gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: give us a hand with arch


From: Samium Gromoff
Subject: Re: [Gnu-arch-users] Re: give us a hand with arch
Date: Mon, 29 Sep 2003 15:12:34 +0400
User-agent: Wanderlust/2.11.7 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 28 Sep 2003 08:45:52 +0900,
Miles Bader wrote:
> 
> "Mark A. Flacy" <address@hidden> writes:
> > Miles> I've done somewhat precise calculations of the potential space
> > Miles> savings, and it's quite substantial on some trees, especially those
> > Miles> with lots of smallish files.  Time-savings probably would be less
> > Miles> noticable, because of the recent inode-state-caching speedups.
> > 
> > My belief is that the time-savings would be *negative*, which is one reason
> > why I'm extremely skeptical about the entire mess.
> 
> Why do you think that the time-savings would be negative?
> 
> For the no-cached-inode-state case, that seems obviously false, as
> reading lots of little files is just about always a lot slower than
> reading one still-pretty-little file; remember, ids are _short_, you can
> probably pack about 80 of them into a _single_ disk block on a typical
> ext2 filesystem.
> 
> For the cached-inode-state case, it's less clear, but as far as I can
> see you still win with one-.arch-ids-file-per-directory.  If one file in
> a directory changing means that you probably have to read the .arch-ids
> for that directory -- but you'd have to read the .arch-ids/foo.id file
> for that file in the many-.id-files case too, and if _more_ than one
> file in a directory changes, the one-.arch-ids-file-per-directory case
> starts to win big again.
> 
> Am I missing some obvious point???
> 
> > Which filesystem type were you using?  ext3?  
> 
> ext2/ext3
> 
> [Yes, they suck in many ways, but they're pretty much a fact of life for
> the near-term future]

        Not exactly. Many people already use ReiserFS. And yes it does _very_
 cpu-wise efficient handling of large amount of files and also tail packing.

> -Miles
> -- 
> I'd rather be consing.

regards, Samium Gromoff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]