Announcement

Collapse
No announcement yet.

Beginner's guide to BTRFS

Collapse
This topic is closed.
X
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    Which Ubuntu server version are you using?
    One from here:

    https://www.ubuntu.com/download/server

    Or, one from the alternate site?
    If you require advanced networking and storage features such as; LVM, RAID, multipath, vlans, bonds, or re-using existing partitions, you will want to continue to use the alternate installer.

    https://www.ubuntu.com/download/alte...rver-installer

    I'd recommend the amd ISO from the alternate site:

    http://cdimage.ubuntu.com/releases/1...rver-amd64.iso
    "I would rather have questions that can't be answered, than answers that can't be questioned." ― Richard Feynman

    Comment


      #47
      I used the first one, https://www.ubuntu.com/download/server
      But let me play around with the subvols a bit more, the more I think about this the more I agree that in a server environment it would make sense to let the admin decide what snapshots are required. Hence, by design not a bug.
      Just found this "subvolid" mount option which may do what we want: mount -o subvolid=261 /dev/sdd1 /btrfs/

      Comment


        #48
        Never use
        btrfs subvolume set-default

        to change the root id to some value other than 5. IOW, don't use that command on Ubuntu based distros.

        You can mount any Btrfs subvolume under your <ROOT_FS>, which is already running, but you are depending on @ and @home as your base of operations. They are mounted in fstab to create / and /home. But even though you think you may have a @ & @home operating system on /dev/sdd1 you won't get it by mounting 261.
        Last edited by GreyGeek; Oct 05, 2018, 01:13 PM.
        "I would rather have questions that can't be answered, than answers that can't be questioned." ― Richard Feynman

        Comment


          #49
          http://manpages.ubuntu.com/manpages/...bvolume.8.html
          A subvolume is a part of filesystem with its own independent file/directory hierarchy.
          Subvolumes can share file extents. A snapshot is also subvolume, but with a given initial
          content of the original subvolume.

          Note
          A subvolume in btrfs is not like an LVM logical volume, which is block-level snapshot
          while btrfs subvolumes are file extent-based.

          A subvolume looks like a normal directory, with some additional operations described
          below. Subvolumes can be renamed or moved, nesting subvolumes is not restricted but has
          some implications regarding snapshotting.

          A subvolume in btrfs can be accessed in two ways:

          · like any other directory that is accessible to the user

          · like a separately mounted filesystem (options subvol or subvolid)

          In the latter case the parent directory is not visible and accessible. This is similar to
          a bind mount, and in fact the subvolume mount does exactly that.

          A freshly created filesystem is also a subvolume, called top-level, internally has an id
          5. This subvolume cannot be removed or replaced by another subvolume. This is also the
          subvolume that will be mounted by default, unless the default subvolume has been changed
          (see subcommand set-default).
          (BUT - Ubuntu has warned against doing that!)

          A snapshot is a subvolume like any other, with given initial content. By default,
          snapshots are created read-write. File modifications in a snapshot do not affect the files
          in the original subvolume.

          set-default [<subvolume>|<id> <path>]
          Set the default subvolume for the (mounted) filesystem.

          Set the default subvolume for the (mounted) filesystem at <path>. This will hide the
          top-level subvolume (ie. the one mounted with subvol=/ or subvolid=5). Takes action on
          next mount.
          Bottom line: DO NOT use the set-default command to change the subvolid to any other value except 5.
          Last edited by GreyGeek; Oct 05, 2018, 01:19 PM.
          "I would rather have questions that can't be answered, than answers that can't be questioned." ― Richard Feynman

          Comment


            #50
            Yes, I figured that 5 is an important id, was reading up here: https://www.linux.com/learn/how-crea...s-linux-part-2
            And I can see from my laptops setup that id 5 is my root
            /dev/mapper/nvme0n1p3_crypt on / type btrfs (rw,noatime,ssd,space_cache,autodefrag,subvolid=25 7,subvol=/@)
            /dev/mapper/nvme0n1p3_crypt on /mnt type btrfs (rw,relatime,ssd,space_cache,autodefrag,subvolid=5 ,subvol=/)
            /dev/mapper/nvme0n1p3_crypt on /home type btrfs (rw,relatime,ssd,space_cache,autodefrag,subvolid=1 016,subvol=/@home)
            But I am experimenting on a VM and took a snapshot so I can happily screw things up :-)
            Just need to somehow create a @ which points to /, map this one as / in fstab and then I should be in business?
            Last edited by Thomas00; Oct 05, 2018, 01:21 PM.

            Comment


              #51
              Continuing my little btrfs journey :-)
              Have to say this was quite a learning experience

              First of all, forget about my "is this a bug" talk above.
              I am pretty sure it's by design, the desktop installer of Ubuntu/Kubuntu just does a few things automatically which a server guy will have to do manually.

              Here's what I believe the Kubuntu installer does different to the Ubuntu server installation:
              1. Create the btrfs filesystem followed by creating the @ and @home subvolumes. Like any new subvolume they will be empty.
              2. Instead of copying the OS files to / they will be copied to the respective subvolumes. Aside from the two subvolumes FS_Root remains empty.
              3. Updates grub to reflect booting from /@ instead of /

              Pretty straightforward when done as part of the installation.

              To achieve the same result manually a few more steps are required:

              1. Create subvolume: btrfs subvolcume create /@
              -> Now you got an empty @ subvolume under /

              2. Change grub.cfg: nano /boot/grub/grub.cfg -> rootflags=subvol=@
              -> For now let's only update the default menuentry 'Ubuntu' one. Once you sucesfully converted the machine you can do the others.
              "linux /boot/vmlinuz-4.15.0-36-generic root=UUID=f6ca238e-c8b6-11e8-8c8d-bcaec52979b7 ro rootflags=subvol=@ maybe-ubiquity"

              3. Grab the UUID of your / via blkid
              4. Update /etc/fstab to reflect booting from /@ : nano /etc/fstab ...defaults, subvol=@ 0 0
              5. Add FS_Root to /etc/fstab: UUID=<yourUUID> /mnt (You can do this later as well)

              6. Copy the OS content of / into /@ : rsync -av --exclude @ --exclude proc --exclude sys / /@
              -> I am excluding proc and sys because they produce errors and are dynamic anyway

              7. Manually create the folders excluded from rsync: mkdir /@/sys, mkdir /@/proc
              -> This is critical! If these folders are not there during boot you bricked your install. I know what I am talking about :-)
              -> Now we have a exact copy of the OS in /@

              8. Reboot
              ----- Drum roll ----
              -> If the machine came up again your OS is running from /@ instead /
              Run ll / and if you can't see @ you successfully switched your root to @
              Check with mount | grep btrfs -> subvol needs to be =/@ not =/

              root@homeserver:~# mount | grep btrfs
              /dev/sdd2 on / type btrfs (rw,noatime,ssd,space_cache,autodefrag,subvolid=25 9,subvol=/@)
              /dev/sdd2 on /mnt type btrfs (rw,relatime,ssd,space_cache,autodefrag,subvolid=5 ,subvol=/)
              root@homeserver:~# ll /
              total 32
              drwxr-xr-x 1 root root 224 Oct 8 08:01 ./
              drwxr-xr-x 1 root root 224 Oct 8 08:01 ../
              drwxr-xr-x 1 root root 2430 Jul 25 23:04 bin/
              drwxr-xr-x 1 root root 620 Oct 6 17:46 boot/
              -> But the machine did not yet boot from /@ !!!

              9. Update grub
              update-grub
              grub-install /dev/sdx
              -> without this one your system will still try to boot from /boot instead of /@/boot

              10. If you haven't done so already in step 5, mount the btrfs root to /mnt: mount /dev/sdx /mnt
              -> Once everything is working add this mount to fstab, use the UUID instead of /dev/sdx

              11. Delete the now obsolete OS folders in FS_ROOT, everything but /@ : rm -r /mnt/boot
              -> Be careful with the rm command...just saying :-)
              -> Start with "rm -r /mnt/boot" and reboot, if you got one of the previous steps wrong you will have to start all over, better to fail early I guess :-)
              -> If the machine reboots, you can safely delete the other folders.

              12. Update the remaining entries in grub.cfg similar to #2

              Done!

              This is what your folders should look like after you worked through all of this. I didn't bother creating a @home subvol for my server use case.
              root@homeserver:~# ll /
              total 32
              drwxr-xr-x 1 root root 224 Oct 8 08:01 ./
              drwxr-xr-x 1 root root 224 Oct 8 08:01 ../
              drwxr-xr-x 1 root root 2430 Jul 25 23:04 bin/
              drwxr-xr-x 1 root root 620 Oct 6 17:46 boot/
              ...
              root@homeserver:~# ll /mnt
              total 16
              drwxr-xr-x 1 root root 2 Oct 8 08:14 ./
              drwxr-xr-x 1 root root 224 Oct 8 08:01 ../
              drwxr-xr-x 1 root root 224 Oct 8 08:01 '@'/
              root@homeserver:~# mount | grep btrfs
              /dev/sdd2 on / type btrfs (rw,noatime,ssd,space_cache,autodefrag,subvolid=25 9,subvol=/@)
              /dev/sdd2 on /mnt type btrfs (rw,relatime,ssd,space_cache,autodefrag,subvolid=5 ,subvol=/)
              root@homeserver:~#
              Once you arrived here you can basically go back to the first post in this thread, create the /mnt/snapshots folder and your very first snapshot! Yay :-)
              root@homeserver:/mnt# mkdir /mnt/snapshots
              root@homeserver:/mnt# btrfs su snapshot -r /mnt/@ /mnt/snapshots/@clean

              Comment


                #52
                @GreyGeek, you wrote the below in your first post here, but the link seems to take me to a conversation which is about having too many snapshots rather than related to balancing?

                Also, would it make sense to update the section about trim to reflect the fact that a weekly trim might be already setup by the OS? And that people should run sudo systemctl status fstrim.timer before setting up a cron job? I guess we should avoid running trim twice.

                Comment


                  #53
                  IMO, running tirm weekly is excessive unless your drive is 80%+ full. I do mine monthly and even that is too often. 2-4 times a year is plenty for most users.
                  Please Read Me
                  Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

                  Comment


                    #54
                    Don't know what's wrong or right but monthly sounds good to me. For those who want to change the default systemctl job to monthly here's how it worked for me just now:
                    Code:
                    1. Run "sudo nano /etc/systemd/system/timers.target.wants/fstrim.timer" and change OnCalendar=weekly to OnCalendar=monthly
                    2. Reload daemons: sudo systemctl daemon-reload
                    3. Start trim: sudo systemctl start fstrim.timer
                    4. Check results: sudo systemctl status fstrim.timer

                    Comment


                      #55
                      Originally posted by Thomas00 View Post
                      @GreyGeek, you wrote the below in your first post here, but the link seems to take me to a conversation which is about having too many snapshots rather than related to balancing?



                      Also, would it make sense to update the section about trim to reflect the fact that a weekly trim might be already setup by the OS? And that people should run sudo systemctl status fstrim.timer before setting up a cron job? I guess we should avoid running trim twice.
                      Thanks for catching that. I've updated the #1 post to point to an explanation and added an additional link, and also added more discussion to fstrim.
                      "I would rather have questions that can't be answered, than answers that can't be questioned." ― Richard Feynman

                      Comment

                      Working...
                      X