On Mon, Aug 3, 2015 at 10:22 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
В Mon, 3 Aug 2015 16:48:24 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-08-03 16:44, Anton Aylward wrote:
On 08/03/2015 10:36 AM, Carlos E. R. wrote:
Can't that do snapshots like BtrFS, like ext4? No, or not currently. Actually, XFS shares some devs and features with btrfs.
I recall reading that XFS could do snapshots but required (a) not to mount via uuid and (b) a "freeze" option. I also recall that the freeze option became kernel sported and could even be used with ext3, but I don't recall where I read that.
The name is the same, but the feature is distinctly different.
The purpose is to create a backup of the filesystem into a different device. It is not a COW (copy on write).
Actually it is exactly what CoW is. It is btrfs which is not CoW - more appropriate name is "redirect on write" or "write anywhere" (which is how oldest implementation is called).
There is no "copy" involved in btrfs write process.
COW semantically means deduplication, i.e. when multiple functions want resources that are indistinguishable, COW is the optimization that permits pointing all functions to a single copy of that resource. So it doesn't mean "when writing, duplicate, then write". It's originally a memory optimization. For file systems it means effectively "do not overwrite on write". And therefore Btrfs (and ZFS) is legitimately called a COW file system. Where XFS and ext234 do overwrites of existing files. On Btrfs, this extends to file system metadata too, with exception of superblocks, it's not overwritten when there are changes, even deletions. So a file delete involves a new write to free space, then walking back through the tree to remove blocks making them free space again as needed. As for freeze. I think this was originally an XFS invention, the gist is that it commits all pending writes to stable media and then makes the file system look cleanly unmounted while not unmounting it. That way an *LVM* snapshot can be taken, then the original is unfrozen and write can continue to happen, while the snapshot is used for doing backups that are consistent and unchanging. But now these days fsfreeze uses the FIFREEZE ioctl which also lets it work for ext4, and then some time ago there were patches to make it work for Btrfs also. https://lwn.net/Articles/379862/ on the original btrfs patches with explanation; patches have evolved in the actual kernel code https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/supe... starting at line 1258 has comments on the freezing stages. and also https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/bloc... starting at line 200 has comments on how the block device status is handled As for systemd problems, I'm definitely missing the emails that explain what the manifestation is. But I think it's understandable to be frustrated when confused, and it's understandable to be confused with significant changes like what systemd implements. Linux stuff is like any big city in the world that has good parts and stinky parts and always parts under some state of deconstruction and construction, I see no problem with expressing annoyance with such things, even in the face of futility. But it's a.) not in evidence and b.) not on topic for this list, to assign willful sabotage of peoples' workflows to particular development projects. *shrug* -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org