lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 23 Jan 2014 16:06:29 -0800
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	Ben Myers <bpm@....com>, xfs@....sgi.com,
	Li Xi <pkuelelixi@...il.com>
Subject: Re: [RFC] directory quota survey on xfs

On Fri, Jan 24, 2014 at 09:32:05AM +1100, Dave Chinner wrote:
> On Tue, Jan 21, 2014 at 03:07:06PM +0800, Zheng Liu wrote:
> > Hi Dave,
> > 
> > On Thu, Jan 16, 2014 at 08:32:07AM +1100, Dave Chinner wrote:
> > > On Wed, Jan 15, 2014 at 11:03:22AM -0700, Andreas Dilger wrote:
> > > > quotas (to keep compatibility for existing XFS deployments), but add
> > > > support into quota-tools so that it is usable by all filesystems.
> > > 
> > > Well, yes. If you are writing a generic quota tool, then it needs to
> > > support all filesystems. We already have a fully featured quota API
> > > that can provide this support - it's the API that XFS has been using
> > > since it was ported to Linux.  We have the opportunity to unify the
> > > quota APIs that ext4 and XFS, so we should take the opportunity
> > > while it is here.  Don't create a new API for ext4 simply because of
> > > NIH syndrome.
> > 
> > These days I was thinking about your comment that uses quotactl API to
> > communicate the userspace tool with the kernel.  But I am still
> > confusing about your comment that unifies the quota API between ext4 and
> > XFS.
> > 
> > Now we have two flag sets in quotactl(2).  One (Q_QUOTAON, Q_GETQUOTA,
> > etc...) is used by extN file system (I am not sure whether other file
> > systems use these flags or not), and another (Q_XQUOTAON, Q_XGETQSTAT,
> > etc...) is used by XFS.
> 
> I'm talking about making ext4 be able to use Q_XQUOTAON,
> Q_XGETQSTAT, etc.
> 
> > In xfs_quota it uses an ioctl(2) to get/set/check project id,
> 
> Right, because that's a filesystem specific operation that has no
> equivalent in any other filesystem at this point in time. Same for
> the project inheritence inode flag.
> 
> You're going to need to add such an interface to ext4 to do this, so
> add a generic ioctl and wire XFS up to it as well. This is kind
> of why I want a generic xattr namespace for inode flags/attribute
> at the VFS - so we don't have to keep inventing new
> ioctl/fcntl interfaces to make this sort of functionality common
> between different filesystems - we just define a new attribute
> string and values and let individual filesystems handle how they
> store them.

I wonder, do you have an opinion on my patches to do just that?  Since it was
an RFC I only wired up ext4; first with string-based xattrs[1] and again as a
(namespace, flags) integer tuple[2].  Jan disliked juggling strings around
(they don't bring me oodles of happiness either), Christoph doesn't like the
magic xattrs, and Ted seemed lukewarm so I'm inclined to fix up the other FSes
a la [2].

(...and please everybody don't co-opt this thread for inode flags any more than
I have.)

--D

[1] http://lkml.org/lkml/2014/1/6/1059 (fs: xattr-based FS_IOC_[GS]ETFLAGS interface)
[2] http://lkml.org/lkml/2014/1/7/534 (fs: new FS_IOC_[GS]ETFLAGS2 interface)
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ