Mailinglist Archive: opensuse (878 mails)

< Previous Next >
Re: [opensuse] Another example of deliberate systemð supporters deliberately sabotaging previously working software...
On Mon, Aug 3, 2015 at 10:22 AM, Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В Mon, 3 Aug 2015 16:48:24 +0200
"Carlos E. R." <robin.listas@xxxxxxxxxxxxxx> пишет:

-----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/super.c?id=refs/tags/v4.2-rc5
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/block_dev.c?id=refs/tags/v4.2-rc5
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >