From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Andrew Morton <akpm@osdl.org>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: lkml <linux-kernel@vger.kernel.org>,
fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Advice sought on how to lock multiple pages in ->prepare_write and ->writepage
Date: Thu, 27 Jan 2005 10:48:44 +0000 [thread overview]
Message-ID: <1106822924.30098.27.camel@imp.csi.cam.ac.uk> (raw)
Hi,
I am looking for advice on how to lock multiple pages in ->prepare_write
and ->writepage. Here is an example scenario where I need to do this:
We have a mounted NTFS volume with a cluster, i.e. logical block, size
of 64kiB on a system with a PAGE_CACHE_SIZE of 4kiB. This means we can
allocate space in a file in multiples of 64kiB (aligned to 64kiB
boundaries). Now take a sparse file and the user is attempting to do a
write into a hole in this file and lets say the write is in the middle
of a sparse cluster (logical block).
This means that the NTFS driver will receive a write request either via
->prepare_write or ->writepage for a page which lies in the middle of
the cluster (logical block).
NTFS driver now allocates a cluster on disk to fill the hole.
Now the driver needs to write zeroes between the start of the newly
allocated cluster and the beginning of the write request as well as
between the end of the write request and the end of the cluster.
In ->prepare_write we are holding i_sem on the file's inode as well as
the page lock on the page containing the write request.
In ->writepage we are only holding the page lock on the page containing
the write request.
We also need to keep in mind that there may be other already dirty pages
n the affected region that have not hit ->writepage yet or in the most
complicated case that are hitting ->writepage simultaneously on a
different cpu or due to preempt. Such pages that are already uptodate
would need to not be zeroed.
A further complication is that any of those pages might be currently
under a ->readpage() and hence locked but they would never be marked
dirty for writeback unless we do it now.
I also need to ensure that any pages I zero also make it to disk
(presumably simply marking these pages dirty would be the Right Way(TM)
to do this).
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent ->readpage() will cause me to miss a page and thus end up
with non-initialized/random data on disk for that page?
Thanks a lot in advance for any advice/suggestions you can give me...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
next reply other threads:[~2005-01-27 10:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 10:48 Anton Altaparmakov [this message]
2005-01-28 0:58 ` Advice sought on how to lock multiple pages in ->prepare_write and ->writepage Andrew Morton
2005-01-28 5:06 ` Nathan Scott
2005-01-28 11:08 ` Anton Altaparmakov
2005-01-28 22:53 ` Bryan Henderson
2005-01-31 22:00 ` Nathan Scott
2005-01-31 23:46 ` Bryan Henderson
2005-02-01 0:10 ` Sonny Rao
2005-02-01 1:32 ` Bryan Henderson
2005-02-01 16:49 ` Sonny Rao
2005-02-01 1:29 ` Matthew Wilcox
2005-01-28 10:43 ` Anton Altaparmakov
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=1106822924.30098.27.camel@imp.csi.cam.ac.uk \
--to=aia21@cam.ac.uk \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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