Here are some other points to consider.

If your machine is swapping, you can consider your machine as having a highly fragmented filesystem; IOW systemic fragmentation.

If your swap partition is on the same disk but greatly displaced from your data, you have a bad case of systemic fragmentation during swap activity.

The level of swappiness affects your effective fragmentation.

The amount of physical RAM affects your effective fragmentation.

If you are running a program that uses a lot of temp space you suffer from systemic fragmentation.

If you are running a separate /tmp partition, you suffer from systemic fragmentation.

If you are running a separate /home partition you suffer from systemic fragmentation.

In the case of disk access by multiple concurrent unrelated processes, a filesystem with 0% fragmentation may be the worst-case scenario; possibly not, but it's unlikely to be the best-case scenario.

If your system is an active NFS or SMB host, you suffer at least some degree of systemic fragmentation.

I'm sure that other posters can contribute other examples of systemic fragmentation.

This is an example of a post technological relevance and without personal attack, which someone else should learn. Well:

1, No matter how much RAM you've got and no matter how less you access the swap partition, the lack of "delayed allocation" makes ext2/3 much more tendency to fragmentation than XFS/Reiser4 which supports that.
(http://groups.google.com/group/linux...77ec83c8?hl=de)

2, Things like "/bin", "/boot" tends to be less fragmented, things like "/tmp", "~", "/usr/src", "/usr/???/portage", "large downloads" tends to be more fragmented.

3, Disk access is much more complicated due to different file-system and different disk access pattern, here is the reply of Jens Axboe as to you and #133:
"
Jens Axboe an mich Details anzeigen 23. Apr.

- Zitierten Text anzeigen -
The answer is, it depends. If both programs issue the reads
asynchronously (instead of doing each read serially), then the ordering
would typically be in straight disk order. No sane disk scheduler would
seek back and forth all the time.

You can test this yourself fairly easily, if you have a newer kernel
that supports blktrace (2.6.17 I think or newer). Get the blktrace tar
ball from here:

http://brick.kernel.dk/snaps/

and compile and install it. Make sure your kernel has
CONFIG_BLK_DEV_IO_TRACE defined. Layout 4 small files on the disk and
write a small test app that does the access in the manner you describe.
Then sync and prune disk caches (sync && echo 3 >
/proc/sys/vm/drop_caches), and execute the app while you have btrace
/dev/<device> running and see what the input to the block layer and what
the io scheduler outputs to the device.

--
Jens Axboe
"

4, So what my suggestion is: do some random-concurrent access yourself on a fragmented partition and a un-fragmented partition(no matter what file-system), then report here.

You still don't understand how fragmentation is negative for a single process but may be positive for a system of concurrent processes. You seem to have missed the whole point about separate partitions. Your thinking seems to be very DOS-centric.

I prefer to examine the limits when it comes to stuff like this. Let's say that you have a hard-drive that only has two areas that can be accessed: one near the beginning of the drive, and one near the end. You have one partition, and two files in that partition. In case1, it just happened to work out that all of file 1 is at one end of the drive, and all of file two is at the other end. If you are running a single process, then all is just fine; perfect even. Unfortunately, if you run two concurrent processes, each accessing the other file, then the effective fragmentation level is as high as possible.. The drive is going to be seeking like crazy.

Let's take another case with this decrepit drive; the case where the two files are horribly fragmented, with approximately half of each file at the beginning and the other half at the end. Let's run the same two processes in the same manner. Unless you have chosen your data distribution and access order very very carefully, the effective fragmentation level is likely going to be much much lower.

Well,

1, Please read 3 in #137 carefully, especially the bold text that point out real-world concurrent access would be much more complicated. (BTW: you've got a sample that maybe nobody will use in the real-world. )

2, Separate partitions does not eliminate fragmentation, even DOS/Windows could have multiple partitions/mount points. And how do you suspect a partition for /tmp, a partition for /home, a partition for /root, a partition for /usr/src, a partition for /usr/local, a partition for /usr/portage, a partition for /var, a partition for /opt, a partition for /etc, a partition for ..., they all suffered a certain degree from fragmentation.

3, And further more, as referred to 1&2, numbers could be much more proven than theories(as pointed out by Jens Axboe, trace the block access pattern yourself to get the right answer).

Added:
I don't think you comprehend the value of examining limits and then generalizing from that to the average case.
/Added

In a multi-processing system, separate partitions increase effective fragmentation rates. Can you say why? I can. In fact, I already have, but you either didn't read or didn't comprehend.

What will cure you of this bad name-dropping habit, anyway? I've spoken to Larry Niven, senator Luger, and Jeff Garzik. Do you see me casually dropping their names as if they were my best friends and lunchtime pals? Jens Axboe is not your friend. You have may be corresponded with him briefly, but, come on! Put an end to this nonsense! Stop attempting to speak for others!

As to. Do you have a link to this quote(please a link to a site that is not under your control)?

I said it could not *eliminate*, rather than *increase*. The examples like "large downloads" / "bad behavior of applications" / "different write strategy of file-systems" as mentioned.

Some of you have been requesting me of giving some proofs by other people rather than reference by myself, seems you regret now?

Sorry, his reply goes directly into my mailbox.

As also pointed out by Mr. Ts'o, I agree that my experiments could be treated something like "worse case". I could not find one "real-world Linux file-system aging" paper as the BSD/FFS: http://www.eecs.harvard.edu/~keith/papers/tr94.ps.gz http://portal.acm.org/citation.cfm?i...ACM&coll=GUIDE

Lets see, I suggested you contact a peer. You then quoted Mr Ts'o and the quote seemed a little off to me so I emailed Mr. Ts'o. Mr. Ts'o then came to this thread and clarified what he actually said. You did not like Mr. Ts'o conclusions.

Now you are quoting Mr. Axboe. This quote is not from a independent verifiable source( a link outside your control) and is not presented in context. Do we really have to go down this same road again?

If Mr. Axboe had come to this thread and made the quote credited to him or if you could provide a link to the information on a site not controlled by you, then it would be proof of something. Until then, this quote is worth as much as the quote you credited to Mr. Ts'o (which he later had to clarify as the meaning had been twisted).

When Mr. Axboe comes on I assume that you will not like his conclusions either and then you will pull the next name off of your list. We will continue this way until one of the gurus on this list will say that "this is just not worth my time" and not bother to "clarify" his statement.

I posted the *original* words of Mr. Ts'o and Mr. Axboe *without* any modification in #69 & #137, as Mr. Tso confirmed in #86. How to interpret their words depends on oneself. (for me I'd say they are positive/objective/constructive/suggestive/informative/encouraging suggestions)

Anyhow, I'd glad to see as much gurus as possible come here, it could clarify many things you and I may misunderstand.

In most cases it is better to allow the guru to speak for himself. As Mr Ts'o did in post #98: I think that this makes it very clear that he thought someone was taking his words and trying to make them mean something that he did not intend to say. I also think it makes his stand on the issue quite clear.

The following from post #71 is clearly refuted in post #89 Both of these statements are quite clear. There is no misunderstand what each of them is saying. One is quite clearly saying that the other is simply not true. If I say the sky is green, then one looks up and the the sky is blue, ether there is something wrong with me or I am not telling the truth. If I later say that what I meant by green was blue (not that I mistyped, etc) it becomes much clearer which of those options is true.

I think this thread has strayed a lot from the issue of filesystems and I doubt that it can go back on track, so I have decided to close it. If there are any objections to this, please kindly send me a message via the LQ email box.