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

[Samium Gromoff]

At 27 Sep 2003 20:03:23 +0300,
Momchil Velikov wrote:
> 
> >>>>> "Tom" == Tom Lord <address@hidden> writes:
> 
>     >> From: Miles Bader <address@hidden>
> 
>     >> Um, which `Darkly Hinted Efficiency Improvements' are those?
> 
>     >> I've done somewhat precise calculations of the potential space savings,
>     >> and it's quite substantial on some trees, especially those with lots of
>     >> smallish files.  Time-savings probably would be less noticable, because
>     >> of the recent inode-state-caching speedups.
> 
>     Tom> Why _don't_ you regard this as a filesystem implementation 
> deficiency,
>     Tom> assuming it is really a problem at all?
> 
>     Tom> It seems to me that a 2-3:1 disk-usage:small-file-size ratio is not
>     Tom> _much_ of a problem, in the big picture, in terms of bucks-per-byte 
> of
>     Tom> storage.  To the degree that it is a problem today, we should expect
>     Tom> it to cease being so within the next couple of years.
> 
>     Tom> On the other hand, 2-3:1 i/o-traffic-size:small-file-size and
>     Tom> kernel-cache-usage:small-fize-size ratios would be very bad news and,
>     Tom> to the extent those things are true, indicate serious filesystem
>     Tom> problems.
> 
>     Tom> When people start saying "small files work so poorly that 
> applications
>     Tom> should implement filesystem-like functionality to handle them
>     Tom> themselves", something has gone very badly wrong either with their
>     Tom> rationale for that, or with the filesystems under consideration.
> 
>   Without claiming one or another piece of software has deficiencies,
> let's say existing filesystems are not the most efficient form of
> storage organization, as far as arch is concerned.
> 
>   So, what?
> 
>   Nobody's gonna rewrite the trusted filesystems.  Not everyone would
> trust his data to the new rewrites (how about no backup superblocks in
> reiser3).  There's no other option than using the filesystems in a

        AFAIK superblocks in reiser3 are not critical and contain minimim
 of information.

        I say so because i once have been hand-reviving an almost dead
 badblocked hdd-ful of information from a reiserfs, and i had to cope
 with creating a reiserfs superblock from scratch almost by hand :-)

> different way.
> 
>   Personally, I wouldn't be worried _that_ much about 10-15% space
> increase (though 57% is ridiculous), but about the time spent doing
> open(2) on thousands of files.
> 
> ~velco

regards, Samium Gromoff