lkml.org 
[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: (fwd) Re: [RFC] mount flag "direct"
    Date
    "Anton Altaparmakov wrote:"
    [snip detailed description for which I am extremely grateful]
    > Ok, so to do a 1 byte read, we just had to perform over 10-20 reads from
    > very different disk locations (we are talking several seconds _just_ in
    > seek times, never mind read times!), we had to allocate a lot of memory
    > buffers to store metadata which we have read from disk temporarily, as well
    > as a lot of memory in order to be able to decompress the mapping pair
    > arrays which tell us the logical to physical block mapping.
    >
    > I am completely serious, we are talking at least hundreds of milliseconds
    > possibly even several seconds to read that single byte.
    >
    > What was that about 50GiB/sec performance again...?

    Let's maintain a single bit in the superblock that says whether any
    directory structure or whatever else we're worried about has been
    altered (ecch, well, it has to be a timestamp, never mind ..). Before
    every read we check this "bit" ondisk. If it's not set, we happily dive
    for our data where we expect to find it. Otherwise we go through the
    rigmarole you describe.

    Maybe our programs aren't going to do unexpected things with the file
    structures. Maybe our file systems satisfy assumptions like not
    moving existing data ondisk to make room for other data. I'd be willing
    to only consider such systems as sane enough to work with in a
    distributed shared environment.

    Can we improve the single-bit approach? Yes. The FS is a tree. When
    we make a change in it we can set a bit everywhere above the change,
    all the way to the root. When we observe the root bot changed, we
    can begin to retrace the path to our data, but abandon the retrace
    when the bit-trail we are following down towards our data turns cold.

    No?

    Peter
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site