Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Mike Hearn <mike navi cx>]

On Sat, 2004-06-26 at 00:41 +0100, Sander Vesik wrote:
> Can you please clarify this part? Precicely what barriers do you see in 
> support for zip files using compression in free software? And why is that
> not affecting any of the libraries and prtograms (starting off with gzip)
> that also rely on the Deflate algorithm?

There's no point compressing the packed file, as you'd have to
uncompress it into the heap before you could use it, which gets us back
to square one with respect to memory pressure.

> As far as I can tell, the whole mapping and aligment issue is a complete 
> strawman argument as no examples where this is a problem has been presented. 

Alan already explained very clearly why these are issues. I suggest you
reread his original email.

> On the other hand, if a the theme is to be a composite document, not using 
> standard file format (and hence libraries and tools) will have very real 
> overheads and additional dependencies. We really don't need yet another
> magic file format and toolset just to do a trivial thing. 

ZIP is not suitable for this system, neither is tar not tar.gz

The library Alan has written is small and while it'll probably grow if
people start using it in production software, the space savings are
almost certainly worth it.

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

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

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