Hi! Trying to kill the keyboard, jpcowh01@dragon.slug.louisville.edu produced:
If you installed with e2tfs on your drives:
umount /opt e2fsck /dev/"partition /opt is on"
It will fix your non-contiguous issue...
This, of course, is blatantly incorrect. e2fsck (actually, all fsck's) will repair damage to the metainformation of the filesystem, a bit equivalent but much more powerful than scandisk under DOS/Windows. However, the question was about defragmenting an ext2fs-filesystem. The German SDB has the following information (rough translation): ----------------------------------------------------------------- EXT2 - Fragmentation Question: How does one defrag the EXT2-Filesystem? Error report: The filesystemcheck shows x% "non-contiguous". Answer: This information comes from Kristian Koehntopp. It is useless, because after defragmentation the filesystem will fast reaquire a fragmentation grade typical for it's usage and then stay there. Additionally the length of the fragments is important. Linux uses a read-ahead of 16 blocks. That means: In a sequential read access to a file (more than 950f all read requests) Linux reads up to 16 sequential blocks ahead of the current access to warm up the kernel-buildin cache, hoping that these blocks will soon be requested by the reading program. Should the fragments be bigger than 16 blocks (most of them are, see below) then a fragmentation does not matter since the seek of the read-ahead cancels it out. Only fragments smaller than 16 blocks actually hurt the reading performance. The ext2-filesystem writes files with a type of readahead, aeh, preallocation. If you write one block in a ext2-fs, up to 7 sequential following blocks are allocated for that file. Two concurrent write accesses in one directory thus would not produce blocks like: 121212121212 but rather a block sequence 1ppppppp2qqqqqqq were 1 and 2 are the written blocks for files 1 and 2, while p and q are preallocated for files 1 and 2. Should 1 and 2 be concurrently expanded a block sequence 11111111222222221ppppppp2qqqqqqqq is created ... and so on. In this way the bad (small) fragmentation is mostly avoided. This procedure is a generalisation of the fragment/ block procedure of the BSD Fast Filing System. As a user on a multitasking system you have to differentiate between performance and throughput, too: Performance is what a user with a single process can maximally suck out of a hard disk in MB/sec. Thoughput is what the HD spits out in MB/sec for all users and processes together. In multitasking systems throughput is usually very much higher than performance. Linux uses algorithms that improve the throughput, not the performance, of the system. For example are accesses to the hard disk in the wait queue of the disk are sorted by rising block numbers. With a saw-tooth algorithm the head of the hard disk climbs to the high block numbers and services the requests and then zips down again in a long seek for the next round. (No, that is not exactly the elevator algorithm: With it latent-times/service-times were to high and the algorithm is not fair.) And sequential requests for the same process are clustered to one larger request. By this sorting the read accesses are not accomplished in the sequence and size the process asked for, but with the sequence and size the hard disk likes. Thus the effects of larger fragments are mostly covered - only small fragments are harmful to the throughput. And finally over all this lies the buffer cache of the operating system, i.o.w. the second read access completely comes out of the RAM and the ordering of the data on the hard dist is completely irrelevant. Defragmentation is wasting time, Kristian ----------------------------------------------------------------- Finally one might mention that there is a defragmenter for ext2-fs, but it is pretty alpha (i.e. hope you have a good backup) and nobody uses it. There is another way to defragment a partition: Back it up to somewhere (tape, another partiton), nuke old partition (mk2fs, etc. etc.) and put the backup onto the remade partition. Usually one uses tar or dump for such tasks, because you might want to keep your special files (pipes, devices, etc.) and only gnu cp is up to the task. Also the fragmentation issue is a good reason for using different partitions for different types of data: /usr changes seldom, if ever, and you might want to mount it read-only. /home changes a bit over the time. /var/spool changes usually fast (news, mail, webcache) and might even require a higher inode density. So try to add into your partitioning plans also the overall life-time of your data on them, that will help that the 'fragmentation grade typical for it's usage' is not twisted between almost never changing and changing by the hour (and different sizes, etc.) Oh, the typical fragmentation is true for all normal usage of the partition, even if up to 95 0.000000illed. Beyond that one must reuse every corner, obviously (but don't forget the usual 5% reserved for root, see tune2fs). -Wolfgang PS: SuSE, go ahead, add it into the SDB, it's OK with me. -- PGP 2 welcome: Mail me, subject "send PGP-key". If you've nothing at all to hide, you must be boring. Unsolicited Bulk E-Mails: *You* pay for ads you never wanted. Is our economy _so_ weak we have to tolerate SPAMMERS? I guess not. -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e