You are not logged in.
Using archinstall, I built a system yesterday using the default disk layout with the BTRFS file system. When I started examining the /etc/fstab and the subvolumes created. I was puzzled. In my mind, either the archinstall script didn't follow the Arch wiki recommended subvolume layout or maybe recommendations are changing.
in the fstab only the root and efi partitions were mounted. But checking btrfs su list / show the normal subvolumes except @, which is by convention is root.
What is going on?
Offline
I suspect the recommendations have changed, but I can't say I've found one recommended layout.
Could you point out which section mentions a recommended/prefered structure?
We have a pretty extensive discussion going on about what layout should be the default one: https://github.com/archlinux/archinstall/issues/781
The feature is also in early stages, so there's still plenty of time to chime in and nail the best default layout we can get! : )
Regarding /etc/fstab, not all entries were saved there, and root was still a conventional partition so /boot and / are the only two entries for now.
Again, that is being revised and discussed in the issue above - and some of the changes have already made it into the master branch.
Offline
I suspect the recommendations have changed, but I can't say I've found one recommended layout.
Could you point out which section mentions a recommended/prefered structure?
I'm really new to this whole btrfs topic but the recommended layout I've seen referenced most is here: https://wiki.archlinux.org/title/snappe … tem_layout
Offline
Torxed wrote:I suspect the recommendations have changed, but I can't say I've found one recommended layout.
Could you point out which section mentions a recommended/prefered structure?I'm really new to this whole btrfs topic but the recommended layout I've seen referenced most is here: https://wiki.archlinux.org/title/snappe … tem_layout
Ah, yea that's a snapper specific layout.
You also have timeshift to take into consideration: https://github.com/teejee2008/timeshift
Although timeshift is in AUR, we're trying to take both into consideration because they are (by the looks of it) the two biggest ones used with btrfs.
I'm also quite new to btrfs subvolumes, other than very simple ones in order to send states between two machines using btrfs-send
Offline
At his point in time while btrfs works, the methods to backing up and restoring are all over the map. I can see a developer installing something that messes up his system and needing to boot from an installation USB iso and moving snapshots around to fix things, but that's not easy for normal users. I know I finally was able to do it with my own btrfs send/receive methods, but even then I had to manually edits UUIDs because the rebuild created new ones.
At this point, I'm having to rely on what works with any Linux distro under any circumstances. Clonezillza. I can periodically boot Clonezilla, create an image of the boot drive on the spare space on the USB Clonezilla drive in about 8 minutes. Restoring that image is even quicker. This obviously is the quickest way to recover a bad SSD, but is quicker than trying to roll back snapshots.
IMHO, The difficulty in managing snapshots including roll-backs is holding back the general acceptance of btrfs.
Offline
At his point in time while btrfs works, the methods to backing up and restoring are all over the map. I can see a developer installing something that messes up his system and needing to boot from an installation USB iso and moving snapshots around to fix things, but that's not easy for normal users. I know I finally was able to do it with my own btrfs send/receive methods, but even then I had to manually edits UUIDs because the rebuild created new ones.
At this point, I'm having to rely on what works with any Linux distro under any circumstances. Clonezillza. I can periodically boot Clonezilla, create an image of the boot drive on the spare space on the USB Clonezilla drive in about 8 minutes. Restoring that image is even quicker. This obviously is the quickest way to recover a bad SSD, but is quicker than trying to roll back snapshots.
IMHO, The difficulty in managing snapshots including roll-backs is holding back the general acceptance of btrfs.
I've had some more success with ZFS (cursed be thy name) and their `zfs-send` in that regard.
I think snapper and timeshift helps quite a bit from the little I've played with it. I think the more usage btrfs gets it will become easier and easier.
Doing a full block-device clone and restore, is for obvious reasons pretty straight forward and will always be "less complicated" to wrap once head around : ) But I like this new technology.. I just need to teach my dinosaur brain that folders aren't folders, and snapshots is a thing etc etc ^^
Offline
There is one key area that I have not seen addressed with automatic snapshots before and after installs, like snap-pac, etc. They only address the 'root' configuration and not 'home'. Many times removing the package is easy, it's the stuff that get's installed in invisible directories in /home that causes problems. If you manually do the pre/post snapshot creations for both root and home, then you are protected. In my case the hourly automatic snapshots do both home and /.
Offline