linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Francis Moreau <francis.moro@gmail.com>
To: linux-fsdevel@vger.kernel.org
Subject: Question regarding concurrent accesses through block device and fs
Date: Fri, 13 Feb 2009 21:25:39 +0100	[thread overview]
Message-ID: <m2hc2yulrw.fsf@gmail.com> (raw)

Hello,

I have a question regarding the page cache/buffer heads behaviour when
some blocks are accessed through a regular file and through the block
dev hosting this file.

First it looks like when accessing some blocks through a block device,
the same mechanisms are used as when reading a file through a file
system: the page cache is used.

That means that a block could be mapped by several buffers at the same
time.

I don't see any issues to this but looking at __block_prepare_write(),
it seems that we don't want this to happen since it does:

        [...]
        if (buffer_new(bh)) {
                unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr);                                                                                                                                               
                [...]
        }

where unmap_underlying_metadata() unmaps the blockdev buffer
which maps b_blocknr block. Also this call seems unneeded if
__block_prepare_write() is called when writing through the block
dev since we already know that the buffer doesn't exist (we are
here to create it).

Could anybody why this is needed at all ?

Also I'm wondering if the block is written first through the file
system (but the data are still in the page cache, not commited to the
disk) and another process try to read the same block through the
block device. Does it get stale data ?

thanks
-- 
Francis

             reply	other threads:[~2009-02-13 20:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13 20:25 Francis Moreau [this message]
2009-02-16  3:00 ` Question regarding concurrent accesses through block device and fs Niu_Yawei
2009-02-16  9:03   ` Francis Moreau

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=m2hc2yulrw.fsf@gmail.com \
    --to=francis.moro@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).