linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin Jambor" <jambormartin@gmail.com>
To: "Linux FS Development List" <linux-fsdevel@vger.kernel.org>
Subject: Shouldn't unmap_underlying_metadata() mark buffers not uptodate?
Date: Sun, 7 May 2006 17:13:58 +0200	[thread overview]
Message-ID: <9615ac9b0605070813n3cda5d5fx43567bb25d22341f@mail.gmail.com> (raw)

Hi,

we are developing a filesystem that writes data to disk in a manner
similar to mpage_writepages(). At the same time, the data can be read
back using bread(). Today we have encountered a situation where we
were reading old data. When we had a look at the disk with hexedit we
also saw old data and only after a reboot we saw the last stuff that
was written to the blocks in question.

Apparently, the reads were fulfilled with cached data in bdev mapping
that were no longer actually up to date.

We have managed to get rid of the problem when we implemented our own
version of unmap_underlying_metadata that also marked the buffer and
page in question as not up to date.

So our questions are:

a) is this likely to happen in other filesystems using
mpage_writepages()? If not, why?

For example, when you read a block directly from the block device,
then filesystem's mpage_writepages() overwrites it and finally you
read that same block from the device again, is it possible that you
read the old data again?

b) shouldn't unmap_underlying_metadata() therefore clear the buffers
uptodate flag?

c) or is there some other kernel (preferably exported :-) function
that we should use?

TIA

Martin

                 reply	other threads:[~2006-05-07 15:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=9615ac9b0605070813n3cda5d5fx43567bb25d22341f@mail.gmail.com \
    --to=jambormartin@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).