I told him to do this, these flags aren't exposed anywhere are they? They are in-kernel specific stuff, please tell me we aren't exposing these via sysfs?
Josef On Fri, May 11, 2018 at 6:06 AM, David Sterba <dste...@suse.cz> wrote: > On Fri, May 11, 2018 at 12:56:10AM -0700, Omar Sandoval wrote: >> --- a/fs/btrfs/btrfs_inode.h >> +++ b/fs/btrfs/btrfs_inode.h >> @@ -23,13 +23,12 @@ >> #define BTRFS_INODE_ORPHAN_META_RESERVED 1 >> #define BTRFS_INODE_DUMMY 2 >> #define BTRFS_INODE_IN_DEFRAG 3 >> -#define BTRFS_INODE_HAS_ORPHAN_ITEM 4 >> -#define BTRFS_INODE_HAS_ASYNC_EXTENT 5 >> -#define BTRFS_INODE_NEEDS_FULL_SYNC 6 >> -#define BTRFS_INODE_COPY_EVERYTHING 7 >> -#define BTRFS_INODE_IN_DELALLOC_LIST 8 >> -#define BTRFS_INODE_READDIO_NEED_LOCK 9 >> -#define BTRFS_INODE_HAS_PROPS 10 >> +#define BTRFS_INODE_HAS_ASYNC_EXTENT 4 >> +#define BTRFS_INODE_NEEDS_FULL_SYNC 5 >> +#define BTRFS_INODE_COPY_EVERYTHING 6 >> +#define BTRFS_INODE_IN_DELALLOC_LIST 7 >> +#define BTRFS_INODE_READDIO_NEED_LOCK 8 >> +#define BTRFS_INODE_HAS_PROPS 9 > > Please keep such changes minimal and only relevant to the purpose of the > patch, in this case just remove the BTRFS_INODE_HAS_ORPHAN_ITEM . > > There will be a hole left in the sequence but this is not a problem and > we're going to convert the defines to enums. The defines are prone to > error if the nubmers get accidentally duplicated, like it happend not so > long ago with the fsinfo::fs_flags. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
