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