On 07/17/2015 12:57 PM, Carlos E. R. wrote:
Can it fail badly? Yes, it can.
My experience with BtrFS is not coloured by some prejudice against "The New" as I see in some people. I like progress. I like learning the new. But I've learnt this about BtrFS. When it works, within the boundaries it works, its great. The use cases you give for recovery from, for example, experimenting with Evergreen, good ones. I've lived with Big Iron that had similar capabilities to apply patches and then possibly back out of them. I'm aware of the upside. I welcome changes that make Linux more "professional", especially for the professional settings where it is replacing "Big Iron" as the x86 chips become more powerful. But lets face it; BtrFS is still in development. Things can still go wrong. Things still do go wrong. If you subscribe to appropriate mailing lists you'll see a couple of patches every day, sometimes as many as half a dozen. Many of them are to deal with actual 'problems'. I say 'problems' in quotes since they may not manifest as bugs yet, just as tests that fail. Heck there are still typos going on, use of "btrfs_error()" instead of "btrfs_err()". Humans are fallible, don't you know :-) I've had BtrFS go wrong. I'm used to the occasional glitch where I can't boot. That's what the rescue system is for. The one time I did have /boot as part of the RootFS the .snapshots did not help. The problem was with the BtrFS itself. I could mount it but whenever I tried to mkinitrd it flipped into RO. I ended up doing a reinstall. There might have been another avenue but the reinstall was the simplest. That reinstall was when I created the separate /boot. Since then I've had a few repeats of things going wrong, particularly when a new kernel comes along. Something seems to munge the MBR or GRUB. See my earlier postings on this matter. Even when the RootFS is going to go RO, with a separate /boot I can still rebuild a initrd and get a running system to do what amounts to "stage 2" maintenance. This is my experience; this is my problem that I've had to solve. Yes it is my environment, LVM with lots of LVs to handle things that many people put in the RootFS that I choose not to, /usr/share, /srv, /tmp. /var and similar. Why? Well, /tmp could be a tmpFS; its is on many systems and distributions, cleared on every reboot. There are, still, security reasons why it should be on a sperate FS and mounted nosuid. Well, /srv is sort of like /home for web applications. Well, /usr/share doesn't have a lot of relevance until the system is up and running. Well, /var is sort of like /tmp in places, it has /var/tmp. It also has /var/cache, which isn't relevant until the appropriate applications are running. So none of those are actually needed for boot. Leave them out of the RootFS. Heck, level them out of the initrd! What I'm NOT saying is that you shouldn't have snapshots of them. Quite the opposite. For many users I would think having /home as a BtrFS with change-based snapshoting every few minutes would be of more value than having it on the RootFS. I've no argument against using BtrFS for those other file systems other than I think snapshots of caches and scratch files (e.g compiler intermediate files that are promptly discarded after the next phase of the compiler runs) is a waste of time and resources. That should be better addressed by having an 'exclude' mechanism in the snapshot configuration. https://forums.opensuse.org/showthread.php/476706-Snapper-possible-to-exclud... The man page mentions filters but gives no examples. The examples I find on my system have no explanation and do not cover caches or scratch files. Let me also quote <quote src="https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_snapper_limits.html"> Currently SUSE Linux Enterprise Server cannot boot from Btrfs partitions. Therefore a separate partition for /boot is created upon the installation when using Btrfs for the system partition. Since /boot does not support snapshots, the following restrictions apply for YaST/zypper rollbacks: no rollback for any configuration changes on the boot loader ------------------------------------------------------------ The only file that can be rolled back is the boot loader configuration file in /etc. The main configuration files reside under /boot and cannot be rolled back. no complete rollback for Kernel installations --------------------------------------------- The Kernel itself and its initrd are installed in the /boot partition, whereas Kernel modules or sources are installed in /var/lib and /usr/src, respectively. Furthermore, each Kernel installation also changes the boot loader configuration files in /boot. So whenever you do a rollback that involves undoing a Kernel installation, you need to manually remove the Kernel and its initrd from /boot and adjust the boot loader configuration by removing the boot entry for the Kernel. </quote> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org