mike.mccarty@sbcglobal.net wrote:
Jim Cornette wrote:
John Summerfied wrote:
Jeff Vian wrote:
Exactly, and IIRC the filesystem knows that if it needs X amount of space for a file, then Y number of inodes are marked for use for that file at the beginning. Thus space allocated is as contiguous as is efficient for read/write on the disk.
If "the filesystem knows that if it needs X amount of space for a file," that implies there's a way of telling it that.
How's that done? I don't recall any system call for *x (there is one for OS/2), and one could do it in JCL in IBM's OS in the 60s), but in the *x world I've never seen a way to do it.
Since the discussions regarding fragmentation on ext3 filesystems was pretty long running. I decided to try filefrag /usr/bin/* |sort |grep 'would be' and the output showed a lot of fragmentation. One of the files was up to 45.
On my system I did this...
# filefrag /usr/bin/* | sort -k2 -nr | grep 'would be'
Here're the first few entries...
/usr/bin/emacs: 248 extents found, perfection would be 1 extent /usr/bin/emacs-21.3: 248 extents found, perfection would be 1 extent /usr/bin/kermit: 80 extents found, perfection would be 1 extent /usr/bin/kbabel: 45 extents found, perfection would be 1 extent /usr/bin/ddd: 45 extents found, perfection would be 1 extent /usr/bin/gthumb: 41 extents found, perfection would be 1 extent /usr/bin/gdbtui: 36 extents found, perfection would be 1 extent /usr/bin/elinks: 30 extents found, perfection would be 1 extent /usr/bin/iniomega: 22 extents found, perfection would be 1 extent /usr/bin/kpersonalizer: 21 extents found, perfection would be 1 extent /usr/bin/artsd: 21 extents found, perfection would be 1 extent /usr/bin/artscat: 20 extents found, perfection would be 1 extent /usr/bin/kiconedit: 19 extents found, perfection would be 1 extent /usr/bin/glade-2: 19 extents found, perfection would be 1 extent /usr/bin/karm: 18 extents found, perfection would be 1 extent /usr/bin/dia: 18 extents found, perfection would be 1 extent /usr/bin/designer3: 18 extents found, perfection would be 1 extent /usr/bin/designer: 18 extents found, perfection would be 1 extent /usr/bin/kppplogview: 16 extents found, perfection would be 1 extent /usr/bin/kfontinst: 16 extents found, perfection would be 1 extent /usr/bin/civclient-xaw: 15 extents found, perfection would be 1 extent /usr/bin/cdrecord: 15 extents found, perfection would be 1 extent /usr/bin/knewstickerstub: 14 extents found, perfection would be 1 ext
Surely those who argue that ext3 does not get fragmented during install don't think that 248 extents is "not significant fragmentation".
I assure you that I have done nothing on my system to try to fragment emacs.
Mike
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!
Yes, but... [root@bend ~]# filefrag /bin/* | sort -k2 -nr | grep 'would be' /bin/netstat: 2 extents found, perfection would be 1 extent /bin/login: 2 extents found, perfection would be 1 extent
Files that are frequently updated will often have some level of fragmentation. Files that are relatively unchanged tend to be in a single extent. Also, the stuff in /bin will generally be small, tight, command line programs. A quick perusal of those listed in your example shows a number of graphical interface programs that are anything but small and don't even get me started about the size of emacs (the probability of change to a program is very directly related to the size of the program).
Cheers, Dave
David G. Miller (aka DaveAtFraud) wrote:
mike.mccarty@sbcglobal.net wrote:
Yes, but...
No, Yes PERIOD.
The point being made is to refute the idea that ext3 inherently does not fragment files.
[root@bend ~]# filefrag /bin/* | sort -k2 -nr | grep 'would be' /bin/netstat: 2 extents found, perfection would be 1 extent /bin/login: 2 extents found, perfection would be 1 extent
Files that are frequently updated will often have some level of fragmentation. Files that are relatively unchanged tend to be in a single extent.
Again, the point was that some claim that ext3 does not and will not fragment files which are not dynamic. I claimed that fragmentation can occur simply due to install of software, which some claimed will not and does not occur with ext3. I think that I have demonstrated my point. In fact, I was quite shocked that it was as bad as that, frankly.
Also, the stuff in /bin will generally be small, tight, command line programs. A quick perusal of those listed in your example shows a number of graphical interface programs that are anything but small and don't even get me started about the size of emacs (the probability of change to a program is very directly related to the size of the program).
I don't use emacs except when I have to. I use MicroEmacs which I build and maintain myself for all my platforms (MSDOS, Win95/98, Linux, at one time Solaris and VAX/VMS).
$ ls -l /usr/bin/emacs ~/bin/em -rwxr-x--- 1 jmccarty jmccarty 505567 Oct 26 2004 /home/jmccarty/bin/em -rwxr-xr-x 2 root root 4408492 Feb 4 2005 /usr/bin/emacs
Mike
On Fri, 2005-12-30 at 10:10 -0600, Mike McCarty wrote:
Again, the point was that some claim that ext3 does not and will not fragment files which are not dynamic. I claimed that fragmentation can occur simply due to install of software, which some claimed will not and does not occur with ext3. I think that I have demonstrated my point. In fact, I was quite shocked that it was as bad as that, frankly.
Hi Mike,
OK, fragmentation can and sometimes does occur. You've explained why and how.
So the next logical question is: what difference, if any, does it make? Can you or anyone else come up with a way to measure the effect or some aspect of it? Perhaps a benchmark that shows how application startup times suffer?
I'm not a filesystems guru, but even so its not at all clear to me that fragmentation must necessarily cause a big or repeated performance hit. Given Linux's VM, it seems plausible that an initial file load might suffer (maybe a lot or maybe a tiny bit?) and that subsequent file accesses will be from pages already cached in RAM.
We should all keep open minds and, if possible, generate some actual benchmark data!
Ed
On Fri, 2005-30-12 at 12:56 -0500, Ed Hill wrote:
On Fri, 2005-12-30 at 10:10 -0600, Mike McCarty wrote:
Again, the point was that some claim that ext3 does not and will not fragment files which are not dynamic. I claimed that fragmentation can occur simply due to install of software, which some claimed will not and does not occur with ext3. I think that I have demonstrated my point. In fact, I was quite shocked that it was as bad as that, frankly.
Hi Mike,
OK, fragmentation can and sometimes does occur. You've explained why and how.
So the next logical question is: what difference, if any, does it make? Can you or anyone else come up with a way to measure the effect or some aspect of it? Perhaps a benchmark that shows how application startup times suffer?
I'm not a filesystems guru, but even so its not at all clear to me that fragmentation must necessarily cause a big or repeated performance hit. Given Linux's VM, it seems plausible that an initial file load might suffer (maybe a lot or maybe a tiny bit?) and that subsequent file accesses will be from pages already cached in RAM.
We should all keep open minds and, if possible, generate some actual benchmark data!
Ed
Finally were back to the original post.
I am not a guru either, but have been administrating Unix systems since the 1980's. I have not found fragmentation to be a significant cause of performance problems on any Unix or Linux machines. Although fragmentation does occur, most Unix and Linux file systems are designed to minimize fragmentation and maximize utilization. Many Unix and Linux file systems try to write files using multiple contiguous blocks. Each block is made up of a number of fragments, the number of fragments per block will depend on the drive size and other parameters. The terminology for fragment confuses this discussion, but may also be the cause of the initial posting. This forum is not well suited to discussing how files are allocated, because there are too many different file systems that use different algorithms to determine when to allocate space for a file in a fragment. In basic terms many file systems allocate as many complete blocks as possible when creating a file and put whats left into a fragments. When a file with fragments is updated and grows enough to fill more complete blocks many Unix and Linux file systems attempt to allocate full blocks to move the new data and the data in the fragments into more complete blocks. If there is sufficient space available many file systems try to ensure files are allocated a contiguous range of blocks. Even if all files have as many contiguous full blocks assigned as possible, some the data will likely be stored in fragments. When running fsck, the fragmentation reported is the number of fragments allocated in comparison to the number of files allocated, and does not necessarily indicate that files are scattered all over the drive.
In closing, the term fragmentation can mean two different things on Linux and Unix file systems, but generally means only one thing in the Windows world. The issue can be quite confusing when administrators who come from an Windows background talk about fragmentation with there Linux and Unix counterparts, because they may not be talking about the same thing. I believe an article on the new file system MS is working on indicates, it will be more like Linux and Unix file systems with respect to the inherent housekeeping and file allocation mechanisms, that reduce the scattering effect.
Guy Fraser wrote:
Finally were back to the original post.
I am not a guru either, but have been administrating Unix systems since the 1980's. I have not found fragmentation to be a significant cause of performance problems on any Unix or Linux machines. Although fragmentation does occur, most Unix and Linux file systems are designed to minimize fragmentation and maximize utilization. Many Unix and Linux file systems try to write files using multiple contiguous blocks. Each block is made up of a number of fragments, the number of fragments per block will depend on the drive size and other parameters. The terminology for fragment confuses this discussion, but may also be the cause of the initial posting. This forum is not well suited to discussing how files are allocated, because there are too many different file systems that use different algorithms to determine when to allocate space for a file in a fragment. In basic terms
Untrue in this context, as the OP specifically requested to find a defragmenter for ext3. That's what led to the claim that a defragmenter is not necessary for ext3, as it has some inherent immunities to fragmentation.
Another question, which AFAIK remains unaswered, though posed by Ed Hill, is just what is the performance degradation which might be suffered. Unfortunately, that is completely dependent on the use to which the file is put, and how often it is read.
Most (all today?) disc drives have read-ahead caching built into the drive, so that reads to sequential sectors are quite a bit faster than random reads, even when no seek is necessary.
Mike
On Fri, 2005-12-30 at 16:40 -0600, Mike McCarty wrote:
Guy Fraser wrote:
Finally were back to the original post.
I am not a guru either, but have been administrating Unix systems since the 1980's. I have not found fragmentation to be a significant cause of performance problems on any Unix or Linux machines. Although fragmentation does occur, most Unix and Linux file systems are designed to minimize fragmentation and maximize utilization. Many Unix and Linux file systems try to write files using multiple contiguous blocks. Each block is made up of a number of fragments, the number of fragments per block will depend on the drive size and other parameters. The terminology for fragment confuses this discussion, but may also be the cause of the initial posting. This forum is not well suited to discussing how files are allocated, because there are too many different file systems that use different algorithms to determine when to allocate space for a file in a fragment. In basic terms
Untrue in this context, as the OP specifically requested to find a defragmenter for ext3. That's what led to the claim that a defragmenter is not necessary for ext3, as it has some inherent immunities to fragmentation.
Hi Mike,
Even if there is fragmentation, it simply DOES NOT MATTER if it doesn't result in a measurable performance hit. So, what benchmarks can you cite that show us how fragmentation degrades performance on a Linux (specifically, ext3) filesystem?
Or, can you create your own test? I mean this very sincerely. If you want to argue that something matters then you need to back it up with some actual measurements. If fragmentation matters then you should be able to devise a test case that demonstrates it.
Another question, which AFAIK remains unaswered, though posed by Ed Hill, is just what is the performance degradation which might be suffered. Unfortunately, that is completely dependent on the use to which the file is put, and how often it is read.
Its not another question. Its the only good reason for getting into this discussion.
Most (all today?) disc drives have read-ahead caching built into the drive, so that reads to sequential sectors are quite a bit faster than random reads, even when no seek is necessary.
Yes, but such things only matter on the initial read from the disk. The Linux VFS+VM will in all likelihood obviate any need to repeatedly read blocks from a disk for frequently accessed files. So for commonly used blocks, the cost is in all likelihood amortized.
Can you demonstrate that the *initial* read really costs more? And, if so, how much?
Ed
Ed Hill wrote:
On Fri, 2005-12-30 at 16:40 -0600, Mike McCarty wrote:
Guy Fraser wrote:
Finally were back to the original post.
[snip]
the cause of the initial posting. This forum is not well suited to discussing how files are allocated, because there are too many different file systems that use different algorithms to determine when to allocate space for a file in a fragment. In basic terms
Untrue in this context, as the OP specifically requested to find a defragmenter for ext3. That's what led to the claim that a defragmenter is not necessary for ext3, as it has some inherent immunities to fragmentation.
Hi Mike,
Hi! I preface this by saying that nothing in here is intended to be or sound rude. Ok?
Even if there is fragmentation, it simply DOES NOT MATTER if it doesn't result in a measurable performance hit. So, what benchmarks can you
I never said otherwise.
cite that show us how fragmentation degrades performance on a Linux (specifically, ext3) filesystem?
Or, can you create your own test? I mean this very sincerely. If you want to argue that something matters then you need to back it up with
I don't want to spend the time necessary to try to devise a test. I possibly could, though it would take some study of the file system, and might require mods to the file system. I don't know.
some actual measurements. If fragmentation matters then you should be able to devise a test case that demonstrates it.
What I *did* claim is that ext3 is subject to fragmentation. I don't recall stating that it was something I was particularly concerned about. I responded to a claim which was demonstrably false, and was being used as an argument to tell someone asking a polite question that he shouldn't be asking the question.
Another question, which AFAIK remains unaswered, though posed by Ed Hill, is just what is the performance degradation which might be suffered. Unfortunately, that is completely dependent on the use to which the file is put, and how often it is read.
Its not another question. Its the only good reason for getting into this discussion.
It is not. When someone asks a question, politely, in a reasonable forum, he deserves a reasonable answer, not an argument. YOU don't know what all his reason for asking was. Perhaps he wants to compress all the used space down to one end of the drive for purposes of splitting the partition. What difference does it make? If he posed a reasonable question, he deserves a reasonable answer. He does not deserve being told that his question has no basis, because the circumstance doesn't occur, when in fact it *does* occur.
Most (all today?) disc drives have read-ahead caching built into the drive, so that reads to sequential sectors are quite a bit faster than random reads, even when no seek is necessary.
Yes, but such things only matter on the initial read from the disk. The Linux VFS+VM will in all likelihood obviate any need to repeatedly read blocks from a disk for frequently accessed files. So for commonly used blocks, the cost is in all likelihood amortized.
You seem argue against points I don't make, and then don't respond to the points I *do* make.
Perhaps I'm not being clear enough. I dunno. Truly, I'm getting confused by this thread.
Can you demonstrate that the *initial* read really costs more? And, if so, how much?
It matters, as I said, depending on what use the file gets read. (I didn't say how often it gets read sequentially, I said what use.) It also depends on how large it is. You apparently have not actually written disc caching code. I have. In particular, I have made some mistakes writing disc caching code. When the size of the file is somewhat larger than the cache can hold, and the whole file gets read repeatedly sequentially, then many caching algorithms thrash badly. In particular, LRU often thrashes badly. It is a theorem that *any* caching algorithm has a circumstance which causes it to behave *worse* than no caching. (The particular circumstance may not be sequential read, BTW.)
Which is why I said that it unfortunately depends on the use the file gets. I just didn't get into gritty details, because I didn't expect anyone to argue against a theorem of computer science.
Mike
Mike McCarty wrote:
David G. Miller (aka DaveAtFraud) wrote:
mike.mccarty@sbcglobal.net wrote:
Yes, but...
No, Yes PERIOD.
The point being made is to refute the idea that ext3 inherently does not fragment files.
[root@bend ~]# filefrag /bin/* | sort -k2 -nr | grep 'would be' /bin/netstat: 2 extents found, perfection would be 1 extent /bin/login: 2 extents found, perfection would be 1 extent
Files that are frequently updated will often have some level of fragmentation. Files that are relatively unchanged tend to be in a single extent.
Again, the point was that some claim that ext3 does not and will not fragment files which are not dynamic. I claimed that fragmentation can occur simply due to install of software, which some claimed will not and does not occur with ext3. I think that I have demonstrated my point. In fact, I was quite shocked that it was as bad as that, frankly.
A while ago I differentiated between extents and fragments.
I see an extent as a section of contiguous storage, normally allocated together. In systems that support preallocation, if you ask for 50 Mbytes the OS will normally try to give it to you in a single extent. If it can't, the result is implementation-dependent, and unimportant here.
If you want more space, probably it will create a new extent. Depending on the implementation and availability, this might be contiguous with the first extent. One would not ordinarily describe these two extents as fragments, unless they were separated in (disk) space.
Even when files are fragmented, if the fragments are close together the fragmentation is relatively unimportant because it has relatively little impact on performance.
Take this file: [summer@bilby var]$ sudo filefrag swapfile swapfile: 13 extents found, perfection would be 5 extents [summer@bilby var]$
Is that separation into 13 extents important? How close are they? I'll leave it to someone else to draw a map: summer@bilby var]$ sudo filefrag -v swapfile Checking swapfile Filesystem type is: ef53 Filesystem cylinder groups is approximately 18832 Blocksize of file swapfile is 4096 File size of swapfile is 536870912 (131072 blocks) Discontinuity: Block 7 is at 5571073 (was 5538311) Discontinuity: Block 13 is at 5603841 (was 5571079) Discontinuity: Block 20 is at 5625473 (was 5603847) Discontinuity: Block 27 is at 5636609 (was 5625479) Discontinuity: Block 34 is at 5664937 (was 5636615) Discontinuity: Block 3957 is at 5669384 (was 5668863) Discontinuity: Block 30035 is at 5695496 (was 5695487) Discontinuity: Block 36165 is at 5702152 (was 5701631) Discontinuity: Block 68382 is at 5734920 (was 5734399) Discontinuity: Block 78860 is at 5745416 (was 5745408) Discontinuity: Block 100591 is at 5767688 (was 5767167) Discontinuity: Block 129036 is at 5796168 (was 5796160) swapfile: 13 extents found, perfection would be 5 extents [summer@bilby var]$
if only because I don't understand the report, and the man page doesn't clarify.
On Fri, 2005-12-30 at 18:27 -0600, Mike McCarty wrote:
I don't want to spend the time necessary to try to devise a test. I possibly could, though it would take some study of the file system, and might require mods to the file system. I don't know.
Hi Mike,
I'm not trying to be rude. I'm just interested in the performance aspect.
And in terms of a test, imagine:
1) create an ext3 filesystem on an empty partition 2) mount it 3) copy some files (including executables) into it 4) measure how fragmented the resulting files are 5) measure how quickly one can read and/or execute the files 6) delete and/or add some more files (try to fragment them!) 7) unmount the filesystem (to clear any caching) 8) goto (2)
which should, after a few cycles, result in measurements of file read and execute times for files with varying amounts of fragmentation.
Ed
On Fri, 2005-12-30 at 18:27 -0600, Mike McCarty wrote:
What I *did* claim is that ext3 is subject to fragmentation.
The "so what" answer is probably the best answer that you're going to get. Your claim is about as significant as saying that hard drives are subject to having data stored on them.
Unless fragmentation on ext3 file systems is a problem, and I've no evidence to the contrary, then it doesn't matter how the data is put on the drive.
In some cases, physical fragmentation is even a benefit (think of *one* of the RAID methods where data is spread across several different drives).
I don't worry about fragmentation any more than I worry about other technicalities of how the data is put onto the drive.
On Sat, 2005-12-31 at 03:12, Tim wrote:
Unless fragmentation on ext3 file systems is a problem, and I've no evidence to the contrary, then it doesn't matter how the data is put on the drive.
All you have to do is look at the seek time on a disk drive compared to any other computer operation to see what the effect will be if a file that is normally read sequentially is broken into non-contiguous chunks. However aside from the effort the system makes to avoid doing that, the real reason you don't often notice the problem in practice is that frequently-accessed files always live in cache so if you read a file often you only take the speed hit once - and if you don't read it often it probably doesn't matter. Writes also always go through cache and sensible operating systems will sort the write-back into seek order to avoid threshing the head around in the process. So, if you think you have a speed problem caused by your disk, the quick fix is normally to add more RAM.
Les Mikesell wrote:
All you have to do is look at the seek time on a disk drive compared to any other computer operation to see what the effect will be if a file that is normally read sequentially is broken into non-contiguous chunks.
This is one of my favourite hobby-horses, especially when I'm trying to explain why we need multiple disk drives for performance...
But the manufacturer's quoted seek time is for random access. If two file fragments are "suitably close" on a disk drive, then the seek time between fragments will be significantly less.
My understanding is precisely that ext2 and ext3 locate files in such a way on disk as to minimise the seek time.
Incidentally, my e-mails live in maildir mailboxes: one file per e-mail. My Fedora List box gets rather large with time, and this makes it somewhat slow to open (I keep all list e-mail, and archive it eventually).
This is due to a very similar phenomenon: obviously, e-mails get written to mailboxes as they arrive, and get located all around the hard disk. So I have to wait for the hard drive to do a lot of seeks when I open the mailbox. I find that copying a mailbox to a new location on the same disk re-locates the e-mails so they are "suitably close". Seek time goes right down, and the mail box opens a *lot* faster. I don't have any figures to hand, but it feels like the mailbox opens in one fifth of the time, maybe less.
Hope this helps,
James.
On Sat, 2005-12-31 at 12:15 -0600, Les Mikesell wrote:
Writes also always go through cache and sensible operating systems will sort the write-back into seek order to avoid threshing the head around in the process. So, if you think you have a speed problem caused by your disk, the quick fix is normally to add more RAM.
It iss interesting to note, also, that Ext3's default "ordered" data writing mode does precisely this, from what I've read. It first commits the metadata transactions to the journal, then flushes the data to the disk in large blocks of writes, then commits the journal transactions to the disk.
Extents-based and delayed write allocation (for on-disk contiguity of file data) are also being worked on (though, due to possible on-disk changes of the filesystem format, this could end up becoming "ext4" or similar). Please see the following page for more information: http://ext2.sourceforge.net/2005-ols/paper-html/node18.html
Tim wrote:
On Fri, 2005-12-30 at 18:27 -0600, Mike McCarty wrote:
What I *did* claim is that ext3 is subject to fragmentation.
The "so what" answer is probably the best answer that you're going to
If you actually bothered to read what went before, you'd see that is response is malapropos.
[snip]
I don't worry about fragmentation any more than I worry about other technicalities of how the data is put onto the drive.
Arguing against claims I haven't made.
Mike
On Mon, 2006-01-02 at 11:46 -0600, Mike McCarty wrote:
Tim wrote:
On Fri, 2005-12-30 at 18:27 -0600, Mike McCarty wrote:
What I *did* claim is that ext3 is subject to fragmentation.
The "so what" answer is probably the best answer that you're going to
If you actually bothered to read what went before, you'd see that is response is malapropos.
[snip]
I don't worry about fragmentation any more than I worry about other technicalities of how the data is put onto the drive.
Arguing against claims I haven't made.
*sigh*
Not true, Mike. Both the original poster and you discussed performance:
https://www.redhat.com/archives/fedora-list/2005-December/msg03298.html https://www.redhat.com/archives/fedora-list/2005-December/msg03340.html
and you asserted:
"Umm, I believe the argument is not that it defrags itself, just that the type of fragmentation it enjoys does not affect performance. Some sort of fertilizer[*], if you ask me."
So, please come up with some actual measurements that will back up your "fertilizer" story.
Ed
Peter Gordon wrote:
On Sat, 2005-12-31 at 12:15 -0600, Les Mikesell wrote:
Writes also always go through cache and sensible operating systems will sort the write-back into seek order to avoid threshing the head around in the process. So, if you think you have a speed problem caused by your disk, the quick fix is normally to add more RAM.
It iss interesting to note, also, that Ext3's default "ordered" data writing mode does precisely this, from what I've read. It first commits the metadata transactions to the journal, then flushes the data to the disk in large blocks of writes, then commits the journal transactions to the disk.
Extents-based and delayed write allocation (for on-disk contiguity of file data) are also being worked on (though, due to possible on-disk changes of the filesystem format, this could end up becoming "ext4" or similar). Please see the following page for more information: http://ext2.sourceforge.net/2005-ols/paper-html/node18.html
Thanks for the link Peter, I found the reading interesting. The information clears up some questions if the fragmentation problem and dealing with large files is being addressed. It seems that work is ongoing.
Jim
Ed Hill wrote:
On Mon, 2006-01-02 at 11:46 -0600, Mike McCarty wrote:
Tim wrote:
On Fri, 2005-12-30 at 18:27 -0600, Mike McCarty wrote:
What I *did* claim is that ext3 is subject to fragmentation.
The "so what" answer is probably the best answer that you're going to
If you actually bothered to read what went before, you'd see that is response is malapropos.
[snip]
I don't worry about fragmentation any more than I worry about other technicalities of how the data is put onto the drive.
Arguing against claims I haven't made.
*sigh*
Not true, Mike. Both the original poster and you discussed performance:
Specifically not true. "Discussion" and "worry" are two different things. I am myself not worried about whatever the effects on performance might be, since I am not experiencing any problems with disc performance. I have not made any claims that whatever performance hits there are are significant to me. Whether they are significant to others depends on a variety of factors. I also don't argue that *you* experience problems with disc performance.
https://www.redhat.com/archives/fedora-list/2005-December/msg03298.html https://www.redhat.com/archives/fedora-list/2005-December/msg03340.html
and you asserted:
"Umm, I believe the argument is not that it defrags itself, just that the type of fragmentation it enjoys does not affect performance. Some sort of fertilizer[*], if you ask me."
So, please come up with some actual measurements that will back up your "fertilizer" story.
If you actually read what I wrote, you will see that my statement is that claims that there is no effect on performance is fertilizer. I did not claim that the effects, whatever they are, bother me, or anyone else. I simply state that they *exist*.
It is entirely possible that, on my machine, the fragmentation *enhances* performance. Unlikely, but possible.
Mike
Mike McCarty:
If you actually bothered to read what went before, you'd see that is response is malapropos.
...[snip]...
Arguing against claims I haven't made.
Ed Hill:
*sigh*
Not true, Mike. Both the original poster and you discussed
From reading Mike's postings over the last several days, it seems he's
one of those that forever argues "I didn't say that", threads are only between original poster and first respondent and about the original words spoken, and is adamant that everyone must agree with him.
Tim wrote:
Mike McCarty:
From reading Mike's postings over the last several days, it seems he's one of those that forever argues "I didn't say that", threads are only between original poster and first respondent and about the original words spoken, and is adamant that everyone must agree with him.
Well, I'm sorry I impress you that way. I try to choose my words carefully when posting, and usually mean very much literally what I say, except when using irony (humorous or otherwise). I hope what I put in here doesn't sound anything but cordial. I've read it several times, trying to remove anything which might sound condemnatory.
What I argued were these points:
(1) ext3 is subject to fragmentation (2) fragmentation has effects on disc performance for at least these reasons: (a) most if not all modern discs actually do read-ahead and if sequential reads are taking place, then these can help since we have parallel processing in our favor (b) any caching algorithm has bad cases, and so one cannot rely on caching to make up for all effects of fragmentation, since the caching may make the performance *worse* (3) exactly what the effects of fragmentation are depend heavily on how the file is used, and a fragmented disc may actually have better response than a contiguous one (especially with multitasking this is relevant, since multiple files may be involved) (4) not all effects of fragmentation are performance related, and if one is trying to reallocate partitions it may make sense to have a defragmenter
I did not argue any of these points:
(1) ext3 fragmentation has effects which are noticeable under most ordinary circumstances to ordinary users of Linux (2) the caching algorithm used in Linux is inadequate for many or any of the users of Linux (3) I need to have an ext3 defragmentation program (4) I am being adversely affected by fragmentation (5) I am worried about or spend time concerned over fragmentation on my machine (6) anyone else should be worried about, or spend time fretting over any effects of fragmentation when using ext3 with Linux (7) anything other than what is listed above (unless I inadvertently overlooked something) in my list of points I argued (1)-(4).
I have seen people, including you, respond to points I did not argue. For example, your statement and my reply
I don't worry about fragmentation any more than I worry about other technicalities of how the data is put onto the drive.
Arguing against claims I haven't made.
I never claimed I was "worried" or "troubled" by fragmentation. What I claimed is that it exists, and it has effects.
Then Ed chimed in with
*sigh*
Not true, Mike. Both the original poster and you discussed performance:
https://www.redhat.com/archives/fedora-list/2005-December/msg03298.html https://www.redhat.com/archives/fedora-list/2005-December/msg03340.html
I pointed out that "discuss" and "worry about" are not synonymous.
This is an exact quote from my reply to Ed:
Specifically not true. "Discussion" and "worry" are two different things. I am myself not worried about whatever the effects on performance might be, since I am not experiencing any problems with disc performance. I have not made any claims that whatever performance hits there are are significant to me. Whether they are significant to others depends on a variety of factors. I also don't argue that *you* experience problems with disc performance.
Do you disagree that one may discuss something which one does not consider significant or worrisome? What was significant to me was what I considered to be counter-factual claims, not disc performance, and those are what I was responding to. Counterfactual claims *are* worrisome to me. In pursuing them, I wound up discussing disc performance. But for me disc performance is not the issue.
The reason I got into this thread in the first place was that I saw what seemed to me to be an absolute post that ext3 is inherently immune to fragmentation, and it just does not/cannot occur. That is demonstrably false. Another post seemed to flatly state that because Linux uses caching, any fragmentation is irrelevant except for the first read of the disc. This is also demonstrably, and even provably, false.
I'm not trying to weasel out, as you can see, since I am here, in what I hope are very plain words, stating what I have tried to claim, and what I have not tried to claim, and what my motives were.
Briefly, my motive is to correct flat statements which seem to me to be factually incorrect, some of them seeming to contradict theorems of computer science.
I don't give a rip about the fragmentation on my machine, since it doesn't seem to cause me any problems whatsoever.
I do care when people make statements to the effect that ext3 is not subject to fragmentation, or that caching can nullify the effects of fragmentation.
I also care when people argue in reply to me, against points I haven't made and wouldn't make, responding to words which I did not and would not use. Especially when I am pretty careful not to say things I don't intend.
Now, to take your claims about me in turn...
From reading Mike's postings over the last several days, it seems he's one of those that forever argues "I didn't say that", threads are only
I think that I have demonstrated that you, at least, have argued against points I haven't intended to make. When someone says "I didn't argue that", people with open minds tend to ask "Oh? Then I must have misunderstood. What point *did* you intend to make?" Argumentative and closed minded people tend to draw conclusions and impute motives.
between original poster and first respondent and about the original words spoken,
Since I specifically addressed issues that the OP and the OR did not discuss, I guess that this doesn't seem quite on the mark, either. I will confess to trying to guide some of the thread back on track of helping the poor OP actually get a response which might be useful to him.
and is adamant that everyone must agree with him.
I'll give you right here the chance to argue against any or all of the points (1)-(4) I argue for above which you believe to be incorrect. I'd be glad to learn which of my beliefs on these points are inaccurate.
P.S. personal comments are better reserved to personal e-mail, with a return address which does not give the appearance of being bogus, don't you think?
Mike
-
David G. Miller (aka DaveAtFraud) -
Ed Hill -
Guy Fraser -
James Wilkinson -
Jim Cornette -
John Summerfield -
Les Mikesell -
Mike McCarty -
Peter Gordon -
Tim