On Wed, 4 Sep 2002, Peter T. Breuer wrote:
> "A month of sundays ago Xavier Bestel wrote:"
> [Charset ISO-8859-15 unsupported, filtering to ASCII...]
> > Le mer 04/09/2002 _ 00:42, Peter T. Breuer a _crit :
> >
> > > 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.
> >
> > Won't work. You would need an atomic read-and-write operation for that
>
> I'm proposing (elsewhere) that I be allowed to generate special block-layer
> requests from VFS, which act as "tags" to impose order on other requests
> at the shared disk resource. But ...
Get. Real.
VFS has no sodding idea of notion of blocks, let alone ordering needed for
a particular filesystem.
As soon as you are starting to talk about "superblocks" (on-disk ones, that
is) - you can forget about generic layers.
As far as I'm concerned, the feature in question is fairly pointless for
the things it can be used for and hopeless for the things you want to
get. Ergo, it's vetoed.
There is more to coherency and preserving fs structure than "don't cache
<something>". And issues involved here clearly belong to filesystem -
generic code simply has not enough information _and_ the nature of the
solution deeply depends on fs in question. IOW, your grand idea is
hopeless. End of discussion.
-
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/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:20 EST