Dude wrote:There is no such thing as a logical copy nor indeed even files to btrfs: the copy-on-write happens at the block/inode level. Hence, after the snapshot, there is no way to determine which of the source and target files were actually the source or target.
1) Btrfs determines which snapshot maintains a logical copy and physically copies the file to the appropriate snapshot before it is modified.
a) Does it copy the complete file or work on the block level?Block.
b) What happens if the file is very large, e.g. 100 GB and there is not enough space on disk to copy the file to the snapshot directory?It doesn't do any copying: a snapshot is zero-cost, i.e. it consumes no storage until there is a change to the file in the snapshot.
c) Doesn't it have a huge negative impact on performance when a file needs to be copied before it can be altered?It's not copied before it can be altered: it's copied on write, i.e. the blocks that change during the fsync process are written out elsewhere on the disk. The entire file is not copied. Have you watched my btrfs presentation on YouTube? It does cover this. :)
I guess calling it "logical copy" was a bad choice. Would calling the initial snapshot a "hard link of a file system" be more appropriate?
I find it interesting that although the snapshot maintains the "hard link" to the original copy - I guess "before block image" (?) - there really is no negative performance impact.There is no such thing as an original copy: the snapshot is just a copy-on-write marker to the filesystem.
How does this work? Perhaps it is not overwriting the existing file, but rather creating a new file? So the snapshot still has the "hard link" to the original file, hence nothing changed for the snapshot? Simply a new file was created, and that's showing in the current file system?There is no file. There is no new file. There are only b-trees and blocks that, when they are changed (anywhere) are copy-on-write'd to elsewhere on the disk. There is no new file: there is a new inode and some new metadata to create a new file entry so that you can see it in the output of ls, but the actual data at this stage is the same as the old stuff.
<pre>df lies, particularly under btrfs. Don't use it. Don't trust it. Ignore it completely. Again, this is covered in my btrfs talk: you should use btrfs fi df / instead. There is also work in the mainline btrfs-progs development to make the output of btrfs fi df / easier to understand.
[root@vm004 /]# # df -h /
Dude wrote:btrfs can take some time to understand - I know I spent a few hours on the phone to Chris Mason (the original btrfs author) when preparing for that talk to make sure I got my head around exactly how btrfs actually works on disk. Use the btrfs wiki at http://btrfs.wiki.kernel.org and the documentation there. Also, there are specific btrfs mailing lists that are probably a better place to get detailed responses to questions than the Oracle forum. :)
Ok. I'm heading back into my hole and do more research. :-)