Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Sander Vesik <sander_traveling yahoo co uk>]

--- Mike Hearn <mike navi cx> wrote: 
> On Fri, 25 Jun 2004 20:01:28 +0100, Sander Vesik wrote:
> > So why not use a standard packing mechanism like say zip, especially as everyby
> s
> > realistcly going to have zlib mapped anyways instead of creating a new packing
> > format? 
> 
> While you can have uncompress zip files support for the format in free
> software is not great and it doesn't deal with things like alignment
> and so on. The packed files can just be mapped and used directly.
> 

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?

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

A counterexample to "mapping zips will cause mapping and aligment issues" is that
modern JDK-s do just that with their classes.jar file.

> One thing that does concern me is that we seem to be hacking around
> problems with the filing system. Why isn't there any way to mark a
> directory as "grouped" which asks the filing system to put all files in
> that directory into a single "run" on the disk consecutively. You could
> then ask the kernel via a new syscall or whatever to map a series of files
> consecutively and you have something similar to the packer system except
> you can still read/write the files using the standard APIs.
> 

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?

> Yes I know this is probably more work and harder to get into the kernel
> etc, but surely that's better than just creating filing-systems-in-a-file
> because the real thing isn't up to scratch?
> 

Not really - the problem is not one of filesystem being up to scratch or no.



	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com