1

What is the difference between FS_IOC_GETFLAGS and FS_IOC_FSGETXATTR ioctl commands? What flags do both return?

Improve this question

2 Answers 2

Reset to default
2

In the Linux context, FS_IOC_GETFLAGS and FS_IOC_FSGETXATTR both retrieve inode flags.

GETFLAGS is the older ioctl, and comes originally from ext2 (again, in Linux); it manipulates a 32-bit value and has thus limited expansion capabilities — there aren’t many unused bits available.

FSGETXATTR comes from XFS, and was recently (2016) moved from XFS to the shared VFS layer. It uses a data structure, struct fsxattr, which allows for more values and more expansion.

Both of these, and the meanings of the data they return, are defined in linux/fs.h. The GETFLAGS flags are additionally documented in ioctl_iflags(2). Common values between the two correspond mostly to GETFLAGS flags which were historically supported by XFS: “append only”, “no atime updates”, “no dump”, “immutable”, and “synchronous updates”.

Note that in both cases support varies from one file system to another, and some flags aren’t actually supported at all.

Improve this answer
2
  • Thank you, Stephen. Great explanation. One question more, how to set these xflags via linux cli? Commented Jun 8, 2018 at 13:23
  • Two CLI tools supports fsxattr-specific flags, as far as I’m aware: chattr allows setting project-related flags, and xfs_fsr allows settings XFS flags (but only on XFS). Some tools (Docker, Ceph...) support fsxattr flags internally, but I don’t know whether they allow manipulating them externally. Commented Jun 8, 2018 at 14:25
-2

FS_IOC_GETFLAGS is an interface to access BSD style file flags. It just uses a much worse interface than *BSD, since you need to open the file in order to get access. *BSD has these informations in struct stat, so if you like to get the related information in /dev/ entries on Linux, you may cause a tape drive to rewind it's medium.

FS_IOC_FSGETXATTRis a similar but apparently incompatible interface from XFS that seems to be supported by ext4 as well since September 2015.

Conclusion: both interfaces are badly designed since they need to open the file in order to get access. The maintainers do not seem to care about their interfaces since they do not inform important users like star which is able to back up and restore the flags from the FS_IOC_GETFLAGSinterface.

Improve this answer
4
  • Not sure who’s downvoting these answers... Do you have a pointer to the extended attribute proposal in question? Commented Jun 8, 2018 at 14:32
  • Hi, I fixed my text, it seems that I was mistaken since the name of the second call is very similar to the withdrawn xattr interface. There seem to be some people who follow me and downvote all my answers. This was the POSIX.1e ACL draft. You may try: simson.net/ref/1997/posix_1003.1e-990310.pdf Commented Jun 8, 2018 at 14:53
  • Thanks, I wondered if you were referring to POSIX.1e. The difference in interfaces between the BSDs and Linux is indeed unfortunate... Commented Jun 8, 2018 at 15:01
  • well, Linux could fix the interface without becoming incompatible to older Linux versions: It would just need to implement and document that an open() with the open flag O_SEARCH but without O_RDONLY or O_WRONLY will be allowed to issue a FS_IOC_GETFLAGS iotcl() but will not cause any side effects in the open() call. O_SEARCH has been introduced in POSIX from my proposal similar to an open method from UNOS that did not have stat() but only fstat(). Commented Jun 8, 2018 at 15:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.