On Mon, 2006-01-02 at 11:02 +0100, Hans Kristian Rosbach wrote:
> On Sun, 2006-01-01 at 12:44 -0800, Peter Gordon wrote:
> > On Sun, 2006-01-01 at 12:35 -0800, Florin Andrei wrote:
> > > It is a good policy to never exceed 80% usage on any partition,
> > > precisely for performance reasons. I am not certain how much each
> > > filesystem type (Ext2/3, XFS, FAT32) is affected, but 80...85% is a good
> > > number to keep in mind. Exceed it, and the performance usually starts to
> > > drop dramatically.
> >
> > Agreed in full. I generally make my partitions a lot larger
> > than I expect them to be used, for this very reason. Granted, it could
> > be easier for me, as disk space really *is* inexpensive where I live;
> > whereas it may not be in other areas...
>
> This is all good, but sometimes you do run out of space. I've seen
> several servers run out of space at night due to runaway processes
> or something similarly uncontrollable situation.
>
> Another possibility is large mailservers, databases, news spools
> or similar files that grow/shrinks/removes data in the middle etc.
>
> So IF a partition has gone over 90% you should expect a great deal
> of fragmentation, but no matter how bad it gets you cant just do
> a quick fixer-up since we have no online defragmentation program.
>
> I too see 250+ extents on binaries like /usr/sbin/mplayer,
> but that potential problem has been dismissed since ELF
> doesn't load the file up sequentially. (but readahead
> would have helped)
>
> Now, what I see as a bigger problem is my home directory..
> A little excerpt:
>
> ./.evolution/mail/local/Inbox.sbd/Devel.sbd/linux-kernel: 1718 extents
> ./.evolution/mail/local/Inbox.sbd/Devel.sbd/Wine-devel: 1472 extents
> ./.mozilla/firefox/jajiw9vd.default/Cache/_CACHE_003_: 1150 extents
> ./.evolution/mail/local/Inbox.sbd/Devel.sbd/fedora-devel: 1139 extents
> ./.spamassassin/bayes_toks: 970 extents
> ./.evolution/mail/local/Inbox.sbd/Devel.sbd/linux-raid: 863 extents
> ./.evolution/mail/local/Inbox.sbd/Devel.sbd/fedora-users: 855 extents
> ./.mozilla/default/lxaxhxet.slt/Cache/_CACHE_003_: 777 extents
> ./.spamassassin/bayes_seen: 691 extents
> ./.evolution/mail/local/Inbox: 537 extents
>
> Now, I hope no one actually thinks this kind of fragmentation
> is just how it should be. True, I will survive even with this
> but I'd rather it wasn't.
>
I agree fragmentation is irritating, but the examples you give are not
duplicated on my system. I checked the same
directory ./.evolution/mail/ and found the largest # of extents on
./.evolution/mail/sql-ledger: 97 extents found
This is a mailbox that I do not routinely delete messages from so it has
been growing for many months.
In contrast, my fedora mailbox has
./.evolution/mail/fedora: 30 extents found
even though the traffic is over 100x the volume, but this one I
regularly delete messages from.
The only assumption I can make is that as files grow additional extents
are added and when data is deleted the extents may remain assigned so
they are reused (or the assigning/releasing maintains a mostly static
quantity).
> I've used this non-opensource util at a few occations, and had
> good results. Problems are: Not opensource, beta, offline-defrag.
> http://www.oo-software.com/en/products/oodlinux/index.html
>
> I would like to see an open-source defragmenter for ext3, if
> just for those worst-case scenarios. Fragmentation CAN happen,
> so there is a need for some.
>
> I'm posting this mostly to encourage those who might think of
> making an open source defragmenter.
>
There are defragmenting tools for some *nix type systems. IBMs AIX has
defragfs for this purpose.
> For the record, this system was installed using FC4 isos from
> scratch and has followed the stream of updates closely.
>
> -HK
>
