Andreas Dilger [off-list ref] wrote:
I saw your patch to that effect. I'm of mixed feelings about this, since
the S_* flags have traditionally been changed on an ad-hoc basis and I don't
necessarily want to let this leak into the on-disk format of these flags for
ext*.
One way to ensure that this holds true is to have a compile-time assertion
that the respective S_* flags match FS_*_FL and EXT_*_FL.
Something like this:
#if S_SYNC != FS_SYNC_FL || \
S_IMMUTABLE != FS_IMMUTABLE_FL || \
S_APPEND != FS_APPEND_FL || \
S_NOATIME != FS_NOATIME_FL || \
S_DIRSYNC != FS_DIRSYNC_FL
#error Ext2/3/4 assumes these equivalences
#endif
would do the trick.
quoted
(5) How often are these flags required? E.g. does it make more sense to
keep them as an additional result, or does it make sense to stick them
in the kstat and xstat structs, knowing that these are allocated on the
kernel stack maybe as three times if an ecryptfs file?
If they aren't requested by userspace, the cost is mostly irrelevant. I
think on OSX these flags are returned for every "ls" call, to mark the
inodes with xattrs every time.
I suppose. I was thinking that they may have to be retrieved from the server.
More concerning to me is the effect of adding more fields to the kstat struct.
Nonetheless, having these flags around may be useful to CIFS, Samba, NFS and
NFSD as various of them may appear in those protocols. Certainly, SMB passes
a bit indicating compression around (ATTR_COMPRESSED).
David