[Top] [All Lists]

Re: [PATCH 02/18] fs: add FL_LAYOUT lease type

To: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH 02/18] fs: add FL_LAYOUT lease type
From: Christoph Hellwig <hch@xxxxxx>
Date: Wed, 7 Jan 2015 11:30:26 +0100
Cc: Christoph Hellwig <hch@xxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150106104652.49078615@xxxxxxxxxxxxxxxxxxxxxxxxx>
References: <1420561721-9150-1-git-send-email-hch@xxxxxx> <1420561721-9150-3-git-send-email-hch@xxxxxx> <20150106104652.49078615@xxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
On Tue, Jan 06, 2015 at 10:46:52AM -0800, Jeff Layton wrote:
> So with the current code, layouts are always whole-file?

layouts aren't whole-file, but layout recalls are.

> Tracking layouts as a lease-like object seems reasonable, but I'm not
> 100% thrilled with overloading all of the lease code with this. Perhaps
> it should be its own sort of object with a separate API to manage them?
> That would also make it easier to support layouts that are not for the
> entire file.
> To that end, it might be nice to hold off on taking this until we
> deprecate the i_flock list as we can then give layouts their own
> list_head in the file_lock_context. It would also make it easier to use
> a new sort of object to represent layouts.
> I just cleaned up that patchset last week, and will re-post it soon
> once I give it a bit of testing this week.

I'm happy to add support to your reworked locks/leases/etc handling
for this.  As for which one gets merged first I'd say which one
is in a mergeable shape earlier.  If you're confident to get your
rework in ASAP I'm happy to rebase it on top, otherwise doing it
the other way around sounds easier.

<Prev in Thread] Current Thread [Next in Thread>