From: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> To: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org, dmonakhov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, Li Xi <pkuelelixi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 4/4] Adds ioctl interface support for ext4 project Date: Fri, 26 Sep 2014 08:22:21 +1000 [thread overview] Message-ID: <20140925222221.GI4945@dastard> (raw) In-Reply-To: <20140925134136.GE4592-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> On Thu, Sep 25, 2014 at 09:41:37AM -0400, Theodore Ts'o wrote: > On Thu, Sep 25, 2014 at 05:59:12PM +1000, Dave Chinner wrote: > > > Also I'm afraid we may quickly run out of > > > 32 available flags in xflags so we'd need to extend that. But all this > > > seems to be doable. > > > > The struct fsxattr was designed to be extensible - it has unused > > padding and enough space in the flags field to allow us to > > conditionally use that padding.... > > I agree that it would be useful for ext4 to support as much of the > XFS_IOC_GETXATTR/XFS_IOC_SETATTR as would make sense for ext4, and to > use that to set/get the project ID. (And that we should probably do > that as a separate set of patches that we could potentially go into > ext4 ahead of the project quota while it is undergoing testing and > review.) > > A few questions of Dave and other XFS folks: > > 1) If we only implement a partial set of the flags or other > functionality, are there going to be tools that get confused? i.e., > are there any userspace programs that will test for whether the ioctl > is supported, and then assume that some minimal set of functionality > must be implemented? No, I don't think they will get confused. The use of the flags is get/modify/set just like other flag setting functions. The extsize and projid fields are condition on the relevant flag being set on return from a get (i.e. projid is only valid if XFS_XFLAG_PROJID[_INHERIT] is set), and those fields are only considered valid on set if those flags are set by the application (or remain set as a result of the getxattr). Hence the applications that use the getxattr/setxattr interface correctly shouldn't care what set of flags and values the filesystem supports other than the specific flags the application needs the filesystem to understand. > 2) Unless I'm missing something, there is nothing that enforces that > fsx_pad must be zero. I assume that means that the only way you can > expand use of fields into that space is via a flag bit being consumed? Yup, that's exactly what I meant by "conditionally use the padding". Even if the padding was guaranteed to be zero, I'd strongly recommend a flag bit to indicate the application understands that the padding region has actual meaning to guard against buggy applications. Cheers, Dave. -- Dave Chinner david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Theodore Ts'o <tytso@mit.edu> Cc: adilger@dilger.ca, Jan Kara <jack@suse.cz>, linux-api@vger.kernel.org, xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>, dmonakhov@openvz.org, viro@zeniv.linux.org.uk, Li Xi <pkuelelixi@gmail.com>, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 4/4] Adds ioctl interface support for ext4 project Date: Fri, 26 Sep 2014 08:22:21 +1000 [thread overview] Message-ID: <20140925222221.GI4945@dastard> (raw) In-Reply-To: <20140925134136.GE4592@thunk.org> On Thu, Sep 25, 2014 at 09:41:37AM -0400, Theodore Ts'o wrote: > On Thu, Sep 25, 2014 at 05:59:12PM +1000, Dave Chinner wrote: > > > Also I'm afraid we may quickly run out of > > > 32 available flags in xflags so we'd need to extend that. But all this > > > seems to be doable. > > > > The struct fsxattr was designed to be extensible - it has unused > > padding and enough space in the flags field to allow us to > > conditionally use that padding.... > > I agree that it would be useful for ext4 to support as much of the > XFS_IOC_GETXATTR/XFS_IOC_SETATTR as would make sense for ext4, and to > use that to set/get the project ID. (And that we should probably do > that as a separate set of patches that we could potentially go into > ext4 ahead of the project quota while it is undergoing testing and > review.) > > A few questions of Dave and other XFS folks: > > 1) If we only implement a partial set of the flags or other > functionality, are there going to be tools that get confused? i.e., > are there any userspace programs that will test for whether the ioctl > is supported, and then assume that some minimal set of functionality > must be implemented? No, I don't think they will get confused. The use of the flags is get/modify/set just like other flag setting functions. The extsize and projid fields are condition on the relevant flag being set on return from a get (i.e. projid is only valid if XFS_XFLAG_PROJID[_INHERIT] is set), and those fields are only considered valid on set if those flags are set by the application (or remain set as a result of the getxattr). Hence the applications that use the getxattr/setxattr interface correctly shouldn't care what set of flags and values the filesystem supports other than the specific flags the application needs the filesystem to understand. > 2) Unless I'm missing something, there is nothing that enforces that > fsx_pad must be zero. I assume that means that the only way you can > expand use of fields into that space is via a flag bit being consumed? Yup, that's exactly what I meant by "conditionally use the padding". Even if the padding was guaranteed to be zero, I'd strongly recommend a flag bit to indicate the application understands that the padding region has actual meaning to guard against buggy applications. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-09-25 22:22 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-24 14:04 [PATCH 0/4] quota: add project quota support Li Xi 2014-09-24 14:04 ` [PATCH 1/4] Adds general codes to enforces project quota limits Li Xi 2014-09-24 16:08 ` Jan Kara [not found] ` <1411567470-31799-2-git-send-email-lixi-LfVdkaOWEx8@public.gmane.org> 2014-09-24 16:14 ` Christoph Hellwig [not found] ` <20140924161417.GA1978-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2014-09-24 17:10 ` Jan Kara [not found] ` <20140924171020.GF27000-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org> 2014-09-24 17:13 ` Christoph Hellwig [not found] ` <20140924171306.GA23874-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2014-09-24 17:37 ` Jan Kara 2014-09-30 20:07 ` Jan Kara 2014-09-24 14:04 ` [PATCH 2/4] Adds project ID support for ext4 Li Xi 2014-09-24 17:11 ` Jan Kara 2014-09-25 1:09 ` Li Xi 2014-09-24 14:04 ` [PATCH 3/4] Adds project quota " Li Xi [not found] ` <1411567470-31799-4-git-send-email-lixi-LfVdkaOWEx8@public.gmane.org> 2014-09-24 17:31 ` Jan Kara [not found] ` <20140924173123.GH27000-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org> 2014-09-25 1:28 ` Li Xi [not found] ` <CAPTn0cB8X3DYprX-oKCu8aV5OLLfJJ2rh9YvMY7re69gi1s-LA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-09-25 11:55 ` Jan Kara 2014-09-24 14:04 ` [PATCH 4/4] Adds ioctl interface support for ext4 project Li Xi 2014-09-24 16:25 ` Jan Kara 2014-09-24 16:25 ` Jan Kara 2014-09-24 16:26 ` Christoph Hellwig 2014-09-24 16:26 ` Christoph Hellwig 2014-09-24 17:01 ` Jan Kara 2014-09-24 17:01 ` Jan Kara 2014-09-25 7:59 ` Dave Chinner 2014-09-25 11:34 ` lixi 2014-09-25 11:34 ` lixi [not found] ` <C31A739F-4502-4B40-9AE3-F2FE49291657-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2014-09-26 0:10 ` Dave Chinner 2014-09-26 0:10 ` Dave Chinner 2014-09-26 2:45 ` Li Xi 2014-09-26 2:45 ` Li Xi 2014-09-25 13:41 ` Theodore Ts'o [not found] ` <20140925134136.GE4592-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2014-09-25 22:22 ` Dave Chinner [this message] 2014-09-25 22:22 ` Dave Chinner 2014-09-25 13:52 ` Jan Kara 2014-09-25 13:52 ` Jan Kara 2014-09-25 22:42 ` Dave Chinner 2014-09-26 12:01 ` Theodore Ts'o 2014-09-26 12:01 ` Theodore Ts'o 2014-09-29 15:55 ` Jan Kara 2014-09-29 15:55 ` Jan Kara 2014-09-25 7:26 ` Dave Chinner [not found] ` <1411567470-31799-5-git-send-email-lixi-LfVdkaOWEx8@public.gmane.org> 2014-09-24 16:43 ` Jan Kara
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140925222221.GI4945@dastard \ --to=david-fqsqvqoi3ljby3ivrkzq2a@public.gmane.org \ --cc=adilger-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org \ --cc=dmonakhov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \ --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \ --cc=jack-AlSwsSmVLrQ@public.gmane.org \ --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=pkuelelixi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=tytso-3s7WtUTddSA@public.gmane.org \ --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \ --cc=xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.