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

Btrfs Allocator Hints

lwn.net

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Btrfs Allocator Hints

#41

Post by riku_iki »

theamk wrote: post #40
riku_iki wrote: post #28

Earlier quoted context omitted.

> Well, maybe it was my fault but since I'm using the exact same system with the same hardware right now (same NVMe SSD), I really doubt that. anecdotes could be exchanged in both directions: I run heavy data processing with max possible throughput on top of btrfs raid for 10 years already, and never had any data loss. I am absolutely certain if you expect data integrity while relying on single disk: it is your fault…

The reliability is about variety of workloads, not amount of data or throughput. It's easy to write a filesystem which works well in the ideal case, it's the bad or unusual traffic patters which cause problem. For all that I know maybe that btrfs complete failure was because of kernel crash caused by bad USB hardware. Or there was a cosmic ray hitting memory chip. But you know who's fault is it? It's btrfs's one. Oth…

> but as you may guess we did not use btrfs ever again.

there are scenarious where btrfs is currently can't be replaced: high performance + data compression.

Re: Btrfs Allocator Hints

#42

Post by hyperman1 »

I feel a bit lost here. In the good old days, I ran ext2/ext3/ext4 and forgot about it, or Reiserfs if I felt fancy (and which was great until it wasn't).

Now, there is a cambrian explosion going on. Ext4, xfs, btrfs,bcachefs, zfs. They each have their pros and cons, and it takes a while before you find out you run into an expensive limit. E.g. Ext3/4 is good, until it ran out of inodes. ZFS is good, but has only 1 password for full disk encryption and I want to store a second one with IT. According to the jungle drums, btrfs eats your data once in a while. Bcachefs stupidly tries to get itself rejected from Linux, not good for long term stability. I'm on XFS now, but let's see how that ends.

Re: Btrfs Allocator Hints

#43

Post by swinglock »

hyperman1 wrote: post #42

I feel a bit lost here. In the good old days, I ran ext2/ext3/ext4 and forgot about it, or Reiserfs if I felt fancy (and which was great until it wasn't). Now, there is a cambrian explosion going on. Ext4, xfs, btrfs,bcachefs, zfs. They each have their pros and cons, and it takes a while before you find out you run into an expensive limit. E.g. Ext3/4 is good, until it ran out of inodes. ZFS is good, but has only 1 p…

And XFS will at unexpected shutdowns sometimes leave you with files that previously contained data now being 0 bytes.

I only really trust ZFS on Linux, but it's such a bother it can't be upstreamed and isn't fully integrated with the native Linux caching, as the native file systems are. Ext is fine too but it's missing features like checksumming and compression, and has limitations as you mentioned.

Re: Btrfs Allocator Hints

#44

Post by ahofmann »

riku_iki wrote: post #30
ahofmann wrote: post #29

Earlier quoted context omitted.

What the hell are you talking about? Any filesystem on any OS I've seen the last 3 decades had some kind of recovery path after any crash. Some of them lose more data, some of them less. But being unable to mount, is a bug that makes a filesystem untrustworthy and useless. And how would RAID help in that situation?

> But being unable to mount, is a bug that makes a filesystem untrustworthy and useless. we are in disagreement on this. If partition table entry corrupted, you can't mount without some low level surgery. > And how would RAID help in that situation? depending on raid, your data will be duplicated on another disk, and will survive in case of one/few disks corruption.

The partition table gets mostly written only once in the lifetime of a filesystem/disk. So it almost never corrupts during an os crash.

There are a lot of RAIDs and configurations. Some of them may do what you describe, but most don't.

Re: Btrfs Allocator Hints

#45

Post by theamk »

riku_iki wrote: post #41
theamk wrote: post #40

Earlier quoted context omitted.

The reliability is about variety of workloads, not amount of data or throughput. It's easy to write a filesystem which works well in the ideal case, it's the bad or unusual traffic patters which cause problem. For all that I know maybe that btrfs complete failure was because of kernel crash caused by bad USB hardware. Or there was a cosmic ray hitting memory chip. But you know who's fault is it? It's btrfs's one. Oth…

> but as you may guess we did not use btrfs ever again. there are scenarious where btrfs is currently can't be replaced: high performance + data compression.

Sure, I can believe this. Does not change the fact that some people encounter compete data loss with it.

Sadly, there are people (and distributions) which recommend btrfs for general-purpose root filesystem, even for the cases where reliability matters much more than performance. I think that part is a mistake,

Re: Btrfs Allocator Hints

#46

Post by riku_iki »

ahofmann wrote: post #44
riku_iki wrote: post #30

Earlier quoted context omitted.

> But being unable to mount, is a bug that makes a filesystem untrustworthy and useless. we are in disagreement on this. If partition table entry corrupted, you can't mount without some low level surgery. > And how would RAID help in that situation? depending on raid, your data will be duplicated on another disk, and will survive in case of one/few disks corruption.

The partition table gets mostly written only once in the lifetime of a filesystem/disk. So it almost never corrupts during an os crash. There are a lot of RAIDs and configurations. Some of them may do what you describe, but most don't.

Ok, I know this, not sure what is your point.

Re: Btrfs Allocator Hints

#47

Post by riku_iki »

theamk wrote: post #45
riku_iki wrote: post #41

Earlier quoted context omitted.

> but as you may guess we did not use btrfs ever again. there are scenarious where btrfs is currently can't be replaced: high performance + data compression.

Sure, I can believe this. Does not change the fact that some people encounter compete data loss with it. Sadly, there are people (and distributions) which recommend btrfs for general-purpose root filesystem, even for the cases where reliability matters much more than performance. I think that part is a mistake,

I would recommend btrfs as general purpose root filesystem. Any FS will have people encountering data loss. I can believe btrfs has N times higher chance of data loss because its packed with features and need to maintain various complicated indexes which are easier to corrupt, but I also believe that one should be ready that his disk will fail any minute regardless of FS, and do backup/replication accordingly.

Re: Btrfs Allocator Hints

#48

Post by bjoli »

ajross wrote: post #8
bjoli wrote: post #5

I wonder if I can use a smaller SSD for this and make it avoid HDD wakeups due to some process reading metadata. That alone would make me love this feature.

Just buy more RAM and you get that for free. Really I guess that's my sense of patches like this in general: while sure, filesystem research has a long and storied history and it's a very hard problem in general that attracts some of the smartest people in the field to do genius-tier work... Does it really matter in the modern world where a vanilla two-socket rack unit has a terabyte of DRAM? Everything at scale happ…

I have 128gb, of which about 100 goes unused most of the time. It seems to have zero effect on this.

Re: Btrfs Allocator Hints

#49

Post by bjoli »

bionade24 wrote: post #6
bjoli wrote: post #5

I wonder if I can use a smaller SSD for this and make it avoid HDD wakeups due to some process reading metadata. That alone would make me love this feature.

Most likely yes, but the also envisioned periodically repacking oft multiple small data extents into one big that gets written to the HDD would wake up the HDD. And if you'd make the SSD "metadata only", browser cache and logging will keep the HDD spinning. This feature is for performance, not the case you described.

The disk is unused except for once a day things get backed up to it (and other places, of course). Nothing will get written to it except for when it is getting written to for the backup.

I will definitely try this.

Re: Btrfs Allocator Hints

#50

Post by rcxdude »

hyperman1 wrote: post #42

I feel a bit lost here. In the good old days, I ran ext2/ext3/ext4 and forgot about it, or Reiserfs if I felt fancy (and which was great until it wasn't). Now, there is a cambrian explosion going on. Ext4, xfs, btrfs,bcachefs, zfs. They each have their pros and cons, and it takes a while before you find out you run into an expensive limit. E.g. Ext3/4 is good, until it ran out of inodes. ZFS is good, but has only 1 p…

That doesn't really match my recollection of timeline. I remember xfs being mentioned in the same sources contemporary with reiserfs (it predates ext3, even!). ZFS is about a decade newer, but not by much, and was probably the main reason most people would pay any real attention to their filesystem at that point, since it meaningfully added features not available in anything else at that point. BTRFS was basically a 'let's build the same thing, but in linux', but seems to have kinda stalled in terms of reliability (or at least in terms of reputation), and bcachefs is very much the new kid on the block, but seems to have a little bit more of a focus on getting to the reliability of ZFS, but it certainly is still not something to trust even as much as BTRFS. So it doesn't really feel like a cambrian explosion, more a new filesystem every ~5 years or so at a reasonably steady pace.

(pretty much the 3 filesystems I think about ATM are ext4 as a standard boot drive, zfs for large, long-lived data storage, and FAT/exFAT for interoperability with windows. It'd have to be a pretty niche use-case for me to consider another option. BcacheFS sounds really interesting but only to experiment with right now)

Post reply on HN