[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: (fwd) Re: [RFC] mount flag "direct"
but now you are changing the on-disk format of each filesystem.

good luck in getting microsoft to change NTFS to allow you to do this (let
alone the others like XFS and JFS that are maintaining compatability with
other operating systems)

David Lang

On Wed, 4 Sep 2002, Peter T. Breuer wrote:

> Date: Wed, 4 Sep 2002 00:42:47 +0200 (MET DST)
> From: Peter T. Breuer <>
> To: Anton Altaparmakov <>
> Cc: Peter T. Breuer <>,,
> Subject: Re: (fwd) Re: [RFC] mount flag "direct"
> "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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.206 / U:28.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site