[pve-devel] [PATCH v2 multiple] btrfs, file system for the brave

[Wolfgang Bumiller]

Changes to v1:
  * Storage API gets a hard bump: (ver=9, age=0), due to the
    import method signature changes.
  * Added `nocow` file storage option as a performance knob.
    This causes raw files to be marked as `NOCOW`
    (`chattr +C`), which does 2 things:
    a) Disables checksumming:
    b) Allows the use of `O_DIRECT` without causing scrubs
       to spam checksum errors...
    Increases performance at the cost of data integrity.
    Note that to my knowledge this is not really worse than
    using any other non-checksumming file system (xfs,
    ext4), and if you use a single-disk setup with no
    redundancy, chances are that's all you need ;-)
  * Added `quotas` btrfs storage option.
    This requires quotas to be anbled on the file system
    (`btrfs quota enable /path/to/mountpoint`), and will
    allow creating "format=subvol" container disks with a
    non-zero size, instead of using an ext4 formatted raw
    file.
    For *now* this also disables send/recv (I'll work on a
    patch for that later).
    Other than that, this, uh, changes performance... (For
    small setups likely for the better, for bigger ones
    *potentially* for the worse.)
  * pve-container: use subvols on btrfs storages with the
    `quotas` option enabled

NOTE:
I kept the "storage lists" on the qemu & container side for
now. We can still change this to become storage features
later, but it seems this part of the code is actually in
need of some more maintenance given the accumulation of
features we have there.
For instance, whether a volume is offline-migratable (the
main checks touched by this series), would ideally also take
the *target* storage into account. Eg. instead of a
"feature" check, we could use `volume_transfer_formats()`
(or a specialized method in `PVE::Storage` to check whether
a volume which has snapshots can be migrated this way, iow.
ask whether `storage_migrate()` with the given volume &
storage parameters is supposed to succeed)

Therefore the qemu & container parts (apart from the
container change listed on top) are just rebased and
otherwise unchanged.

--

Original cover letter:

This is another take at btrfs storage support.
I wouldn't exactly call it great, but I guess it works (although I did
manage to break a few... Then again I also manged to do that with ZFS
(it just took a few years longer there...)).

This one's spread over quite a few repositories, so let's go through
them in apply-order:

* pve-common:

<snip>

* pve-storage:

  * PATCH 1/4: fix find_free_disk_name invocations

    Just a non-issue I ran into (the parameter isn't actually used by
    our implementors currently, but it confused me ;-) ).

  * PATCH 2/4: add BTRFS storage plugin

    The main implementation with btrfs send/recv saved up for patch 4.
    (There's a note about `mkdir` vs `populate` etc., I intend to clean
    this up later, we had some off-list discussion about this
    already...)

    Currently, container subvolumes are only allowed to be unsized
    (size zero, like with our plain directory storage subvols), though
    we *could* enable quota support with little effort, but quota
    information is lost in send/recv operations, so we need to cover
    this in our import/export format separately, if we want to.
    (Although I have a feeling it wouldn't be nice for performance
    anyway...)

  * PATCH 3/4: update import/export storage API

    _Technically_ I *could* do without, but it would be quite
    inconvenient, and the information it adds to the methods is usually
    readily available, so I think this makes sense.

  * PATCH 4/4: btrfs: add 'btrfs' import/export format

    This requires a bit more elbow grease than ZFS, though, so I split
    this out into a separate patch.

* pve-container:

  * PATCH 1/2: migration: fix snapshots boolean accounting

    (The `with_snapshots` parameter is otherways not set correctly
    since we handle the base volume last)

  * PATCH 2/2: enable btrfs support via subvolumes

    Some of this stuff should probably become a storage property...
    For container volumes which aren't _unsized_ this still allocates
    an ext4 formatted raw image. For size=0 volumes we'll have an
    actual btrfs subvolume.

* qemu-server:

  * PATCH 1/1: allow migrating raw btrfs volumes

    Like in pve-container, some of this stuff should probably become a
    storage property...

--
Big Terrifying Risky File System