| title: | Re metadata copied data not copied |
|
Hi everyone,
Here is an expanded example which is how I imagined COW would handle
changes to the files data ("file contents"). One can pretend it is an
attempt to inject malicious code into /bin/sh (e.g. file1 is /bin/sh).
[METADATA] -- DATA
[file1 perms olduser:oldgroup] -- file contents
# cp file1 file2
[file1 perms olduser:oldgroup "COW"]
-- file contents
[file1 perms olduser:oldgroup "COW"] /
(A "COW" flag is set in btrfss (hidden) metadata.)
# chown newuser:newgroup file2
[file1 perms olduser:oldgroup "COW"]
-- file contents
[file1 perms newuser:newgroup "COW"] /
(chown, chmod, others? are not "writes" to file contents, so file
contents dont need to be copied-on-write yet.)
# cat newcontent file2
[file1 perms olduser:oldgroup] -- file contents
[file2 perms newuser:newgroup] -- file contents + newcontent
(File contents are modified. This is a "write" that triggers COW. The
file contents are copied and then modified. Metadata for file2 are hooked
up to copied then modified file contents. "COW" flag is cleared.)
It would work, but it is slightly different from how btrfs works. There
are two ways to read COW (copy on write):
1) Before changing something, make a copy of the old data and put it
somewhere else. Then overwrite the original location.
2) Dont ever overwrite the original location, write somewhere new
instead. The old copy stays in the original location.
Btrfs does #2.
Does the choice #1 or #2 change whether the extended example works or not?
It seems as though either way makes sense for the example given...?
The bcp command creates a second inode that points to the same data
extents as the first inode. So, modifications to the inodes themselves
(such as chown, chmod, touch etc) dont touch the data extents.
Modifications to the data extents go through the COW mechanism to make
sure we dont overwrite the originals.
To me it sounds like if cp were replaced with bcp, then btrfs would behave as
I imagined in my example...
Why is a "bcp" separate from cp needed? Is it because with cp btrfs
doesnt "know" a simple copy is being made, but just gets a stream of data to
write to disk?
Is it possible to update cp to do the btrfs ioctl automatically, or must the
commands always remain separate because there are situations where it would
be a problem for the file contents to be COW? (It seems to me the fact that
the data contents are COW would be transparent to userland apps, so the bcp
ioctl could be built in to cp.)
Looking forward to (a stable) btrfs!
Eager User. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
