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
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
