On Sun, May 30, 2010 at 07:33:33PM +1000, Dmitri Nikulin wrote:
> On Sat, May 22, 2010 at 3:03 AM, Josef Bacik <jo...@redhat.com> wrote:
> > + while (1) {
> > + lock_extent(tree, start, end, GFP_NOFS);
> > + ordered = btrfs_lookup_ordered_extent(inode, start);
> > + if (!ordered)
> > + break;
> > + unlock_extent(tree, start, end, GFP_NOFS);
>
> 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 we
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, or
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
