Re: Handbook btrfs support

wireless posted on Fri, 06 Dec 2013 14:31:52 -0500 as excerpted:

> I was looking at the handbook. File system support seems limited in the
> documentation of the handbook, some quite antiquated (reiserfs?).
>=20
> Looking at the handbook it would seem to be quite extensible to support
> one of the newer, extremely attractive, files systems (ZFS or btrfs). M=
y
> guess is that, license_wise, it would be easier to document the use of
> btrfs in the handbook?
>=20
> So, these are the sections that would need only limited prose to suppor=
t
> btrfs in the handbook:
>=20
> 2.b 4.b/4.d  4.e 6.a 6.b 7.b 8.a 9.e 10.e ?
>=20
> The idea would be to use a single 2T drive, with the standard (handbook=
)
> 3 partition scheme, with just the simplest gentoo system set up with
> BTRFS.
>=20
> Your comments and suggestions are most welcome. If this idea is deemed
> meritorious, I'll take a crack at it and post what I discover after
> performing a few of this proposed btrfs handbook installs?

As you'll know if you follow the btrfs list, have read the wiki, or even=20
simply the btrfs kernel config option, btrfs isn't exactly stable yet. =20
While a patch in 3.13 does tone down the warning a bit, matching a=20
slightly toned down warning on the wiki of late, and I /do/ run btrfs=20
here, it's still far enough from stable that I'd hesitate to put it in=20
the handbook just yet.

Basically, current btrfs status for single-device or multi-device=20
raid0/1/10 modes is "semi-stable"; it generally works reasonably well,=20
but be *SURE* and keep *TESTED* backups and be prepared to use them if=20
necessary, AND try to keep on latest (upstream Linus) stable kernel if=20
not the development kernel RCs.  Following current discussions and status=
=20
on the btrfs list is recommended as well.

And bugs do still often affect a reasonable cross-section of users, too. =
=20
One fixed in 3.12 was hitting a lot of systemd users as well as others =20
using pre-allocated files that are then written into (torrent clients=20
often do this too and someone reported getting hit by that, too).  For=20
3.13, a host of kernel memory leaks have been fixed, as well as a=20
concurrency bug hit when people tried to run a balance and a snapshot (as=
=20
often done via cronjob, so the admin may have only been thinking about=20
and run the balance manually) at the same time.

Until very recently, live-git master-branch btrfs-progs was strongly=20
recommended too (development happens in branches and the policy for=20
master is that it's always run-ready, as stable as btrfs itself is at=20
this point), but with kernel 3.12 the btrfs-progs versioning policy=20
changed, with releases now generally synced with the kernel and versioned=
=20
similarly, thus making btrfs-progs-3.12 as current as the 3.12 series=20
kernel.  Of course that's ~arch, while live-git 9999 is naturally masked.

Run older than that as a btrfs tester (which is what anyone running btrfs=
=20
is at this point, a tester) and you're not only needlessly risking having=
=20
to use those backups you're keeping as a not-yet-fully-stable filesystem=20
tester due to running code with known and now fixed bugs, but any testing=
=20
reports filed aren't going to be as useful either, because you're testing=
=20
old code on a fast-moving project that has moved on from it.

But a lot of gentoo users reading the handbook won't want to be upgrading=
=20
that fast nor will they be that faithful in keeping current and tested=20
backups, nor will they wish to bother with following the btrfs list, as=20
recommended for anyone wishing to test btrfs at this point.

Oh, and neither btrfs nor zfs mount options are listed in the mount=20
manpage yet.  I don't know about zfs, but one indication of btrfs=20
maturing will be when it appears in the mount manpage.

So IMO btrfs is inappropriate for the handbook at this point.  Or if it's=
=20
included, stress its testing aspect and that those choosing to test it=20
should be prepared to use their TESTED backups, keep current on the=20
kernel and btrfs-progs, and follow the btrfs list to keep up with current=
=20
issues with what they've chosen to test.

Tho the thinking is that btrfs should really start to stabilize in 2014,=20
at least for the "basic" functionality comparable to most filesystems. =20
Of course in some ways every year seems to be the year btrfs will=20
stabilize, rather reminding me of the year of the Linux desktop. =20
However, I know it's getting closer, as I'm actually running it this=20
year, something I tried but gave up on last year.  And after leaving it=20
to mature a bit after the first bit, I could DEFINITELY see the=20
difference when I came back.  It really is getting there, and 2014 could=20
very well be the year.

Meanwhile, zfs is a bit more mature, but as you point out, has licensing=20
issues, thus making it not particularly handbook appropriate, tho of=20
course people can choose to run it if they wish.

Thus at this point, ext4 really remains the best "mainline" choice, with=20
xfs also a reasonable choice these days.  And reiserfs certainly remains=20
usable.  I'm still using it on spinning rust here, tho it's not so good=20
for SSDs, which is where I'm testing btrfs.  But ext4 has an ssd mode as=20
well, I believe.

--=20
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman