Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls

[Theodore Ts'o <tytso@mit.edu>]

On Fri, Nov 29, 2013 at 04:27:48PM +1100, Dave Chinner wrote:
> > Sure, I was thinking about doing something like this instead:
> > 
> > #define FS_IOC_GETFLAGS_WIDE		_IOR('f', 32, __u64)
> > #define FS_IOC_SETFLAGS_WIDE		_IOR('f', 32, __u64)
> > 
> > And I agree that a good reason to do this is to get 64 bits worth of
> > attributes....
> 
> Why create a new ioctl for getting these generic attributes out of
> the kernel? Isn't that the problem xstat() is supposed to solve?

Well, need to set and get these file flags, and historically we've
used a bitmask for this purpose.  And these aren't so much attributes
as flags, really, i.e:

#define FS_IMMUTABLE_FL			0x00000010 /* Immutable file */
#define FS_APPEND_FL			0x00000020 /* writes to file may only append */

etc.  Some of these files are pretty file-system specific (and indeed
this ioctl was intended originally for ext[234]):

#define FS_JOURNAL_DATA_FL		0x00004000 /* Reserved for ext3 */

But because some of these flags ended up being file system generic, for example:

#define FS_NOATIME_FL			0x00000080 /* do not update atime */

(as well as the FS_IMMUTABLE_FL and FS_APPEND_FL), this ioctl was
hijacked into a generic ioctl for all file systems.  The problem is
some of these flags have become file system specific --- for other
file systems, e.g:

#define FS_NOCOW_FL			0x00800000 /* Do not cow file */

On the other hand, some of these are currently fs-specific, but could
eventually become used by more than one file system, e.g.:

#define	FS_COMPR_FL			0x00000004 /* Compress file */

> And if it's truly generic stuff, then a syscall pair with enough
> bitmap space for the forseeable future is more appropriate than a
> new ioctl....

You mean something where we take a char * and a length?  We could, but
(a) it would be incompatible with existing FS_IOC_[GS]ETFLAGS, and (b)
it's not clear the complexity is worth it.

Regards,

						 - Ted

P.S. One of the reasons why there's a certain amount of wastage with
this ioctl is that some of the bit fields were originally used as the
file system level encouding for the file flags in ext[234].  This
could be argued to be bad design, but we didn't ask for this
ext[234]-specific ioctl to get hijcaked for use by other file systems,
either.  If we do create the 64-bit version of this ioctl, we won't
have this problem with the upper 32-bits --- and indeed it would be
preferable if other file-system specific flags for btrfs, f2fs, et.al,
got allocated from the MSB end of the 64-bit ioctl.

Or we could design an entirely new ioctl that uses a completely new
bitmask allocation scheme, or even a plan9 style set of ascii messages
which are passed back and forth between userspace and the kernel ---
or even insist that btrfs was wrong, that they shouldn't have been
allocating flags out of this legacy ioctl, but should have been using
the existing xattr interface with a new namespace that was either
btrfs specific or a new vfsflag namspace.

The options and opportunities for bike shedding are endless.   :-)