Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

[Darrick J. Wong]

On Fri, May 11, 2018 at 04:41:45PM +0200, David Sterba wrote:
> On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> > On 5/11/18 9:32 AM, Chris Mason wrote:
> > > On 11 May 2018, at 10:10, David Sterba wrote:
> > > 
> > >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> > >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> >  Move the btrfs label ioctls up to the vfs for general use.
> > 
> >  This retains 256 chars as the maximum size through the interface, which
> >  is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> >  label size.
> > 
> >  Signed-off-by: Eric Sandeen 
> >  Reviewed-by: Andreas Dilger 
> >  Reviewed-by: David Sterba 
> > >>>
> > >>> No objections (and it obviously ought to go through btrfs tree).
> > >>
> > >> I can take it through my tree, but Eric mentioned that there's a patch
> > >> for xfs that depends on it. In this case it would make sense to take
> > >> both patches at once via the xfs tree. There are no pending conflicting
> > >> changes in btrfs.
> > > 
> > > Probably easiest to just have a separate pull dedicated just for this 
> > > series.  That way it doesn't really matter which tree it goes through.
> > 
> > Actually, I just realized that the changes to include/uapi/linux/fs.h are 
> > completely
> > independent of any btrfs changes, right - there's nothing wrong w/ 
> > redefining
> > the common ioctl under a different name in btrfs.  So the fs.h patch could 
> > go first,
> > through the xfs tree since it'll be using it.
> > 
> > Once the common ioctl definition goes in, then btrfs can change to define 
> > its ioctls to
> > the common ioctls, or act on them directly as my patch did, etc.  Would 
> > that be
> > a better plan?  IOWs there's no urgent need to coordinate a btrfs change.
> 
> Agreed, I like that plan.

Ok, I'll await a new series with all the patches that Eric wants to
squeeze through the xfs tree.  I don't mind carrying the btrfs changes
too, so long as they're one-liners and the btrfs maintainers ack/rvb it.

--D
--
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

Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

[David Sterba]

On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> On 5/11/18 9:32 AM, Chris Mason wrote:
> > On 11 May 2018, at 10:10, David Sterba wrote:
> > 
> >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>  Move the btrfs label ioctls up to the vfs for general use.
> 
>  This retains 256 chars as the maximum size through the interface, which
>  is the btrfs limit and AFAIK exceeds any other filesystem's maximum
>  label size.
> 
>  Signed-off-by: Eric Sandeen 
>  Reviewed-by: Andreas Dilger 
>  Reviewed-by: David Sterba 
> >>>
> >>> No objections (and it obviously ought to go through btrfs tree).
> >>
> >> I can take it through my tree, but Eric mentioned that there's a patch
> >> for xfs that depends on it. In this case it would make sense to take
> >> both patches at once via the xfs tree. There are no pending conflicting
> >> changes in btrfs.
> > 
> > Probably easiest to just have a separate pull dedicated just for this 
> > series.  That way it doesn't really matter which tree it goes through.
> 
> Actually, I just realized that the changes to include/uapi/linux/fs.h are 
> completely
> independent of any btrfs changes, right - there's nothing wrong w/ redefining
> the common ioctl under a different name in btrfs.  So the fs.h patch could go 
> first,
> through the xfs tree since it'll be using it.
> 
> Once the common ioctl definition goes in, then btrfs can change to define its 
> ioctls to
> the common ioctls, or act on them directly as my patch did, etc.  Would that 
> be
> a better plan?  IOWs there's no urgent need to coordinate a btrfs change.

Agreed, I like that plan.
--
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

Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

[Eric Sandeen]

On 5/11/18 9:32 AM, Chris Mason wrote:
> On 11 May 2018, at 10:10, David Sterba wrote:
> 
>> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
 Move the btrfs label ioctls up to the vfs for general use.

 This retains 256 chars as the maximum size through the interface, which
 is the btrfs limit and AFAIK exceeds any other filesystem's maximum
 label size.

 Signed-off-by: Eric Sandeen 
 Reviewed-by: Andreas Dilger 
 Reviewed-by: David Sterba 
>>>
>>> No objections (and it obviously ought to go through btrfs tree).
>>
>> I can take it through my tree, but Eric mentioned that there's a patch
>> for xfs that depends on it. In this case it would make sense to take
>> both patches at once via the xfs tree. There are no pending conflicting
>> changes in btrfs.
> 
> Probably easiest to just have a separate pull dedicated just for this series. 
>  That way it doesn't really matter which tree it goes through.

Actually, I just realized that the changes to include/uapi/linux/fs.h are 
completely
independent of any btrfs changes, right - there's nothing wrong w/ redefining
the common ioctl under a different name in btrfs.  So the fs.h patch could go 
first,
through the xfs tree since it'll be using it.

Once the common ioctl definition goes in, then btrfs can change to define its 
ioctls to
the common ioctls, or act on them directly as my patch did, etc.  Would that be
a better plan?  IOWs there's no urgent need to coordinate a btrfs change.

-Eric
--
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

Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

[Chris Mason]

On 11 May 2018, at 10:10, David Sterba wrote:


On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:

On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:

Move the btrfs label ioctls up to the vfs for general use.

This retains 256 chars as the maximum size through the interface, 
which

is the btrfs limit and AFAIK exceeds any other filesystem's maximum
label size.

Signed-off-by: Eric Sandeen 
Reviewed-by: Andreas Dilger 
Reviewed-by: David Sterba 


No objections (and it obviously ought to go through btrfs tree).


I can take it through my tree, but Eric mentioned that there's a patch
for xfs that depends on it. In this case it would make sense to take
both patches at once via the xfs tree. There are no pending 
conflicting

changes in btrfs.


Probably easiest to just have a separate pull dedicated just for this 
series.  That way it doesn't really matter which tree it goes through.


-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