Skip to contentSkip to conversation

Btrfs: add datacow flag in inode flag

PATCH Superseded liubo 5 participants 9 messages Mar 3, 2011 – Mar 17, 2011

Subsystems (2)
VFS Btrfs file system

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

liubo

author
#0 lore raw

PATCH 1/2 Btrfs: add datacow flag in inode flag

For datacow control, the corresponding inode flags are needed. This is for the following patch.

Signed-off-by Liu Bo <[email protected]>
---
 include/linux/fs.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
include/linux/fs.h +2 -0
index 63d069b..bef47ff 100644
@@ -353,6 +353,8 @@ struct inodes_stat_t {
 #define FS_TOPDIR_FL			0x00020000 /* Top of directory hierarchies*/
 #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 */
 
 #define FS_FL_USER_VISIBLE		0x0003DFFF /* User visible flags */
Signature · 1 line
1.6.5.2
#1 lore raw

Excerpts from liubo's message of 2011-03-03 03:35:42 -0500:

Quoted 14 lines

For datacow control, the corresponding inode flags are needed. This is for the following patch.

Signed-off-by Liu Bo <[email protected]>
---
 include/linux/fs.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
include/linux/fs.h +0 -0
index 63d069b..bef47ff 100644

include/linux/fs.h struct inodes_stat_t { · line 360

Quoted 8 lines
include/linux/fs.h +2 -0
@@ -353,6 +353,8 @@ struct inodes_stat_t {
 #define FS_TOPDIR_FL            0x00020000 /* Top of directory hierarchies*/
 #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 */
 
 #define FS_FL_USER_VISIBLE        0x0003DFFF /* User visible flags */

Hi everyone,

I'd like to go ahead and include these for btrfs to use. Are there objections or a different preferred interface?

-chris

#2 lore raw
Quoted 1 line · Chris Mason

Excerpts from liubo's message of 2011-03-03 03:35:42 -0500:

I'm fine with it. I'll defer the check for conflicts with extN-specific flags to Ted, though.

#3 lore raw
Quoted 9 lines · Christoph Hellwig

include/linux/fs.h struct inodes_stat_t { · line 358

Quoted 5 lines · Chris Mason

#define FS_EXTENT_FL 0x00080000 /* Extents */
#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

include/linux/fs.h +2 -0
+#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:

Quoted 9 lines
#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.

It also isn't clear to me whether the SNAPFILE_DELETED_FL and SNAPFILE_SHRUNK_FL really need to be persistent flags that are stored on disk, or if they are state flags that should only be stored in the in-memory inode? Not having them in the limited remaining inode flag space would be better... Amir?

Cheers, Andreas

#4 lore raw

Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400:

Quoted 21 lines · Christoph Hellwig
Quoted 9 lines · Chris Mason

include/linux/fs.h struct inodes_stat_t { · line 358

Quoted 5 lines

#define FS_EXTENT_FL 0x00080000 /* Extents */
#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

include/linux/fs.h +2 -0
+#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:

Quoted 8 lines
#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 */
Quoted 3 lines
Quoted 1 line

#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.

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.

-chris

#5 lore raw

On Wed, Mar 16, 2011 at 1:35 AM, Chris Mason <[email protected]> w= rote:

Quoted 5 lines

Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400:

Quoted 4 lines · Christoph Hellwig
Quoted 3 lines · Chris Mason
Quoted 2 lines

=A0#define FS_EXTENT_FL =A0 =A0 =A0 =A0 0x00080000 /* Extents */ =A0#define FS_DIRECTIO_FL =A0 =A0 =A0 0x00100000 /* Use direct i/=

o */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

+#define FS_NOCOW_FL =A0 =A0 =A0 =A0 =A00x00800000 /* Do not cow =

file */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

+#define FS_COW_FL =A0 =A0 =A0 =A0 =A0 =A00x01000000 /* Cow file =

*/

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

=A0#define FS_RESERVED_FL =A0 =A0 =A0 0x80000000 /* reserved for =

ext2 lib */

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

I'm fine with it. =A0I'll defer the check for conflicts with extN-=

specific flags

Quoted 5 lines
Quoted 5 lines
Quoted 1 line

to Ted, though.

Looking at the upstream e2fsprogs I see in that range:

Quoted 1 line

#define EXT4_EXTENTS_FL =A0 =A0 =A0 =A0 =A0 0x00080000 /* Inode us=

es extents */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_EA_INODE_FL =A0 =A0 =A0 =A0 =A00x00200000 /* Inode us=

ed for large EA */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_EOFBLOCKS_FL =A0 =A0 =A0 =A0 0x00400000 /* Blocks all=

ocated beyond EOF */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_FL =A0 =A0 =A0 =A0 =A00x01000000 /* Inode is=

a snapshot */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_DELETED_FL =A00x04000000 /* Snapshot is bein=

g deleted */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_SHRUNK_FL =A0 0x08000000 /* Snapshot shrink =

has completed */

Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT2_RESERVED_FL =A0 =A0 =A0 =A0 =A00x80000000 /* reserved=

for ext2 lib */

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

#define EXT2_FL_USER_VISIBLE =A0 =A0 =A00x004BDFFF /* User visible=

flags */

Quoted 2 lines
Quoted 2 lines

so there is a conflict with FS_COW_FL and EXT4_SNAPFILE_FL. =A0I 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 "C=
OW" 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.

Quoted 3 lines

In the btrfs case FS_COW_FL means to do COW even when there are no snapshots. =A0FS_NOCOW_FL means to do cow only when there are snapsho=

ts.

Quoted 1 line

I am interested in FS_NOCOW_FL as well, but for my implementation it wo= uld 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-fsdevel= " in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#6 lore raw
Quoted 21 lines · Amir Goldstein
Quoted 20 lines · Chris Mason

Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400:

Quoted 19 lines · Christoph Hellwig
Quoted 8 lines · Chris Mason

include/linux/fs.h struct inodes_stat_t { · line 358

Quoted 5 lines

#define FS_EXTENT_FL 0x00080000 /* Extents */
#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

include/linux/fs.h +2 -0
+#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:

Quoted 8 lines
#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 */
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

#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.

Fine with that, but it's up to Chris. :)

thanks,
liubo

Quoted 33 lines

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.

Quoted 3 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw

Excerpts from liubo's message of 2011-03-16 22:10:09 -0400:

Quoted 22 lines · Amir Goldstein
Quoted 21 lines · Chris Mason
Quoted 20 lines

Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -0400:

Quoted 19 lines · Christoph Hellwig
Quoted 8 lines · Chris Mason

Review

Quoted 5 lines

#define FS_EXTENT_FL 0x00080000 /* Extents */
#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

(quoted diff) +2 -0
+#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:

Quoted 8 lines
#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 */
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

#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.

Fine with that, but it's up to Chris. :)

I'd rather not conflict unless we're critically short on space.

Quoted 19 lines
Quoted 19 lines

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.

Quoted 3 lines

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.

Quoted 5 lines
Quoted 5 lines

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.

I'm not sure how the island of blocks idea can work with snapshots? Wouldn't the snapshot corrupt if anything in the island were changed?

-chris

#8 lore raw

On Thu, Mar 17, 2011 at 4:21 PM, Chris Mason <[email protected]> w= rote:

Quoted 3 lines

Excerpts from liubo's message of 2011-03-16 22:10:09 -0400:

Quoted 2 lines · Amir Goldstein
Quoted 1 line

On Wed, Mar 16, 2011 at 1:35 AM, Chris Mason <[email protected]=

Quoted 1 line · om> wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line

Excerpts from Andreas Dilger's message of 2011-03-15 18:06:49 -04=

00:

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines · Christoph Hellwig
Quoted 2 lines · Chris Mason
Quoted 1 line

=A0#define FS_EXTENT_FL =A0 =A0 =A0 =A0 0x00080000 /* Extents =

*/

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

=A0#define FS_DIRECTIO_FL =A0 =A0 =A0 0x00100000 /* Use direct=

i/o */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

+#define FS_NOCOW_FL =A0 =A0 =A0 =A0 =A00x00800000 /* Do not c=

ow file */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

+#define FS_COW_FL =A0 =A0 =A0 =A0 =A0 =A00x01000000 /* Cow fi=

le */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

=A0#define FS_RESERVED_FL =A0 =A0 =A0 0x80000000 /* reserved f=

or ext2 lib */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

I'm fine with it. =A0I'll defer the check for conflicts with ex=

tN-specific flags

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line

to Ted, though.

Looking at the upstream e2fsprogs I see in that range:

Quoted 1 line

#define EXT4_EXTENTS_FL =A0 =A0 =A0 =A0 =A0 0x00080000 /* Inode=

uses extents */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_EA_INODE_FL =A0 =A0 =A0 =A0 =A00x00200000 /* Inode=

used for large EA */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_EOFBLOCKS_FL =A0 =A0 =A0 =A0 0x00400000 /* Blocks =

allocated beyond EOF */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_FL =A0 =A0 =A0 =A0 =A00x01000000 /* Inode=

is a snapshot */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_DELETED_FL =A00x04000000 /* Snapshot is b=

eing deleted */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT4_SNAPFILE_SHRUNK_FL =A0 0x08000000 /* Snapshot shri=

nk has completed */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

#define EXT2_RESERVED_FL =A0 =A0 =A0 =A0 =A00x80000000 /* reser=

ved for ext2 lib */

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

#define EXT2_FL_USER_VISIBLE =A0 =A0 =A00x004BDFFF /* User visi=

ble flags */

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

so there is a conflict with FS_COW_FL and EXT4_SNAPFILE_FL. =A0I=

don't know the semantics of those two flags enough to say for sure whe=
ther it is reasonable that they alias to each other, but at first glanc= e "COW" and "SNAPSHOT" don't seem completely unrelated.

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

EXT4_SNAPFILE_FL indicates a special system snapshot file, so it h=

as

Quoted 15 lines
Quoted 4 lines
Quoted 2 lines

no equivalence relation with FS_COW_FL.
Please use 0x02000000 for FS_COW_FL.

Fine with that, but it's up to Chris. :)

I'd rather not conflict unless we're critically short on space.

Quoted 8 lines
Quoted 8 lines

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) snaps=

hot

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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 w=

hen

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

it is not needed.

Quoted 1 line

In the btrfs case FS_COW_FL means to do COW even when there are n=

o

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

snapshots. =A0FS_NOCOW_FL means to do cow only when there are sna=

pshots.

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

I am interested in FS_NOCOW_FL as well, but for my implementation =

it would mean

Quoted 1 line
Quoted 1 line
Quoted 1 line

do not do COW on rewrites even when there are snapshots, so a user=

can

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

create a pre-allocated
"island of blocks", which are pinned to a physical location, for r=

aw

Quoted 5 lines
Quoted 1 line
Quoted 1 line

VM image for example.

I'm not sure how the island of blocks idea can work with snapshots? Wouldn't the snapshot corrupt if anything in the island were changed?

It would corrupt, but only to the extent that the file to which you req= uested
NOCOW may contain newer data. It cannot contain uninitialized data, because truncating the file would leave it's blocks referenced by the s= napshot.

Think of a large database file, which is already replicated and hot bac= ked up
regularly. An arbitrary snapshot of that file will give you a copy for disaster recovery
at best. Not sure this is worth the effort of COWing it and fragmenting it beyond
recognition.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html