On Sun, Dec 01, 2013 at 11:52:32PM -0500, Theodore Ts'o wrote: > On Mon, Dec 02, 2013 at 09:20:03AM +1100, Dave Chinner wrote: > > Ugh, that'll just screw it up even more. And if we put the ~10 XFS > > flags in there that aren't supported by FS_IOC_GETFLAGS, and all the > > others from other filesystems, we'll be out of space in a couple of > > kernel releases... > > What are the definitions XFS flags, and how is XFS currently > setting/getting them, out of curiosity? fs/xfs/xfs_dinode.h: /* * Values for di_flags * There should be a one-to-one correspondence between these flags and the * XFS_XFLAG_s. */ #define XFS_DIFLAG_REALTIME_BIT 0 /* file's blocks come from rt area */ #define XFS_DIFLAG_PREALLOC_BIT 1 /* file space has been preallocated */ #define XFS_DIFLAG_NEWRTBM_BIT 2 /* for rtbitmap inode, new format */ #define XFS_DIFLAG_IMMUTABLE_BIT 3 /* inode is immutable */ #define XFS_DIFLAG_APPEND_BIT 4 /* inode is append-only */ #define XFS_DIFLAG_SYNC_BIT 5 /* inode is written synchronously */ #define XFS_DIFLAG_NOATIME_BIT 6 /* do not update atime */ #define XFS_DIFLAG_NODUMP_BIT 7 /* do not dump */ #define XFS_DIFLAG_RTINHERIT_BIT 8 /* create with realtime bit set */ #define XFS_DIFLAG_PROJINHERIT_BIT 9 /* create with parents projid */ #define XFS_DIFLAG_NOSYMLINKS_BIT 10 /* disallow symlink creation */ #define XFS_DIFLAG_EXTSIZE_BIT 11 /* inode extent size allocator hint */ #define XFS_DIFLAG_EXTSZINHERIT_BIT 12 /* inherit inode extent size */ #define XFS_DIFLAG_NODEFRAG_BIT 13 /* do not reorganize/defragment */ #define XFS_DIFLAG_FILESTREAM_BIT 14 /* use filestream allocator */ Now, several of them overlap with the FS_IOC_GETFLAGS ioctls and are manipulated by them, but otherwise we have the XFS_IOC_FSGETXATTR/ XFS_IOC_FSSETXATTR ioctl pairs to manipulate them. And, to top it off, there XFS_IOC_FSGETXATTRA which retrieves information from the attribute fork rather than the data fork of the inode. The complex bit about some of these bits is they also have a value associated with them that is stored elsewhere in the inode. So by themselves, a bitmap interface is not sufficient to replace the XFS ioctl. However, a generic xattr based interface (i.e. name/value pair) would allow us to completely replace both the IOC_FSGETFLAGS and the XFS_IOC_FSGETXATTR interfaces with a single, common API... > > And FWIW, an attribute based approach means you don't need to get > > the flags before setting them to ensure you don't reset flags you > > don't care about, so it's safer from that perspective, too... > > Sure, but it will also be more complex, since we'll now have to parse > a whole series of strings and translate them into flags. ... and then > the m68k and other small device folks will start kvetching about how > the kernel gets bigger with every release, and how their poor > bootlader doesn't support kernels bigger than some arbitrary limit. If the embedded folks really care that much about the size of the kernels, then they can send patches to make it a config option. They already turn huge amounts of crap off (like CONFIG_BLOCK), so I don't see any reason why we need to care about that.... > > > The options and opportunities for bike shedding are endless. :-) > > > > I'm not interested in bike shedding - let's just solve the problem > > once and for all.... > > I'm curious what the XFS flags are because it's not clear to me > whether the total number of file system attributes that would be > legitimately fs generic are in the dozens, hundreds, or thousands. > There is such a thing as overdesign. We've got space on disk in the v3 XFS inode for another 65 individual inode flags. I can see at least another 5 XFS specific flags in the not too distant future, and maybe more. Indeed, I plan to use inode flags (and inheritable inode flags) for a lot of new stuff as well as making mount options fined grained per-inode configurable. Each of those is likely to involve 2 bits each to support inheritence from parent directories. So, while I'm not looking at hundreds of new inode flags, there's definitely scope in the foreseeable future for tens of new inode flags in XFS alone... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
