Re: [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 15, 2016 at 10:35:07AM +0100, Jan Kara wrote:
> On Wed 13-01-16 16:40:58, Eric Sandeen wrote:
> > Actually, that's exactly what I thought would *need* to happen ... we already
> > have this weird 15-year-old split-brain quota interface, so if xfs and ext4
> > both need the same functionality, then we'd probably add both GETQUOTA2 and
> > XGETQUOTA2.  If we were doing this all from scratch, sure, but adding a new
> > handles-both-quota-types interface when every other operation is already split
> > between the two almost seems to make matters worse.
> 
> Well, currently GETQUOTA and XGETQUOTA (and all the other quotactls) are
> actually translated so they work regardless of the underlying filesystem.
> So the only difference between XFS and VFS quotactls is in the formatting
> of input/output structures. So from kernel POV it seems somewhat pointless
> to add two calls doing the same thing and differing just in the formatting
> of output - especially when we want the call to be extensible.
> 
> I agree that having a unified call means having a new structure for passing
> dquot info between kernel and userspace. So just for adding that one small
> feature you want it seems like an overkill. But when thinking about new
> extensible getquota quotactl it IMHO makes sense to unify the VFS/XFS split
> brain. Thoughts?

A new unified userspace quota API would be nice, but it's a
completely separate piece of work. We'd also need to do userspace
work to support it, so I think this is a valid medium term goal,
but not somethign that should gate the work Eric is doing.

i.e. it might be best to introduce a quotactl2 syscall for a
unified interface, such that the syscall itself has a flags
argument rather than having to jump through hoops to embed flags
in argument structures.....

FWIW, converting xfs_quota to use a new kernel API is trivial (half
an hour's work) as it already has a kernel API abstraction layer for
cross platform support. Hence we can quickly get userspace support
in place to test such a new kernel API...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux