From: Chris Mason <chris.mason@oracle.com>
To: Dmitri Nikulin <dnikulin@gmail.com>
Cc: Josef Bacik <josef@redhat.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/6] Btrfs: do aio_write instead of write
Date: Tue, 1 Jun 2010 09:19:22 -0400 [thread overview]
Message-ID: <20100601131922.GJ8980@think> (raw)
In-Reply-To: <AANLkTiljjXsML35vHoUc-XXTrbOft6TO1KKZyYdj3HUn@mail.gmail.com>
On Sun, May 30, 2010 at 07:33:33PM +1000, Dmitri Nikulin wrote:
> On Sat, May 22, 2010 at 3:03 AM, Josef Bacik <josef@redhat.com> wrote=
:
> > + =A0 =A0 =A0 while (1) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 lock_extent(tree, start, end, GFP_NOF=
S);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ordered =3D btrfs_lookup_ordered_exte=
nt(inode, start);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!ordered)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 unlock_extent(tree, start, end, GFP_N=
OFS);
>=20
> Is it ok not to unlock_extent if !ordered?
> I don't know if you fixed this in a later version but it stuck out to=
me :)
The construct is confusing. Ordered extents track things that we have
allocated on disk and need to write. New ones can't be created while w=
e
have the extent range locked. But we can't force old ones to disk with
the lock held.
So, we lock then lookup and if we find nothing we can safely do our
operation because no io is in progress. We unlock a little later on, o=
r
at endio time.
If we find an ordered extent we drop the lock and wait for that IO to
finish, then loop again.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-06-01 13:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-21 17:03 [PATCH 1/6] fs: allow short direct-io reads to be completed via buffered IO Josef Bacik
2010-05-21 17:03 ` [PATCH 2/6] direct-io: add a hook for the fs to provide its own submit_bio function Josef Bacik
2010-05-21 17:03 ` [PATCH 3/6] direct-io: do not merge logically non-contiguous requests Josef Bacik
2010-05-22 1:47 ` Mike Fedyk
2010-05-22 14:02 ` Josef Bacik
2010-05-21 17:03 ` [PATCH 4/6] fs: kill blockdev_direct_IO_no_locking Josef Bacik
2010-05-21 17:03 ` [PATCH 5/6] Btrfs: add basic DIO read/write support Josef Bacik
2010-05-21 17:03 ` [PATCH 6/6] Btrfs: do aio_write instead of write Josef Bacik
2010-05-23 8:31 ` Shi Weihua
2010-05-23 23:59 ` Josef Bacik
2010-05-27 3:06 ` liubo
2010-05-27 3:13 ` liubo
2010-05-27 12:59 ` Chris Mason
2010-05-28 1:42 ` liubo
2010-05-30 9:33 ` Dmitri Nikulin
2010-06-01 13:19 ` Chris Mason [this message]
2010-06-01 23:20 ` Dmitri Nikulin
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=20100601131922.GJ8980@think \
--to=chris.mason@oracle.com \
--cc=dnikulin@gmail.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@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).