An interesting read on One Ted Ts'o:

http://www.av8.net/IETF-watch/Tytso.html


Edit: Please see post #86 for clarification.

What do you want to say? Your posts seems more and more technological irrelevant.

1. You referenced (Ts'o) as an expert guru to bolster your credibility. Depending on the accuracy of the above link his status may be in question.

2. The only reference to Ts'o, in regards to your research, is from you. Self referencing again.

3. Assuming what you posted was a communication from Ts'o, what you interpreted it(what you posted) to say and what I(and a few others I suspect) thought it says are markedly different.


4. Did you give Ts'o a link to this thread? While you say he did not care for our posts, I do not see anything about this thread in the posted information(excluding your ted agreed stuff).

1, For post #71 I did not aim at one single person, but *those* person. You definitely need not to be too much sensitive.

2, However, no matter whatever you define "Defragment", the fastest and the most efficient way is dumping---you get a fragment-free partition in several minutes, the file-system reorganize its structure automatically(this is what Norton GHOST doing).

3, Theodore Ts'o is well known as a core developer of ext2/3/4 and the first north America Linux kernel developer. His words is worthwhile.

hi,


TSo's
Whats ur answer?


this is what all asked earlier!

It's getting a little bit warm around here.
Should I be donning my Asbestos long-johns?

Seriously though, it's better to prevent (as far as possible) fragmentation in the first place than have to try and fix it later.

Given that Linux actually understands elevators, and uses memory the way it's supposed to be used (virtually), how bad would fragmentation have to be before it became an issue?

Let's take the case of random access of a file and memory is insufficient to cache the accesses. It's just going to be slow, there's no two ways about it.

How about serial access. The size of memory doesn't seem to matter, but the issue of how many users there are does. If there is one user doing one single job on a badly scattered large file, yeah, that might be an issue. I say might, only because it might take a deliberate action in order to have a worst case data distribution on the file. In the average case, it's not an issue. For multiple users doing non-trivial jobs the elevator and memory cache should smooth the accesses out enough that it's not noticeable.

Given Linux as the OS, I simply do not see the issue here; except under controlled, deliberately borked, conditions for a single user doing an atypical job.

Dumping is garbage in and garbage out. There is no way of knowing that fragmentation is close to 0%. Doing it the right way such as re-ordering the addresses that points to data to make it sequential is a better and more predictable. Yes, my way will take a lot longer, but it actually will be more efficient than dumping and does not need an extra drive equal to the present drive in order for it to work.

The defrag utility such as in Norton Utilities that actually defrags data based on the address. Doing a full defrag makes all data sequential while a space defrag combs through the mess to provide sequential writes for video, sound, and raw graphics capturing.

This is like saying I do not like getting an oil lube for my car, so I am not going to do it. When not doing an oil lube, the engine can perform horrible or seize. Fragmentation occurs and there is no way around but to do maintenance. tmcco's script defragfs is a fake defrag utility. tmcco is thick-headed to understand what I am trying to say. If tmcco does not know C or C++, should get right on it and learn it to create the correct defrag utility for Linux instead of showing theories and graphs to represent the fake utility. I would rather see theories and graphs based on the correct defrag utility instead of a fake defrag utility.

Guys, can we continue with the discussion without any personal attacks etc. The discussion seems to be getting a bit messy. Cheers.

tmcco

I am a little confused. In your profile you list your homepage as www.tmcco.com, which is the page of one H. Court Young. Mr. Young has self-published three books and loves to put words to paper. Considering his references to his father being in the army I assume he is US born. Your english skills would indicate that you are not a native speaker and not a author (in english). Could you clear up the contradiction?

Thanks
Lazlow

Hi, it's been pointed out to me that there's been this thread about fragmentation, and it's apparently degenerated a fair amount, and furthermore that my name has been dragged into this. So let me try to clear up some points.

First of all, if someone wants to pull out Dean Anderson's opinion of me, some explanation of the background is in order. Since I have previously served as chair of the IP Security Working Group and as a member of the security area directorate of the Internet Engineering Task Force (IETF, the standards body of the Internet), I was asked to serve as one of the two IETF mailing list "Sergeant at Arms", which is responsible for enforcing the mailing list code of conduct. In that role, I asked Mr. Dean Anderson to refrain from violating those guidelines, and he created said web page as a result. Some time later, as a result of his continued violation of these guidelines, Mr. Anderson was subsequently banned from all IETF mailing lists, not by my decision (I, in my role an IETF Sergeant at Arms, report to the IETF chair, and can be overruled by him, although to date this has never happened), but by the Internet Engineering Steering Group. Their decision to ban Mr. Anderson was taken after a request from the IETF community, following a process defined by RFC 3683. The reasons for this ban can be found here and here . Mr Dean Anderson subsequently appealed this decision to the Internet Architecture Board, who upheld the decision by the IESG. Folks should feel free to look at the decisions reached by the leadership of the IETF, and decide whether they come down on the side of them (and me), or that of Mr. Dean Anderson.

Secondly, the note referenced by tmcco was mine. However, it should be noted that it was in reply to his benchmarks about fragmentation. It is certainly true that Linux filesystems can suffer from fragmentation, and his benchmark fairly compared multiple filesystems given a particular workload --- which happened to be to involve randomly deleting some number of files, and writing some other files of different random lengths, with all files in the same directory. Whether or not the workload as measured by his benchmark is a fair one is a different story. Indeed, it's pretty obvious that it doesn't represent an accurate model of real life usage for most users. My note was trying to encourage him to develop a better set of benchmarks.

As far as his specific program is concerned, I'm not particularly enthusiastic about pure userspace progams that attempt to defragment a filesystem. There are significant locking problems that you have to worry about --- what if the file is being accessed and modified while a userspace defragger is copying and rewriting the file? Secondly, these programs don't completely eliminate fragmentation, and indeed, to the extent they work, it is because Linux (and most modern Unix filesystems) are fragmentation resistant. (Note that I didn't say fragmentation-proof!)

So my preference is to improve existing filesystems to make them more fragmentation resistant at least for common, real-life workloads, instead of writing fragmentation programs. We should be able to do better than Microsoft Windows, and not require people run slow defragmentation programs. Of course, the ethos of open source software is that people can work on whatever they want, and if want to work on defragmentation programs, they are perfectly free to --- but it's simply not something I'm interested in myself. However, for people who do want to work on defragmenters, my recommendation is to either create off-line defraggers (such as fixing and updating e2defrag, which is an ext2-specific defragger that only works on 1k blocksizes, doesn't support some of the newer ext3/4 filesystems, and has the sad problem that if it gets interrupted mid-defrag, your filesystem is completely toasted), or to create on-line defraggers that have kernel support (such as the ext4 defragger being worked on by Takashi Sato-san from NEC). My personal interest in the kernel support for on-line defragging is to be able to do on-line shrinking of filesystems, which means that the kernel support for on-line defrag can support multiple problems, which is always a sign of a good design.

So the net of this is that my comments were not meant as an unlimited endorsement of tmcco's ideas, nor (in particular) of his selected defragmentation approach. Do I hope that he might do some more work in this area, however? Of course! In order to do that, though, it means we need to encourage each other in areas where we are on the right track, and gently correct people when they are wrong. It is for that reason that I tried to get him to focus on better benchmarks, and in fact I spent no time criticizing his defragmentation program. This is first of all because he didn't ask me to comment on it, and secondly, because it's better to encourage people in areas where you feel they might be able to contribute useful work, as opposed to tearing them down in other areas.

So let me end this by quoting from Rodney King, "Can't we all just get along?"

Regards,

-- Ted

I'm guessing that's not the correct homepage. The project manager of the defragfs sourceforce project is listed as having the sourceforge username xucanhao, with the listed name of "tmcco". I corresponded with someone with a gmail address with the same username, and who listed his real name as "Xu CanHao", which looks like a Chinese (or at least Asian) name. I'm guessing that tmcco is an irc handle of some sort, and is unrelated to the web page found at www.tmcco.com.

Regards,

-- Ted

Mr. Ts'o,
Thanks for stepping in, making these statements and alleviating all doubt. Hopefully tmcco will now focus on the topic of his thread and stop attempting to sway us with the dropping of additional names.

For the record, no, tmcco did not give me a link to this thread, and I never sent him any statements or comments about this thread and the comments made by him or others on this discussion for the board for the simple reason that I didn't know about it. I did not become aware of this discussion until lazlow sent me e-mail about it on Friday morning. My apologies for not replying until now; I'm pretty busy these days.

Regards,

-- Ted

Mr. Ts'o

The reference (from the question in post #87) to that home page comes from tmcco's own profile on this forum: http://www.linuxquestions.org/questi...er.php?u=32035

That is why I am confused.

I have sent you another email as to other matters.

Again

Thank You

Lazlow