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

231–240 of 240 posts

Re: Five Years of Btrfs

#231

Post by pizza234 »

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…

Do you have a link to the bug issue? ZFS purpotedly never had any corruption issues on release versions, so that makes it a really interesting case.

Re: Five Years of Btrfs

#232

Post by pmarreck »

xzcat wrote: post #53
pmarreck wrote: post #24

Earlier quoted context omitted.

I have to beg to differ here as I had a different experience that I literally just posted about to Reddit yesterday https://www.reddit.com/r/zfs/comments/eu1qsj/a_tale_of_two_f... tl;dr Unbeknownst to me I had a bad drive cable for an external NVMe enclosure that was causing intermittent I/O errors (only during high drive utilization) that went undetected by BTRFS and slowly corrupted my drive, eventually leading to…

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…

> when the proxmox node I was using it on just randomly decided it wasn't going to boot anymore

could this possibly be proxmox's fault more than ZFS's fault? You even said the pools were fine

Re: Five Years of Btrfs

#233

Post by cmurf »

packetlost wrote: post #203
cmurf wrote: post #194

Earlier quoted context omitted.

Sounds like hardware problems in the storage stack. Btrfs developers contributed the dm-log-writes target to the kernel, expressly for conducting power loss tests on file systems. All the file systems benefit from this work. https://www.kernel.org/doc/Documentation/device-mapper/log-w... And Btrfs is doing the right thing these days. I recently conducted system resource starvation tests where a compile process spun o…

100% was not a hardware problem. Works fine on other filesystems ️

That's an inadequate answer because it rests on other file systems assuming the hardware is working reliably. Btrfs and ZFS don't make such assumptions, that's why everything is checksummed. They are canaries for hardware, firmware, and software problems in the storage stack that other filesystems ignore.

Re: Five Years of Btrfs

#234

Post by rdslw »

starfallg wrote: post #109
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…

Btrfs is the only FS I used that resulted in complete FS corruption losing nearly all data on disk, not once, but 3 times. After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.

Sorry, but this is an anecdata.

Down there, 2/3 of this hackersnews discussion (if you are patient to get there) you can see questions about production deployment of btrfs, with some VERY interesting answers of BIG deployments of btrfs. Read success confirmed with data. My takeaway from reading whole discussion:

* lot of people (individuals) praise of btrfs

* lot of people (ind.) tell about problems

* quite nice features/btrfs usage patterns, not matched even by zfs mentioned

* still for VM/DB you shall consider different approach (thin LVM + xfs or ext4) and slave machine WITH btrfs and snapshots on it

* quite many problems/deficienses of ZFS mentioned (apart fomr typical license/kernel inclusion)

* lot of new features on the way in recent kernels for btrfs

* btrfs is not dead

p.s. worth to comment that kernel 5.6 just received another huge new features batch for btrfs (async discard!)

Re: Five Years of Btrfs

#235

Post by SignalsFromBob »

loudmax wrote: post #38
nickik wrote: post #18

Being 'The Dude' of file system is literally the opposite of what I want. When looking at ZFS talks and the incredible complexity of some of those operations that Btrfs seems to think are 'no big deal', I will simply not trust that. Specially because it has been proven over and over again that Btrfs claims its 'stable' and then a new series of issues show up. Or its 'stable' but not if you use 'XY feature', or if the…

> I think its much more NIMBY then a license issue How do you propose that ZFS be brought into Linux? When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel. This was no accident. At the time, Sun was still pushing OpenSolaris which was losing ground to Linux. The ZFS on Linux project gets around this restriction by running…

> The ZFS on Linux project gets around this restriction by running ZFS in user space

ZFS on Linux is a kernel module. You may be thinking of ZFS-FUSE which runs in user space using FUSE, but I'm not sure if it's being maintained any more.

Re: Five Years of Btrfs

#236

Post by mekster »

muxator wrote: post #71
derefr wrote: post #27

A question for HN: what filesystem and/or block-device abstraction layer would you use on a database server, if you wanted to perform scheduled incremental backups using filesystem-level consistent snapshotting and differential snapshot shipping to object storage, instead of using the DBMS’s own replication layer to achieve this effect? (I.e. you want disaster recovery, not high availability.) Or, to put that another…

I do not think it would be a good idea to use file system level snapshotting for backing up a database. The database "knows better" about its internals, and can give more guarantees about the consistency of its data. I would trust a filesystem-levdl backup only as a last resort.

I also think database specific backup makes more sense.

Some people recommend filesystem snapshotting but wouldn't that make recovery a slow process because you have to load up the entire database even if you just wanted to look up on data of a small table?

Maybe backing up only small tables as SQL dumps while keeping a file system snapshot would be a good compromise.

Re: Five Years of Btrfs

#237

Post by mekster »

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…

Also, who uses btrfs in production? I only heard Facebook is using it somewhere but never read about others. Why is Facebook using btrfs yet there seems to be no publicity to make it more popular for external contributions.

Re: Five Years of Btrfs

#238

Post by mekster »

ak217 wrote: post #33
lousken wrote: post #7

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

At a previous job, I deployed btrfs to production in a system that continuously spins up and shuts down thousands of VMs. A key feature that I was able to leverage to make this easy is seed devices. This btrfs feature works similarly to overlay filesystems. If I were doing that today, I would do a bake-off of OverlayFS vs. btrfs for this feature. Btrfs has many other compelling features that may make it worth using,…

I heard people get stable btrfs when certain features are turned off, so it may be helpful to say what you have turned on or off with its features when saying how it has been stable or not.

Re: Five Years of Btrfs

#239

Post by mekster »

shmerl wrote: post #182

I'm using Btrfs currently, but I'm waiting for Bcachefs to replace it.

How far has it come to replace any of the production ready filesystems?

It says it's feature complete in 2015 and was trying to put itself into kernel mainline in 2018 but I don't see much about anyone using it in production.

Re: Five Years of Btrfs

#240

Post by shmerl »

mekster wrote: post #239
shmerl wrote: post #182

I'm using Btrfs currently, but I'm waiting for Bcachefs to replace it.

How far has it come to replace any of the production ready filesystems? It says it's feature complete in 2015 and was trying to put itself into kernel mainline in 2018 but I don't see much about anyone using it in production.

It's not production ready so far for sure. I didn't really follow all details on that.
Post reply on HN