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

161–170 of 240 posts

Re: Five Years of Btrfs

#161

Post by twic »

clSTophEjUdRanu wrote: post #73
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…

I really don't understand the insane hype around ZFS. You can't read any thread that touches on filesystems without the ZFS zealots coming out.

Eh, i'm waiting for them to rewrite it in Rust.

Re: Five Years of Btrfs

#162

Post by rocqua »

jstrong wrote: post #91
iracic wrote: post #74

Earlier quoted context omitted.

It is possible to put database in state that is "ready" for snapshot, pushing changes to disk and sort of freezing I/O during snapshot.

this is generally not a matter of concern for a copy on write filesystem like zfs, since it's not possible for the file to be in an "in between" state. If a write were in progress, the filesystem would still be pointing to the previous state. Only when the data is written to disk is the pointer moved to the new location.

It matters when various writes to files need to be ordered, and the DB processes is keeping some of the consistency part in memory.

Re: Five Years of Btrfs

#163

Post by gravypod »

louwrentius wrote: post #108
gravypod wrote: post #103

I've seen a lot of the hacker community focusing on btrfs and zfs but very little focusing on ceph. I think ceph has a lot of the features that we want in a file system and some things that aren't even possible on traditional file systems (per-file redundancy settings) with very little downsides. The setup is a little more complex involving a few daemons to manage disks, balance, monitor, etc. I wish there was someth…

I love Ceph, I even wrote an intro about it for those who are not familiar with it. https://louwrentius.com/understanding-ceph-open-source-scala... But Ceph is not designed to be a competitor to BTRFS or ZFS. The core vision of Ceph is scalability. If you need petabytes of storage and the performance to scale with it, take a look at Ceph. I may be totally wrong here, but from what I understand about Ceph, it's not me…

I never really store data on my local machines anymore. All of my data is either hosted only on, or backed up to, my storage server. I think the selling point of ceph is that every server in my apartment can be part of my storage cluster and data I really want to avoid loosing can be persisted across all of them.

For me latency isn't really a large issue. I read and write everything locally on my SSD-backed desktop/laptop and then sync my files to my storage node via git or rsync or something. For me data integrity and availability are important.

Re: Five Years of Btrfs

#164

Post by adamzegelin »

proaralyst wrote: post #106
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.

The trick was to insert a USB drive, tell BTRFS it's block storage and delete away. Once you're done you tell it not to use the disk and you're good. This is why I'm back on ext4 now, too.

Or, if you don't care about your data, add a RAM disk :P

Re: Five Years of Btrfs

#165

Post by ansible »

mdip wrote: post #12
pojntfx wrote: post #3

Love using Btrfs; the is no better filesystem than it nowadays that it's reliability issues have been fixed.

I tend to agree with you here -- reliability has been a non-issue for me, though I've never configured `btrfs` in its RAID configuration. Performance becomes an issue in certain cases, but in every one that I've encountered, adjusting configuration has resolved the problems to my satisfaction. Would my Windows 10 VM run better under a different filesystem, rather than `btrfs` with various tweaks applied? Reading rela…

We have run btrfs in RAID configuration, but that has usability issues, even just doing RAID-1.

We've switched back to using MD (mdadm) for RAID-1 setup, and then using btrfs on top of that for the snapshots, send / receive, block-level CRC and such.

Dealing with failed drives isn't as easy with btrfs as it is with Linux MD.

Re: Five Years of Btrfs

#166

Post by paulddraper »

takeda wrote: post #136
paulddraper wrote: post #124

Earlier quoted context omitted.

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.

Ext4 reserves space that can be used only by root, it is so system services can continue to work when users take all the space. It doesn't have issues like this if you exhaust all of that space. In ZFS and I'm sure in btrfs you can set up quotas and reserved space, globally and or user, but by default it is set to 0. I actually set my quota to 80% because apparently if you fill ZFS more it causes heavy fragmentation.

You're 100% correct; ext4 reserves this for a different purpose. I'm just saying it's not a entirely novel idea (albeit for a different reason).

Re: Five Years of Btrfs

#167

Post by SEJeff »

blattimwind wrote: post #154
SEJeff wrote: post #137

Earlier quoted context omitted.

Historically, the biggest bugs in btrfs were when you came close to filling up the filesystem. For the longest time, you'd get -ENOSPC (no space left) even when you had many Gb of space left due to really bad metadata and block level space usage.

Let's not forget about various performance issues which were exacerbated by "low free space" conditions (i.e. after you filled the volume beyond 80 % these started to pop up). A file system that will sometimes go down well into the fractional IOPS range is not very useful. Some of these are fixed by now, though.

"the biggest bugs in btrfs were when you came close to filling up the filesystem" :)

I used to read every email on btrfs-devel for a year or so.

Re: Five Years of Btrfs

#168

Post by wmf »

tjoff wrote: post #127
RX14 wrote: post #119

Earlier quoted context omitted.

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...

Some people came up with the idea of "crash-only software", arguing that it's better to maintain one code path (recovering from a crash) than two (clean start and recovery), but it hasn't caught on that much. https://www.usenix.org/legacy/events/hotos03/tech/full_paper...

Re: Five Years of Btrfs

#169

Post by Zardoz84 »

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.

this wasn't fixed years ago ? I had a BTRFs partition filled by a rogue process and it not bricked. it allow me to remove the junk files without any issue. And I'm talking of a Ubuntu 14.04 Ltd server

Re: Five Years of Btrfs

#170

Post by cpudestw2020 »

vetinari wrote: post #63
Fnoord wrote: post #45

Earlier quoted context omitted.

RAID5 on btrfs has a write hole last time I checked. Bug has been around forever, and was around in 2014 for sure. Phoronix has some thorough performance comparisons between Ext4fs, Btrfs, XFS, and ZFS.

That one is here to stay, it is a property of software-based RAID. If it bothers you, use UPS.

I think in Linux, if you're using mdadm there is the ability to specify a write journal; all data (i.e. blocks+parity) gets written to the journal first, and then gets cleaned up after everything gets completed successfully, and the journal is replayed after a power failure.

Mind you, for that to work well you'd want a victim SSD with a write speed at least that of the array...

Post reply on HN