Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Jamie McCracken <jamiemcc blueyonder co uk>]

On Sat, 2004-06-26 at 01:05, Mike Hearn wrote:

> 
> > What would happen if two directories both of which have a reference to the 
> > same inode (remember hard links?) are asked to put files into a "single run"? 
> > Is it really reasonable to have the filesystem reorganise disk layout each 
> > time a file is added to such a directory? What about deleting? What if some of teh
> > files are large?
> 
> Modern filing systems defragment themselves on the fly anyway (or use
> algorithms that are very good at preventing it in the first place).
> 

They can because they are not constrained by what you want. Modern
filesystems do not place files contiguously but as B-tree nodes. Theres
no way they can give you want you want using B-trees (which also gives
us journalising ability and removes the need to defrag). If you want a
contiguous filesystem you can always use FAT but I expect performance
would still be crap!

> > Not really - the problem is not one of filesystem being up to scratch or no.
> 
> That's exactly what the problem is. The problem, rephrased, is
> basically:
> 
> "startup time is suffering because we are using lots of small files for
> icon themes".
> 
> which can be transformed into
> 
> "startup time is suffering because modern filing systems require lots of
> seek time in order to open many small files"
> 
> which can be transformed into 
> 
> "startup time is suffering because there is no way to ask modern filing
> systems to align files into continuous regions - as that way you seek
> only a few times and gain maximum read speed, ie the idea is to reduce
> the number of seeks as much as possible".

The best solution to that is to use some ultra fast database to store
all the settings and gconf data that currently reside in loads of small
xml files. (xml is also painfully slow to parse and search which
exacerbates the latency). Databases are an excellent choice cause you
only need to use enough memory to hold the indexes to get fast
retrieval. Performance gain from doing that alone would be phenomenal.
If the database supports blob fields you could even shove the icons (or
other binary items) in there.

Expecting similar performance from the filesystem is sadly unrealistic. 

jamie.

> 
> I'm not 100% sure, Alan can correct me, but I'm guessing that for a
> large packed file the number of seeks will still be > 1 because of file
> fragmentation anyway. Really it's just about how you arrange your
> abstractions.
> 
> thanks -mike
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>