Re: [gentoo-user] planned btrfs conversion: questions

[Marc Joliet]

OK, I am in the middle of copying over my data from my backups to the freshly
created btrfs file system :-) . Read more below.

Am Wed, 7 May 2014 00:53:07 +0200
schrieb Marc Joliet <marcec@×××.de>:

[...]
> While I am unsure of my choice of RAID level (some comments on LWN.net claim
> that the MD RAID 10 is more comparable to btrfs' RAID 1, which I will attempt to
> verify myself beforehand). However, due to btrfs' live rebalancing feature, I
> worry less about this. By the time I really need more space the RAID 5/6 code
> (and maybe N-way mirroring) ought to be stable (or at least finished), or I
> can switch to RAID 1 if I need the flexibility.

I went with RAID 10 for data and RAID 1 for meta-data. I will see how the disk
usage actually turns out and can decide from there whether I want to change
either one if I'm not satisfied.

> [...]
> > The reason why I would choose EXT4 for the SSD is that btrfs still lacks support
> > for swap files and I worry about creating a swap partition on the SSD. Is that
> > warranted, or will the wear-levelling of the SSD handle that just fine? Do swap
> > partitions support SSDs specially? Also, does anyone know whether EXT4 goes
> > beyond "merely" supporting TRIM? That is, the btrfs wiki advertises the
> > following:
> >
> >   "SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for
> >   reuse) and optimizations (e.g. avoiding unnecessary seek optimizations,
> >   sending writes in clusters, even if they are from unrelated files. This
> >   results in larger write operations and faster write throughput)"
> >
> > Does EXT4 also implement such optimisations for SSDs?
>
> I will also go ahead with this (despite the open questions), although I will
> leave swap on the LVM for now. I think tonight (well, today) I "just" want to
> get the SSD running. Furthermore, "btrfs convert" should be able to up-convert
> it in the future once btrfs is "production ready" (both articles make a
> guesstimate of about 1-2 years).
>
> I think I would also prefer running a few days from the SSD before converting
> "the rest" to btrfs, which should be fairly simple at that point.

So, as before, the conversion was straightforward, since the RAID + LVM only
contained /home and data, thus I could convert without rebooting (though I will
reboot once the backups are restored, just to see if that works as expected).

Anyway, I performed the following steps:

- remount all affected partitions read-only
- perform one last backup
- unmount the affected partitions
- shut down the logical volumes and the RAID (also, remove mdadm, mdraid and
  lvm from all run-levels)
- run "mkfs.btrfs -f -m raid1 -d raid10 -L MARCEC_STORAGE /dev/sd{a,b,c,d}" (-f
  because the HDDs still had a partition table)
- create subvolumes where I used to have separate partitions (adjusting
  permissions where necessary)
- rsync /home from the backup drive (which was surprisingly fast)

What I am now in the middle of (2/3 of the way through) is syncing my media
partitions. After that, the conversion will be complete, and I will hope and
pray to our noodly overlord that I don't encounter any bugs.

[...]
> Thus the question arises: are there any show-stopper bugs in gentoo-sources
> 3.14.x that I should be aware about? They don't have to be directly btrfs
> related.

This is still an open question. I of course already upgraded prior to the btrfs
conversion and haven't noticed anything out of the ordinary, but I would be
interested in anybody else's experience.

One other thing I noticed: my old RAID had the distinct disadvantage that the
newest drive I had added to it had a different alignment than the old ones.
Since I had to copy the partition table from one of the existing drives, it was
not possible to accommodate this (though I only found out after recently
running "blockdev --getalignoff"). I suspect btrfs could be able to deal with
that better than mdraid, and searching for "alignment" on the btrfs wiki shows
results which heavily imply that it in fact can (quote from the description of
the btrfs_chunk data structure: "Optimal alignment parameters for block I/O").

Anyway, everything seems to be running fine so far :-) .

[...]

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup