Mailinglist Archive: opensuse (1620 mails)

< Previous Next >
Re: [opensuse] Re: btrfs (with subvolumes) & raid-1 setup
On 11/23/2014 01:31 AM, Andrei Borzenkov wrote:
В Sat, 22 Nov 2014 13:34:16 -0500
Anton Aylward <opensuse@xxxxxxxxxxxxxxxx> пишет:

On 11/22/2014 09:38 AM, arvidjaar@xxxxxxxxx wrote:
I think this the only setup that makes sense in the long run. I do not know
if yast supports it though.

Please explain why you feel it is the only setup that makes sense.

You install new updates and create snapshot before it. Your primary
filesystem is in btrfs root and snapshot goes in some subvolume
(/.snapshot/backup or anything). You reboot and find that your system
does not boot or is not usable. What are your options to go back to
working backup?

That's an interesting strawman argument but I don't see it as being
realistic or common.

And it has nothing whatsoever to do with root as its own subvolume.

1. Copy files from backup snapshot back into root.

It is time consuming, defeats space saving by inflating root and may
not be that trivial if directory structure changed.

You seem confused as to the purpose of a snapshot and and confused as to
why you should want to reboot after a zypper update.

The only time you need to update following a 'update' is of you have
replaced or rebuilt the kernel. That is a special case.

2. Mount backup snapshot as root.

So we are exactly in the situation we discuss. We end up with root on
subvolume without explicit support from system management tools.

That is not so.
There is a mistake in your thinking.

Sometimes I get a DUH reaction reading this list and then I realise that
not everyone has had the opportunity to be exposed to "Big Iron
administrative practices. Snapshoting of the 'before' state when
applying changes date back to Big Iron.

Snapshots are about being able to roll back updates.

They are not backups.

We have snapshotting on BtrFS but not on, for example, ReiserFS, because
of the COW mechanism

if you walk, for example, the /etc tree and the
/.snapshot/<number>/snapshot/etc/ tree side by side you will see that
for each file they appear to be hardlinked. Actually the snapshot
version ow COWed.

If it really were a backup then it would be a copy, and making a full
copy of the file system for every snapshot will rapidly consume your
disk. The state info is bad enough.

The purpose of a snapshot is so you can roll back the change(s)
resulting from a zypper update. Or possibly, of you have regular by the
clock snapshotting enabled, from changes you make by had to the

let me repeat:


If you have badly screwed what is in /etc and rendered your system
unbootable because of that that mounting a snapshot is not a fix.

3. Set default volume to backup snapshot

Probably just as unsupported as 2; also it raises hairy questions like
"what / now refers to, like in /.snapshot".

If your root is on subvolume from the very beginning and all tools are
known to support it, fallback is trivial. You are on /@/root-current,
you create /@/root-backup; if boot from /@/root-current fails, just
point to /@/root-backup and continue to work.

That is completely unjustified and not logical.

Firstly in recovery mode there is no need for the root of the file
system you are 'mending' to be a subvolume. As I've said before, the
'mending' from recovery of an unbootable systems is a well established
procedure and works with any file system. It works, I know from my own
experience, with BtrFS without the need for any subvolume trickery.

Having booted from the recovery CD/DVD of your choice you can mount the
hard disk RootFS at /mnt. You can do this with ANY file system,
ext[234], ReiserFS, XFS or BtrFS.

All the tools available on your recovery system are still available.

If it is a screwed system config that is the reason your system is
unbootable then the snapshots look just like a subdirectory and you'll
have to fire which one has the prior actual copy.

My experience with 'unbootable' has more to do with what's in /boot.
Fixing that is quite another matter. It also is independent of the file
system being used.

All in all you have not presented an argument why a BtrFS has to be a
subvolume of itself. The arguments you give are not about 'necessity;
what you are trying to achieve with these 'mounts' can be done without
the need for subvolumes.

Snapshots with BtrFS are an emergent property of the COW mechanism.
They are not copies in the conventional sense. Their purpose is for
rolling back changes, not for recovery from catastrophic disaster.

If you are using the COW mechanism as a substitute for proper backups --
as seems to be the case with the scenarios you describe -- then you are
mistaken and going to complicate your life if you do have a disaster
that necessitates recovery.

\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups