From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: Xavier Bestel <xavier.bestel@free.fr>
Cc: ptb@it.uc3m.es, Anton Altaparmakov <aia21@cantab.net>,
david.lang@digitalinsight.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: (fwd) Re: [RFC] mount flag "direct"
Date: Wed, 4 Sep 2002 01:44:14 +0200 (MET DST) [thread overview]
Message-ID: <200209032344.g83NiEc29471@oboe.it.uc3m.es> (raw)
In-Reply-To: <1031093579.1073.6.camel@bip> from Xavier Bestel at "Sep 4, 2002 00:52:58 am"
"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
next prev parent reply other threads:[~2002-09-03 23:39 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-03 21:48 Peter T. Breuer
2002-09-03 22:19 ` Anton Altaparmakov
2002-09-03 22:42 ` Peter T. Breuer
2002-09-03 22:52 ` Xavier Bestel
2002-09-03 23:44 ` Peter T. Breuer [this message]
2002-09-04 7:06 ` Alexander Viro
2002-09-04 9:02 ` Peter T. Breuer
2002-09-04 11:05 ` Anton Altaparmakov
2002-09-04 11:39 ` Peter T. Breuer
2002-09-04 14:13 ` Anton Altaparmakov
2002-09-05 22:45 ` Daniel Phillips
2002-09-05 23:06 ` Anton Altaparmakov
2002-09-05 23:17 ` Daniel Phillips
2002-09-05 23:24 ` Anton Altaparmakov
2002-09-06 8:57 ` Peter T. Breuer
2002-09-06 9:08 ` Anton Altaparmakov
2002-09-06 9:17 ` Peter T. Breuer
2002-09-06 9:50 ` Lars Marowsky-Bree
2002-09-06 14:10 ` Peter T. Breuer
2002-09-06 13:20 ` Helge Hafting
2002-09-06 13:22 ` Rik van Riel
2002-09-06 13:53 ` Peter T. Breuer
2002-09-06 15:32 ` Rik van Riel
2002-09-06 14:25 ` Peter T. Breuer
2002-09-06 17:20 ` Anton Altaparmakov
2002-09-06 17:33 ` Daniel Phillips
2002-09-06 19:32 ` Anton Altaparmakov
2002-09-06 18:29 ` Peter T. Breuer
2002-09-06 19:30 ` Anton Altaparmakov
2002-09-09 16:30 ` Peter T. Breuer
2002-09-17 11:21 ` Anton Altaparmakov
2002-09-05 8:30 ` Helge Hafting
2002-09-05 8:43 ` David Lang
2002-09-05 14:24 ` Peter T. Breuer
2002-09-05 16:59 ` David Lang
2002-09-05 23:08 ` Daniel Phillips
2002-09-06 8:14 ` Ingo Oeser
2002-09-06 9:06 ` Helge Hafting
2002-09-04 12:49 ` Ragnar Kjørstad
2002-09-04 12:54 ` Peter T. Breuer
2002-09-04 13:22 ` Ragnar Kjørstad
2002-09-05 3:36 ` Edgar Toernig
2002-09-05 3:58 ` Alexander Viro
2002-09-05 15:59 ` [RFC] intent-based lookup (was: mount flag "direct") Andreas Dilger
2002-09-03 23:24 ` (fwd) Re: [RFC] mount flag "direct" David Lang
2002-09-04 4:27 ` Kevin O'Connor
2002-09-03 23:05 ` David Lang
[not found] <02Sep6.161154edt.62237@gpu.utcc.utoronto.ca>
2002-09-07 13:36 ` Peter T. Breuer
[not found] <20020909181724.GA31153@ravel.coda.cs.cmu.edu>
2002-09-09 18:58 ` Peter T. Breuer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200209032344.g83NiEc29471@oboe.it.uc3m.es \
--to=ptb@it.uc3m.es \
--cc=aia21@cantab.net \
--cc=david.lang@digitalinsight.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xavier.bestel@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®