Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Five Years of Btrfs

markmcb.com

Post reply on HN
Print view View original

121–130 of 240 posts

Re: Five Years of Btrfs

#121

Post by takeda »

rcthompson wrote: post #104
takeda wrote: post #97

Earlier quoted context omitted.

ZFS had this issue (I believe fixed) workaround was to pick up one large file that you wanted to delete and do `echo -n > /the/unimportant/file` once the file was reduced in size to 0, rm started to work again. Not sure if that workaround would work in btrfs, but it worked on ZFS.

What happens if the file has already found its way into a snapshot? Then presumably that command will not free any space.

Well, rm wouldn't free the space either so you either would remove the snapshot or chose a different file.

Re: Five Years of Btrfs

#122

Post by riku_iki »

Shalle135 wrote: post #25

Is there any specific reasons to run btrfs over for example ext4? You can create/shrink/grow pools, create encrypted volumes etc by using LVM. It all depends on the application but in the majority of cases the io performance of btrfs is worse than the alternatives. Redhat for example choose to deprecate btrfs for unknown reasons while SUSE made it it’s default. The future of it seems uncertain which may cause a lot o…

For me, killer feature is transparent compression, I work with a lot of numerical data in Postgres, and running it over btrfs is the only viable way to compress it.

Re: Five Years of Btrfs

#123

Post by rleigh »

boris wrote: post #29
lousken wrote: post #7

Did anyone had the courage to use btrfs in production? Any stories to share?

We (the build2 project) use it in our CI infrastructure for VM storage. For every build we make a snapshot of a VM, boot it, build, drop the snapshot, repeat. So we are talking about making/dropping snapshots every couple of minutes 24x7 for months without a reboot. We haven't had a single issue.

No problems with unbalancing?

When I was doing whole rebuilds of Debian, using e.g. 8 parallel builds of >18000 packages, it was creating and destroying a snapshot once every few seconds to minutes, at most 8 snapshots in existence at once. It got unbalanced and went write only every 36 hours. A clean brand new filesystem which never had more than 10% space utilisation and was typically around 1%.

Re: Five Years of Btrfs

#124

Post by paulddraper »

tezzer wrote: post #95

I've had one issue with btrfs that took it off my radar completely. A customer had a runaway issue that filled a btrfs device with unimportant things. We found the errant process and killed it, but apparently if a btrfs device is completely full, you can't delete anything to free up space. File removal requires some amount of free space. Bricked the device, annoyed a customer, back to ext4.

I'm surprised they wouldn't reserved space.

IIRC ext4 reserves a (configurable) portion of the disk for system management; it seems like btrfs could easily do the same.

Re: Five Years of Btrfs

#125

Post by rleigh »

saalweachter wrote: post #110
xzcat wrote: post #53

Earlier quoted context omitted.

I'll throw in my own anecdote. ZFS on root caused me a significant amount of headache when the proxmox node I was using it on just randomly decided it wasn't going to boot anymore. The ZFS pools were fine, no data was lost, but no amount of messing with it fixed the zfsonroot and it was quite difficult to find quality search results for. And of course it was a weekend where my parents and siblings and in-laws were vi…

I suspect that both BTFS and ZFS are currently good enough under most configurations that most users don't have a problem with whichever they choose, and it's only a tiny fraction that has a really good or bad experience and becomes a rabid advocate based on their anecdotes.

This is an obvious truism. Of course they appear to work correctly under ideal conditions.

The real question is how they behave under less than ideal conditions. It is these conditions where Btrfs has performed poorly, and where ZFS has performed very well. I lost several Btrfs filesystems due to its poorly-tested and broken error handling trashing the filesystem beyond recovery.

The selling point of both of these filesystems is their robustness, fault-tolerance and ability to self-heal. Only one of them actually delivers.

Re: Five Years of Btrfs

#126

Post by loeg »

takeda wrote: post #97
tezzer wrote: post #95

I've had one issue with btrfs that took it off my radar completely. A customer had a runaway issue that filled a btrfs device with unimportant things. We found the errant process and killed it, but apparently if a btrfs device is completely full, you can't delete anything to free up space. File removal requires some amount of free space. Bricked the device, annoyed a customer, back to ext4.

ZFS had this issue (I believe fixed) workaround was to pick up one large file that you wanted to delete and do `echo -n > /the/unimportant/file` once the file was reduced in size to 0, rm started to work again. Not sure if that workaround would work in btrfs, but it worked on ZFS.

See also: 'truncate -s 0 /the/file'

Re: Five Years of Btrfs

#127

Post by tjoff »

RX14 wrote: post #119
tjoff wrote: post #101

Earlier quoted context omitted.

It very much is a concern. ZFS has no knowledge about the internals of a database, which parts of a file are related to each other etc.

DBMSes always keep their database in the file system in a consistent state to be able to recover from system crashes. Taking a file system snapshot is equivalent to pulling the power on the database server in terms of data recovery, but databases are designed to support this.

As do filesystems. Yet I've seen anyone argue that cutting the power is the recommended way of doing backups.

In fact the opposite, make sure to use an UPS just so that you can shutdown cleanly in the unfortunate event.

For example: https://blogs.oracle.com/paulie/backing-up-mysql-using-zfs-s...

Re: Five Years of Btrfs

#128

Post by rossmohax »

zielmicha wrote: post #59

fsync is still a bit slow on BTRFS (on ZFS too, but to a smaller degree). For example, I just did a quick benchmark on Linux 5.3.0 - installing Emacs on fresh Ubuntu 18.04 chroot (dpkg calls fsync after every installed package). ext4 - 33s, ZFS - 50s, btfrs - 74s (test was ran on Vultr.com 2GB virtual machine, backing disk was allocated using "fallocate --length 10G" on ext4 filesystem, the results are very consisten…

is ext4 also from fallocated file on underneath ext4?

Re: Five Years of Btrfs

#129

Post by rbanffy »

m4rtink wrote: post #98
InTheArena wrote: post #31

I went on a quest a few years ago, thinking it would be good for the industry to standardize on a single next generation filesystem for UNIX. I started with ZFS on linux since that seemed to have the most vocal advocates. That lasted about a half year, until a bug in the code resulted in a completely corrupt disk, and I had to restore 4TB of data over a month from offside backups. That plus the licensing confusion ar…

Hard to standardize on something that can't be maintained in the same place all your other filesystems are in (in the Kernel) for licensing reasons.

Only the boot file system drivers need to be in the kernel. As long as there is a stable ABI, it's fine for everything else to be someplace else.

Re: Five Years of Btrfs

#130

Post by rbanffy »

paulddraper wrote: post #124
tezzer wrote: post #95

I've had one issue with btrfs that took it off my radar completely. A customer had a runaway issue that filled a btrfs device with unimportant things. We found the errant process and killed it, but apparently if a btrfs device is completely full, you can't delete anything to free up space. File removal requires some amount of free space. Bricked the device, annoyed a customer, back to ext4.

I'm surprised they wouldn't reserved space. IIRC ext4 reserves a (configurable) portion of the disk for system management; it seems like btrfs could easily do the same.

Won't that only work for non-root processes?
Post reply on HN