Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8
- From: Alan Cox <alan lxorguk ukuu org uk>
- To: Jamie McCracken <jamiemcc blueyonder co uk>
- Cc: Mike Hearn <mike navi cx>, desktop-devel-list gnome org
- Subject: Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8
- Date: Sat, 26 Jun 2004 00:48:01 +0100
On Gwe, 2004-06-25 at 21:23, Jamie McCracken wrote:
> an uncompressed tar far would be better (and possibly faster) than zip
> as its more ubiquitous on nixes. The alignment issue is likely to have
> negligible effect on performance as the main bottleneck is disk i/o
Alignment is critical or you get faults and low performance. Tar btw
doesn't work. Tar has headers through the data because its an archive
format - its designed to handle tape errors so you get
[Header]
[Half an icon]
[Header]
[Other half]
> (saving a dozen ns with alignment does not really compare to the dozen
> ms expended by reading the file in the first place). I dont mind Alan
> doing it his own way but I would like some tools to be able to pack and
> unpack icons myself if thats the case (if we could have File Roller
> supporting that pac formtat then that would be great for ordinary
> users).
If I thought I could reuse a format I would have. A completely agree
that file roller should support such a format. The entire packer is
about 150 lines so thats not a problen
> one big file will always be more efficient than lots of little files
> regardless. Bear in mind that we read data from the disk in 512 byte
> chunks so unless each icon file is exactly a multiple of 512 it could
> involve an extra read. For 1000 icons thats potentially 1000 extra reads
> whilst for a single file it would be only one extra read at most.
A lot of the cost is all the opens. Linux and Unix file systems all
pretty much split data from metadata in stripes. And while you might
just about be able to fix the fs of one OS, the moment you hit NFS or
other platforms it would get very hard indeed.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]