On 11/23/2014 01:31 AM, Andrei Borzenkov wrote:
В Sat, 22 Nov 2014 13:34:16 -0500 Anton Aylward
пишет: On 11/22/2014 09:38 AM, arvidjaar@gmail.com 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 configuration.. let me repeat: A SNAPSHOT IS NOT A BACKUP 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org