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

In OpenZFS and Btrfs, everyone was just guessing

phoronix.com

Post reply on HN
Print view View original

161–170 of 172 posts

Re: In OpenZFS and Btrfs, everyone was just guessing

#161

Post by dartos »

onetimeuse92304 wrote: post #25
nabla9 wrote: post #3

> Everyone, literally, is just guessing. And then running scripts to evaluate the odds that things are actually working correctly. Just like BTRFS. When filesystem or databases have serious bugs, they are often heisenbugs. Incredibly hard to pin down. You need to be able to replicate the bug to find what is happening. In one of the first jobs I had, large Oracle database started to corrupt data repeatedly about once…

The hardest bug I have ever worked with was an embedded device losing all data on the flash chip. But the issue was, this was happening even after we removed all instructions to delete data from the flash. The device had most traces between controller and flash completely hidden as a precaution for hacking/snooping, making it extremely difficult to diagnose the issue as the issue completely vanished in a test harness…

I think something similar happened to my sd card at a hackathon years ago.

We couldn’t change the data on it. Linux would report that data was written to it, but when we unmounted and remounted it, the data was unchanged.

https://devpost.com/software/xcaliber

Re: In OpenZFS and Btrfs, everyone was just guessing

#162

Post by Am4TIfIsER0ppos »

withinboredom wrote: post #113
solarkraft wrote: post #29

Earlier quoted context omitted.

A lot of end users run ZFS through TrueNAS/FreeNAS and I indeed found that community to spread a lot of misinfo and un-actionable advice. I liken them to gamers lapping up any snake oil solution to get 0.1 fps more. I would suggest anyone trying to learn about ZFS to avoid it, it definitely was counter-productive to me. Reddit, random blogs and official documentation (often that by Oracle) turned out to be much bette…

Reminds me of a game (MMO) I play on the weekends. Any time someone new joins, they always ask how come frame rates are so low. Then we begin the ”set your graphic settings to high” conversation. They immediately say we are full of shit. It’s already set to low and getting 10 fps. Eventually, someone explains: “just try it, or stop complaining.” 30s later, they exclaim: “holy ** I’m getting 60 fps now!” Sometimes, wh…

Is that a visible option somewhere or do you only have one setting, the preset?

Re: In OpenZFS and Btrfs, everyone was just guessing

#164

Post by mischief6 »

cromka wrote: post #158
mischief6 wrote: post #152

Earlier quoted context omitted.

while it is unfortunate it requires a write, it is useful in some cases. for example, finding old objects in a cache, or today i used it to find out what firmware my kernel is loading by checking atime of /lib/firmware.

For the latter you could enable it, reboot and get the same information right away, then disable it?

i did not see a clear list of all firmware files read by the kernel in dmesg, so the find/atime trick worked well.

Re: In OpenZFS and Btrfs, everyone was just guessing

#165

Post by withinboredom »

Am4TIfIsER0ppos wrote: post #162
withinboredom wrote: post #113

Earlier quoted context omitted.

Reminds me of a game (MMO) I play on the weekends. Any time someone new joins, they always ask how come frame rates are so low. Then we begin the ”set your graphic settings to high” conversation. They immediately say we are full of shit. It’s already set to low and getting 10 fps. Eventually, someone explains: “just try it, or stop complaining.” 30s later, they exclaim: “holy ** I’m getting 60 fps now!” Sometimes, wh…

Is that a visible option somewhere or do you only have one setting, the preset?

The preset is the only way to influence it.

Re: In OpenZFS and Btrfs, everyone was just guessing

#166

Post by bsder »

duped wrote: post #72
bsder wrote: post #41

Earlier quoted context omitted.

I like Rust, but you are going to be writing a lot of unsafe Rust for a filesystem implementation. Multiple processes are writing to the filesystem simultaneously. "Ownership" is fuzzy and is moving around. At that point, is Rust buying you anything for how much it's going to get in your way? I really don't see an advantage to Rust when operating at these kinds of low levels.

Have you ever written a file system? Most of the work is conforming to the semantics of the interface to the kernel/programs calling it. Very little of that requires unsafe code, and the bulk of the provably unsafe stuff (physically writing to memory/disk) is very simple. The complex stuff can and should be written at a higher level than C.

> Have you ever written a file system? Most of the work is conforming to the semantics of the interface to the kernel/programs calling it.

Yes, I have. And I have implemented partial file locking semantics. And I can painfully remember what I went through to validate it.

Quite a few of those pointers are write pointers which are simultaneously active with a lot of read pointers and they have different owners. That is a task which is screaming "Rust is going to make your life miserable."

Re: In OpenZFS and Btrfs, everyone was just guessing

#167

Post by ungamedplayer »

ungamedplayer wrote: post #111
keep_reading wrote: post #106

Earlier quoted context omitted.

Deduplication in ZFS can be pushed onto dedicated flash storage now instead of requiring gobs of RAM.

Great channel for side attacks btw.

Oh got some hate there.. pissed off the zfs kids with a dose of reality.

Dedupe can be used to infer secret data. .. more news at 11

Re: In OpenZFS and Btrfs, everyone was just guessing

#168

Post by ungamedplayer »

keep_reading wrote: post #141
ungamedplayer wrote: post #111

Earlier quoted context omitted.

Great channel for side attacks btw.

Without having physical access to my hardware, where every disk is FDE anyway?

Physical access not required. Dedupe side attack required timing measurement.

Re: In OpenZFS and Btrfs, everyone was just guessing

#169

Post by yencabulator »

GrumpySloth wrote: post #144
RantyDave wrote: post #37

Earlier quoted context omitted.

On the other hand there are a couple of things in ZFS that can make a big difference. For instance: changing the page size to be the same size as Postgresql uses (8kb); disabling the writing of 'last accessed' timestamps; or whether or not the filesystem attempts deduplication. From what I remember (it's been a while) these can be configured on a per-dataset basis, where a dataset is a lightweight filesystem more aki…

> disabling the writing of 'last accessed' timestamps atime is the most useless filesystem feature I’ve heard of. But on most Unix-like systems it’s enabled by default and the main thing it does is turn reads into writes, degrading performance. All the while ctime isn’t a standard Unix filesystem feature. And ctime to me always seemed infinitely more useful (and cheaper!) than atime.

relatime has been the Linux default since 2009. It makes that be one write per 24 hours.

Re: In OpenZFS and Btrfs, everyone was just guessing

#170

Post by noigai »

grumpyprole wrote: post #140

A terrifying accusation. I've had both OpenZFS and Btrfs eat my data, luckily I had backups but did lose a few files. XFS is probably the best bet on Linux, it was beautifully designed and implemented by SGI back in the day. Hopefully the ChatGPT generation don't start modifying that code too much.

> XFS is probably the best bet on Linux

Yes, agree. However, I also lost files on it (had files overwritten with 0s, as other people already commented here). Also, it's your best bet of you don't need the extra features provided by ZFS. Thanks to its checksum validation, I detected bad SATA cables three times already (on different systems), instead of getting corrupted data.

>it was beautifully designed and implemented by SGI back in the day. Hopefully the ChatGPT generation don't start modifying that code too much.

Except it's not what happened. Please check this talk from Dave Chinner, where he explains how XFS was developed and ported to Linux and then made robust and stable by him and other contributors. The disk format has changed many times, now it's robust and resilient against metadata corruption.

XFS Development talk by Dave Chinner https://m.youtube.com/watch?v=FegjLbCnoBw&t=683s&pp=ygUQeGZz...

History of Linux FS, also by Dave Chinner: https://m.youtube.com/watch?v=DxZzSifuV4Q&pp=ygUQeGZzIGRhdmU...

Post reply on HN