Improper shutdown of system / Fragmentation Problems / Boot

[Stijn Hoop]

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.

I understand.

> 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. 

--Stijn

-- 
"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
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040609/fdbf8ba1/attachment.bin