On Mon, May 25, 2015 at 5:21 PM, Javier Perez <pepebuho@xxxxxxxxx> wrote: > Hi > > I am just learning about btrfs on my home system. > > How do I know what kind of options where used to create a BTRFS filesystem? > I installed F21 from scratch and I created a BTRFS filesystem on a HDD. I > think I created it with the "single" option. btrfs filesystem df <mp> OR btrfs fi df <mp> # is shorter The mountpoint is presumably / but could also be /home, if you've done a default Btrfs installation. This will show the data and metadata profiles. The default mkfs for HDD is data profile single, and metadata profile DUP. > Now I read that that is dangerous, I should have created it as one of the > raids if I want to have data redundancy and protection vs bit rot (which is > what I was looking forward to). It's no more dangerous than any single drive installation. If there's any bit rot, at least you are notified of what files are affected if you check kernel messages with dmesg. This happens passively during normal use (any file read operation), and can also be checked with: btrfs scrub start <mp> And then checking kernel messages. If corruption has happened in metadata, then on HDD by default with DUP metadata profile, the problem is fixed automatically. If single data profile, then it'll list the bad file path. > > How can I verify it? Also, If I want to change it, can I do it IN-PLACE or > do I have to reformat/recreate the filesystem? It can be done in place. Add a new drive, optionally partition it and then, e.g.: btrfs device add /dev/sdb1 <mp> btrfs balance start -dconvert=raid1 -mconvert=raid1 <mp> Note you must convert both data and metadata profiles in order to really get raid1 protection. If you only change data profile to raid1 then metadata (the file system itself) stays as DUP and that means it's only on one device. These days the -m conversion will also convert system chunks too, so it doesn't need to be separately listed. Conversion status is in dmesg, as well as btrfs balance status <mp> as well as: btrfs fi df <mp> Eventually all chunks will be converted and have the same profile. Note that Btrfs and GNOME have no mechanism to notify the user in case of drive failure like with mdadm managed drives. If a drive dies with mdadm raid1, GNOME shell will produce a notification. That doesn't happen right now with Btrfs multiple devices. Further, there are some problems booting Btrfs raid1 in the case of a drive failure: 1. When all devices for a Btrfs volume aren't available, somewhere between btrfs kernel code and libblkid there's a failure for a volume UUID to be produced; 2. udev doesn't scan for it; 3. systemd can't find root by UUID; This results in boot failure. 4. The degraded mount option is not enabled for Btrfs in the kernel by default; This results in boot failure. So to fix this you manually edit the boot entry (GRUB) and change root=UUID=<uuid> to root=/dev/sdXY for the surviving drive, which can sometimes be tricky since these assignments can change especially if a drive has died. And you need to change rootflags=subvol=root to rootflags=subvol=root,degraded Now you can boot, and then do replacement with a new drive, e.g.: btrfs replace start <devid> /dev/sdc1 <mp> To get devid is non-obvious. You should be able to infer it from: btrfs fi show which will show you the devid for current devices but not missing ones, sorta annoying that this isn't more clear. Anyway, that does a device add, device delete, balance all in one step. It's an online replace and rebuild, tends to be pretty fast because it only has to sync used blocks rather than all blocks like md and lvm raid. > > Thanks for whatever help/illumination you might provide. I am catching up on > btrfs, but I am not there yet. Yeah, I highly advise frequent backups with Btrfs. It's very unlikely you will experience serious problems, but based on btrfs@ list experience, if you end up in an edge case there's a good chance you will need that backup. Fortunately even bad problems tend to make the filesystem mount read-only so at least you can update your backup, but there are still cases where btrfs check cannot fix the problem. And it's still mostly advisable to not run btrfs check --repair without first posting the complete results of btrfs check to the btrfs@ list. So if this all sounds overly complicated and daunting then I'd say mdadm or lvm raid + ext4 or XFS is a better choice for your use case right now. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
