Improper shutdown of system / Fragmentation Problems / Boot
stijn at win.tue.nl
Wed Jun 9 13:10:49 PDT 2004
On Wed, Jun 09, 2004 at 03:59:00PM -0400, Bill Moran wrote:
> Stijn Hoop <stijn at win.tue.nl> wrote:
> > On Wed, Jun 09, 2004 at 02:21:40PM -0500, Scott wrote:
> > > As a newbie to FreeBSD, I may be way off base, but it seems
> > > very logical to me that the size of your drive or partition
> > > would make a difference on at what percentage full one would
> > > start to notice problems.
> > >
> > > In terms of megs/gigs 80% of 120 gigs still has a lot of
> > > work space left. 80% of 4 gigs is not much. I would think
> > > with a larger drive/partition, one could run at a higher
> > > percentage before trouble started.
> > >
> > > It makes sense to me anyway :)
> > That's what one would like, but UFS doesn't work that way. It's
> > allocation algorithm assumes 10% of the disk is free -- regardless
> > of actual size. Or so I've been told (multiple times).
> > IMHO this is a bit ridiculous -- I mean, given 1 TB of space (nearly
> > feasible for a home server right now), why would an FS allocator need
> > 10% of that if the files on the volume are averaging 10 MB?
> > But then again, and this is worth noting -- I'm certainly nowhere near as
> > clueful as others on how to design a stable & fast file system. Seeing as
> > UFS1 is still in use, and has been for the last 20 years (think about
> > it!), I think maybe the tradeoff might make sense to an expert...
> > BTW, note that you really need to consider the perfomance drop for yourself
> > -- like others said, if the files on the volume change infrequently,
> > performance matters little, and space more so.
> I think you've missed the point.
I most certainly do that a lot of the time :)
> The designers of UFS/FFS did not design the filesystem to require 10% free
> space in order to perform well.
OK, I did not know that.
> They developed the best, fastest (thus the name "fast file system") filesystem
> algorithms they could come up with.
That I knew, and still experience every day :)
> Then, during testing, they found that these algorithms started to perform
> really poorly when the filesystem got really full. Thinking this might be
> important, they tested further until they knew exactly what point the
> performance started to drop off at. They then went one step further and
> developed another algorithm in an attempt to maintain as much performance
> as possible even when the filesystem got very full. This is why you'll
> occasionally see the "switching from time to space" message when your
> filesystem starts to fill up. The filesystem drivers are doing their best
> to degrade gracefully.
> Now, I'm not going to say that there is no more that can be done. I think the
> fact is that the two algorithms work well enough that nobody has bothered to
> invest the research into improving them. (That combined with the fact that
> disk space keeps getting cheaper and cheaper, makes it unlikely that anyone
> will invest much $$$ into researching how to use that last 10% while still
> maintaining top performance).
Well, although disk is cheap, seen absolutely it's still a lot of space that's
"wasted". I do understand the issues, and your posts, this and the previous
reply, have made things clearer -- thanks.
"I'm not under the alkafluence of inkahol that some thinkle peep I am. It's
just the drunker I sit here the longer I get."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040609/fdbf8ba1/attachment.bin
More information about the freebsd-questions