On Wed, Mar 16, 2011 at 1:35 AM, Chris Mason <chris.ma...@oracle.com> wrote: > Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400: >> On 2011-03-15, at 2:57 PM, Christoph Hellwig wrote: >> > On Tue, Mar 15, 2011 at 04:26:50PM -0400, Chris Mason wrote: >> >> #define FS_EXTENT_FL 0x00080000 /* Extents */ >> >> #define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */ >> >> +#define FS_NOCOW_FL 0x00800000 /* Do not cow file */ >> >> +#define FS_COW_FL 0x01000000 /* Cow file */ >> >> #define FS_RESERVED_FL 0x80000000 /* reserved for ext2 lib */ >> > >> > I'm fine with it. I'll defer the check for conflicts with extN-specific >> > flags >> > to Ted, though. >> >> Looking at the upstream e2fsprogs I see in that range: >> >> > #define EXT4_EXTENTS_FL 0x00080000 /* Inode uses extents */ >> > #define EXT4_EA_INODE_FL 0x00200000 /* Inode used for large EA */ >> > #define EXT4_EOFBLOCKS_FL 0x00400000 /* Blocks allocated beyond >> > EOF */ >> > #define EXT4_SNAPFILE_FL 0x01000000 /* Inode is a snapshot */ >> > #define EXT4_SNAPFILE_DELETED_FL 0x04000000 /* Snapshot is being deleted >> > */ >> > #define EXT4_SNAPFILE_SHRUNK_FL 0x08000000 /* Snapshot shrink has >> > completed */ >> > #define EXT2_RESERVED_FL 0x80000000 /* reserved for ext2 lib */ >> > >> > #define EXT2_FL_USER_VISIBLE 0x004BDFFF /* User visible flags */ >> >> so there is a conflict with FS_COW_FL and EXT4_SNAPFILE_FL. I don't know >> the semantics of those two flags enough to say for sure whether it is >> reasonable that they alias to each other, but at first glance "COW" and >> "SNAPSHOT" don't seem completely unrelated.
EXT4_SNAPFILE_FL indicates a special system snapshot file, so it has no equivalence relation with FS_COW_FL. Please use 0x02000000 for FS_COW_FL. EXT4_SNAPFILE_DELETED_FL is a persistent state of a snapshot file, which is no longer available as a mountable device, but cannot be unlinked because it holds changed data sets needed by older snapshots. EXT4_SNAPFILE_SHRUNK_FL is a persistent state of a (deleted) snapshot file, which has undergone a "shrink" process to free all change sets not needed by older snapshots. The persistence of the flag is needed to avoid tedious shrinking when it is not needed. > > In the btrfs case FS_COW_FL means to do COW even when there are no > snapshots. FS_NOCOW_FL means to do cow only when there are snapshots. > I am interested in FS_NOCOW_FL as well, but for my implementation it would mean do not do COW on rewrites even when there are snapshots, so a user can create a pre-allocated "island of blocks", which are pinned to a physical location, for raw VM image for example. Thanks, Amir. -- 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
