You are not logged in.

#1 2022-04-01 16:57:41

dawnofman
Member
Registered: 2019-07-26
Posts: 140

[solved] is it good practice to create subvolumes installing to BTRFS?

Recently I installed manjaro (yes yes I know I know, this is not manjaro; just picking an example) on another computer and selected BTRFS which ended with the following /etc/fstab:

UUID=whatever /boot/efi      vfat                  umask=0077 0 2
UUID=whatever /              btrfs subvol=/@,      defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 1
UUID=whatever /var/cache     btrfs subvol=/@cache, defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 2
UUID=whatever /var/log       btrfs subvol=/@log,   defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 2
UUID=whatever /home          btrfs                 defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 2

Since I never installed arch to BTRFS before (always EXT4) and given that using subvolumes will allow more efficient size management I wonder what will be the proper way to doing so in arch: what subvolumes do you advice/consider should be created ? (I mean, in the end probably will be a matter of user preference, but all-in-all maybe there are good practices I am not aware of).

I have read:

- BTRFS wiki entry which points to a more straightforward introduction to subvolumes
- subvolumes on BTRFS sys admin guide which explains pros and cons of subvolumes and/or nested-subvolumes
- man mkfs.btrfs for the details on how to create subvolumes: straighforward; no examples given

What I did not come across yet, is a specific example on how to install the system like in the example I provided before and before I start creating subvolumes the wrong way I want to get them right to avoid re-installing/reformatting once again.

Needless to say, any advice, be generic or quite-specific, will be welcome.

Last edited by dawnofman (2022-06-15 03:16:00)

Offline

#2 2022-04-02 05:05:28

CarbonChauvinist
Member
Registered: 2012-06-16
Posts: 413
Website

Re: [solved] is it good practice to create subvolumes installing to BTRFS?

Maybe look into how openSUSE sets this up as they have been using BTRFS as default for some time now, this blog post goes into more detail caveat emptor.

Like you already pointed out, most of the considerations will be individual to the person installing, but with that being said Snapper is also a factor. The arch wiki on Snapper has a suggested layout which you can also review and add to as needed.


"the wind-blown way, wanna win? don't play"

Offline

#3 2022-04-02 22:32:28

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved] is it good practice to create subvolumes installing to BTRFS?

CarbonChauvinist wrote:

Maybe look into how openSUSE sets this up as they have been using BTRFS as default for some time now, this blog post goes into more detail caveat emptor.

Like you already pointed out, most of the considerations will be individual to the person installing, but with that being said Snapper is also a factor. The arch wiki on Snapper has a suggested layout which you can also review and add to as needed.

Thanks for pointing me in the right direction: the first link you provided creating openSUSE-style btrfs root partition & subvolumes proved very insightful.

I will be formatting my drive as following:

sgdisk --new='1:4096:+1G ' --typecode='1:EF00' --change-name='1:system-EFI' '/dev/sd?'; ###  1 GB system-EFI for FAT32
sgdisk --new='2:    :+90G' --typecode='2:8304' --change-name='2:system-NIX' '/dev/sd?'; ### 90 GB system-NIX for BTRFS including sub-volumes for var, tmp, root, home

mkfs.fat           -F '32'      -n 'system-EFI' '/dev/sd?1'; ### FAT32 … do not use any outdated file-system: FAT → VFAT → FAT32 (this one)
mkfs.btrfs --csum='crc32c' --label='system-NIX' '/dev/sd?2'; ### BTRFS

And installing with the following script (showing the relevant part only for this topic):

strFAT32options='rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount'; ### my default options to mount FAT-32 file-systems
strBTRFSoptions='defaults,noatime,space_cache,ssd,compress=zstd,commit=120'; ### my default options to mount BTRFS file-systems

strVolumeSystemEFIUUID='c3c15aa8-9577-4103-b1e2-e4f554d7fd15';  ### ie: should be [/dev/sd?1/]
strVolumeSystemNIXUUID='f47191f1-cd5c-4a21-8c8c-39c40412e77a';  ### ie: should be [/dev/sd?2/]

strVolumeSystemEFI="/dev/disk/by-partuuid/${strVolumeSystemEFIUUID}";
strVolumeSystemNIX="/dev/disk/by-partuuid/${strVolumeSystemNIXUUID}";

strSystemTMP='/mnt/system/'; ### ie: the target root file-system to which we'll be installing to

if ! /usr/bin/test -d "${strSystemTMP}"; then ### target root file-system not yet available

   /usr/bin/mkdir "${strSystemTMP}";

fi;

/usr/bin/mount --options="${strBTRFSoptions}" "${strVolumeSystemNIX}" "${strSystemTMP}"; ### ie: on a volatile mount-point on the live image file-system (A)

/usr/bin/btrfs subvolume create "/${strSystemTMP}/@";
/usr/bin/btrfs subvolume create "/${strSystemTMP}/@/var";
/usr/bin/btrfs subvolume create "/${strSystemTMP}/@/tmp";
/usr/bin/btrfs subvolume create "/${strSystemTMP}/@/root";
/usr/bin/btrfs subvolume create "/${strSystemTMP}/@/home";

/usr/bin/mkdir --mode='755'  "${strSystemTMP}boot/";
/usr/bin/mkdir --mode='755'  "${strSystemTMP}var/";
/usr/bin/mkdir --mode='1777' "${strSystemTMP}tmp/";
/usr/bin/mkdir --mode='700'  "${strSystemTMP}root/";
/usr/bin/mkdir --mode='700'  "${strSystemTMP}home/";

/usr/bin/mount --options="${strFAT32options}"               "${strVolumeSystemEFI}" "${strSystemTMP}boot/";
/usr/bin/mount --options="${strBTRFSoptions},subvol=@/var"  "${strVolumeSystemNIX}" "${strSystemTMP}var/";
/usr/bin/mount --options="${strBTRFSoptions},subvol=@/tmp"  "${strVolumeSystemNIX}" "${strSystemTMP}tmp/";
/usr/bin/mount --options="${strBTRFSoptions},subvol=@/root" "${strVolumeSystemNIX}" "${strSystemTMP}root/";
/usr/bin/mount --options="${strBTRFSoptions},subvol=@/home" "${strVolumeSystemNIX}" "${strSystemTMP}home/";

### at this point I guess I should be able to proceed with the installation as usual

The openSUSE link advice to also use other sub-volumes such as /opt and /srv which I'm not creating since this particular installation won't use them at all -in fact, I will be removing those directories to clean the root directory a bit.

A couple of doubts:

- When I mount the main file-system I specify my options with the --options switch as expected ... look for (A) in the above script
- When I later mount the sub-volumes I am also using the same switch ... I do not know if this is necessary at this point since I think/guess the sub-volumes will be inheriting those options ... am I right ? (I remember have read somewhere that the options only mattered to the parent sub-volume, ie: (A) in my example, but I don't remember where did I read it thus I cannot provide a link.

Do you think I am getting something wrong at this point ?

Offline

#4 2022-04-02 23:11:52

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved] is it good practice to create subvolumes installing to BTRFS?

CarbonChauvinist wrote:

Maybe look into how openSUSE sets this up as they have been using BTRFS as default for some time now, this blog post goes into more detail caveat emptor.

Like you already pointed out, most of the considerations will be individual to the person installing, but with that being said Snapper is also a factor. The arch wiki on Snapper has a suggested layout which you can also review and add to as needed.

Something else I forgot on my previous reply: do you know why the @ on the names of sub-volumes ?

There is no mention on the need of @ in the BTRFS sysadmin guide.

Just wondering where do they come from.

Offline

#5 2022-04-17 17:38:41

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved] is it good practice to create subvolumes installing to BTRFS?

dawnofman wrote:

Something else I forgot on my previous reply: do you know why the @ on the names of sub-volumes ?

There is no mention on the need of @ in the BTRFS sysadmin guide.

Just wondering where do they come from.

A reply-to-myself for anyone else wondering the same: no, there is no need for it.

Offline

Board footer

Powered by FluxBB