Rearrange i_flags to be consistent with FS_IOC_GETFLAGS
in [Kernel]
|
Prev: [PATCH] Rearrange i_flags to be consistent with FS_IOC_GETFLAGS
Next: soundcore_open: Reduce the area BKL coverage
From: David Howells on 6 Jul 2010 19:50 Dave Chinner <david(a)fromorbit.com> wrote: > I'd prefer generic flags are not dependent on fixed values from a > specific filesystem several layers down the storage stack. They're not so dependent. They're based on the FS_IOC_[GS]ETFLAGS ioctl which even XFS translates its flags for. These ioctl flags must now remain invariant. Whilst they might have originated as Ext2/3/4 flags, they're now independent of that. > Also, if the problem you are trying to solve is overhead of calculating the > flags for stat() on RISC architectures, then I'd argue that XFS is just as > important target for such an optimisation because it is widely used in small > ARM and MIPS based NAS appliances.... This can be argued one way or another, however aligning i_flags with something would probably be an improvement somewhere. Most of what I deal with is Ext3/4 based, and BTRFS-based is likely to become important too. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Chinner on 6 Jul 2010 22:00
On Wed, Jul 07, 2010 at 12:45:25AM +0100, David Howells wrote: > Dave Chinner <david(a)fromorbit.com> wrote: > > > I'd prefer generic flags are not dependent on fixed values from a > > specific filesystem several layers down the storage stack. > > They're not so dependent. History says otherwise. :) > They're based on the FS_IOC_[GS]ETFLAGS ioctl which > even XFS translates its flags for. Sure, because the ioctl flags values are derived from the ext2 on-disk format flags and hence don't match anything XFS related at all. > These ioctl flags must now remain > invariant. Whilst they might have originated as Ext2/3/4 flags, they're now > independent of that. Yes, the ioctl flags must remain invariant. OTOH, the generic inode flags (S_*) have no such invariant requirement and have a history of frequent change. IMO, that means some flags should not be tied to the value of a specific subsystem just so a subsystem specific optimisation can be made. It just seems like a dangerous layering violation to be making... Cheers, Dave. -- Dave Chinner david(a)fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |