ZFS ZFS metadata bloat problem?

C

canihazsekooriti

I discovered on BTRFS a metadata bloat problem. Basically, I copy an nspawn container folder (several gigs), and the metadata usage gets bloated by 115MB. As it's CoW a typical user would expect almost no extra space taken by this action (even being remotely aware of some overhead) and will not be aware of this metadata bloat quickly and easily. Importantly, there is no way to mitigate it. So you start snapshotting a duplicated and completely unmodified folder, and you multiply that 115MB metadata bloat with each snapshot. Not good.

Does ZFS have the same problem???

And as for BTRFS I feel there's such easy solutions to that - when you duplicate a folder, don't duplicate metadata until you modify something in the duplicated data. Basically, snapshotting metadata on each duplication of folders is kind of what needs to happen. That saves lots and lots of storage space for private and corporate users.
 
ZFS snapshots only use space when data is modified. And, that space will be freed when the snapshot is deleted. ZFS CoW removes the old "tree" when the reference count to the metadata (&data) is zero. When snapshots are involved the reference count is +1 per snapshot. Only the changed data and its metadata remain -- as you suggest in your last paragraph.

I've played around with BTRFS in Fedora. It's klunky and IMO not ready for prime time. This is probably why Red Hat has deprecated it in RHEL (though other Linux distros continue to use it). At $JOB we use LVM with EXT4. Though we are starting to support XFS under LVM in some cases. For Linux users I'd recommend not using BTRFS.
 
cy@ said:
ZFS snapshots only use space when data is modified. And, that space will be freed when the snapshot is deleted. ZFS CoW removes the old "tree" when the reference count to the metadata (&data) is zero. When snapshots are involved the reference count is +1 per snapshot. Only the changed data and its metadata remain -- as you suggest in your last paragraph.

I've played around with BTRFS in Fedora. It's klunky and IMO not ready for prime time. This is probably why Red Hat has deprecated it in RHEL (though other Linux distros continue to use it). At $JOB we use LVM with EXT4. Though we are starting to support XFS under LVM in some cases. For Linux users I'd recommend not using BTRFS.
Click to expand...
Well, BTRFS snapshots do the same things, as far as I am aware - snapshots only use space when data is modified. It's more of the CoW issue that duplicates the metadata on a copy operation, and metadata can weigh a lot. ZFS has the same problem, doesn't it?

I've been using BTRFS on Linux for a while now, and it's been pretty smooth. Red Hat's Fedora has made BTRFS their default filesystem.
 
canihazsekooriti said:
Well, BTRFS snapshots do the same things, as far as I am aware - snapshots only use space when data is modified. It's more of the CoW issue that duplicates the metadata on a copy operation, and metadata can weigh a lot. ZFS has the same problem, doesn't it?

I've been using BTRFS on Linux for a while now, and it's been pretty smooth. Red Hat's Fedora has made BTRFS their default filesystem.
Click to expand...
That may be but Red Hat has deprecated it in RHEL. That begs the question, when will Fedora follow suit, as Fedora is the RHEL upstream and Red Hat develops Fedora.
 
You must log in or register to reply here.
Back
Top