[Top][All Lists]

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

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

From: Momchil Velikov
Subject: Re: [Gnu-arch-users] Re: give us a hand with arch
Date: 27 Sep 2003 20:03:23 +0300
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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


reply via email to

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