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. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
