Andreas Dilger <adilger@xxxxxxxxx> 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. > > (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 -- 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
