>>> On 1/12/2018 at 07:00 AM, Roger Evans <[email protected]> >>> wrote: > ?I have had a bad experience with btrfs and SLES 12.3: - the virtual machine > we'd put a lot of work into, wouldn't boot after expanding a btrfs, and had > to be recreated along with the work involved.
How was that expansion performed? If it was by using the tools provided in YaST, I hope that got reported in a service request to your provider. -snip- > Putting everything on one btrfs, means that if one of the disks > goes bad, everything is trashed. I'm not sure what you mean by "one btrfs." Unless I'm missing something, pretty much the same statement could be made about any file system that spans multiple DASD volumes. For a more information on using and working with btrfs, see https://www.suse.com/documentation/sles-12/singlehtml/stor_admin/stor_admin.html#sec.filesystems.major.btrfs > And if something fills up one of the > subvolumes, you can't even log in, since all the other volumes - like / and > /var, will also be full. This why btrfs supports quotas. From the URL above: 1. Enable quota support: sudo btrfs quota enable / 2. Get a list of subvolumes: sudo btrfs subvolume list / Quotas can only be set for existing subvolumes. 3. Set a quota for one of the subvolumes that was listed in the previous step. A subvolume can either be identified by path (for example /var/tmp) or by 0/SUBVOLUME ID (for example 0/272). The following example sets a quota of five GB for /var/tmp. sudo btrfs qgroup limit 5G /var/tmp To me, the big advantage of btrfs is snapshots. You can take a snapshot your system (less the subvolumes that are defined so that they are _not_ backed up), with a single command. With the integration of the snapper tool with zypper, and YaST, snapshots are taken before and after operations such as installing packages. The comparison capabilities of snapper allow you to see exactly what was changed between the two snapshots. This has some advantages in documenting what got changed, when for change control and auditing. If you inadvertently clobber a file, you can restore it from a snapshot. If you install maintenance and the system won't boot, you can easily reboot from the previous snapshot. It allows easy and repeatable testing. If you create a file system for testing purposes, and take a snapshot of it before starting, anything you do to that file system can be reversed instantly so that it goes back to its original state. Yes, you have to learn a lot of new commands and subcommands, and that means a new learning curve. I think the features we gain do outweigh that. And, due to the nature of the file system, as you point out certain tools such as "df" don't work the same way. The "btrfs filesystem df" and "btrfs filesystem du" commands are there for that. As always, when any SUSE customer has questions like this, in addition to posting here in the mailing list we encourage you to contact your sales or tech sales support person. That can help us figure out if a number of customers are seeing similar issues or having similar questions. It might even trigger a new white paper to be written such as was done for systemd. Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
