I'm running SuSE 5.2 on my PII box, and, whenever I do a hard reset (due to a KDE lockup, etc.) , I get the following error message during the reboot, as Linux looks at each of my partitions (which were not umounted cleanly): /hda8 (0.8 on-contiguous) /hda9 (10.8on-contiguous) etc. My HD is divided into /tmp, /usr, /opt, /, and /home partitions, but only /usr (due to its humongeous size, I guess) is showing fragmentation over 1%). It's now at 10.8%, and getting more fragmented by the day. Any M---S---T operating system would need to be defragged at this point, of course. Linux seems to be tolerating the fragmentation well -- I've been told that it's okay to ignore it -- but apps loading from /usr are slowing down. Does anybody have background on what to do about fragmented HDs? Has anybody defragged a drive using the defrag utility available at RedHat or elsewhere? All fragmentation and defrag stories appreciated!! -- Glenn -- -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e

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

Hubert, Thanks for getting back to me.

Are you sure you can see a slowdown?

Yes, you're probably right -- the slowdown (if any) is probably negligible. But I wonder if that would be the case at a higher frag percentage (like 50 or 60%, in an extreme scenario).

I think most of the fragmentation on /usr comes from compiling the kernel. The installation wrote the apps to a freshly formatted partition so they shouldn't be fragmented at all. This may not be true for applications installed after a kernel compile but fragmentation really shouldn't be a problem.

Well, I've been installing a lot of apps to /usr/local lately -- most of them downloaded from the Internet. And de-installing apps as well. /usr is getting a lot -- too much -- traffic these days.

...

Does anybody have background on what to do about fragmented HDs?

Nothing. Just ignore it. Fragmentation only can become a problem on almost full partitions.

At the moment, my /usr partition is 94 0.000000ull, with only 110,000MBs of remaining space. Am I at a critical level of fullness right now? *** BTW, Hubert, thanks for your comment a few minutes ago about the recent flamewar. (More of a flame*battle*, but still). If newbies make comments that people are offended by, *please* ignore those comments, okay? If you flame them -- either here or in private -- *the entire ML* will be liable to a counterflame, as we saw this morning. -- Glenn -- -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e

Don't know much about ktools and hdparam. A general suggestion, don't mess with the base package. I don't think you will save significant amount of disk space by removing packages piecemeal. On the contrary, you could be shooting yourself in the foot. My goal isn't saving disk space, I'm still only at 18 SuSE installed... I'm just trying to learn what each peice is.. expand my knowledge. I know sed, (should have removed it from the list but I wasn't

On 21-May-98 Arun K. Khan wrote: thinking) but I have never heard of the others and I *hunger* for the knowledge ;) ---------------------------------- <A HREF="http://benham.net/index.html"><A HREF="http://benham.net/index.html</A">http://benham.net/index.html</A</A>> -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d+(-) s:+ a29 C++$ UL++>++++ P+++$ L++>++++ E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- PE++ Y++ PGP++ t+ 5 X R+ !tv b++++ DI+++ D++ G++>G+++ e h+ r* y+ ------END GEEK CODE BLOCK------ ---------------------------------- -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e