From: "Peter T. Breuer" <ptb@it.uc3m.es>
Message-Id: <200209032344.g83NiEc29471@oboe.it.uc3m.es>
Subject: Re: (fwd) Re: [RFC] mount flag "direct"
In-Reply-To: <1031093579.1073.6.camel@bip> from Xavier Bestel at "Sep 4, 2002
 00:52:58 am"
To: Xavier Bestel <xavier.bestel@free.fr>
Date: Wed, 4 Sep 2002 01:44:14 +0200 (MET DST)
Cc: ptb@it.uc3m.es, Anton Altaparmakov <aia21@cantab.net>,
       david.lang@digitalinsight.com,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Reply-To: ptb@it.uc3m.es
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1739
Lines: 38

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

> (read previous timestamp and write a special timestamp meaning
> "currently writing this block"), and you don't have that.

I believe we only have to write it when we change metadata, and
read it when we are about to use cached metadata. Racing to write it
doesn't matter, since the most recent wins, which is what we want.

Umm .. there is a bad race to read. We can read, think nothing has
changed, then read and find things shifted out from under. We need
to take a FS global lock when reading! Umm. No. We need to take
a global lock against changing metadata when reading, not against
arbitrary changes. And that can be done by issuing a tag request.

It's late.

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/