Hacker News Reader

Comment by oridb | Hacker News Reader

Author here: correct, it's currently on the user to deal with corrupted data. I'm not opposed to adding a RAID layer, but I also want to explore what adding trim-style feedback to a generic RAID layer may look like, so that different file systems could share the work.

We'll see where things go.

View on HN

> […] but I also want to explore what adding trim-style feedback to a generic RAID layer may look like […]

TRIM commands sent to the block layer would probably help with SSD/NVMe wear leveling, as well as thin-provisioning in virtualized environments.

And the lack of RAID is not a critique: if you're mostly interested in the file system layer that's fine, and a useful area to solve problems in. My comment was more towards the comparison to ZFS and its "rampant layering violation" [1] and some of the trade-offs that happen when you focus on more or fewer parts of the stack.

[1] https://web.archive.org/web/20070602005153/http://blogs.sun....

Unrelated: and since you're surfing the comments, with regards to your superblocks [1], you may wish to look into some of the lessons learned by ZFS; specifically see perhaps Allan Jude's "Large Label and Blockpointer-V2" from the 2025 OpenZFS Dev Summit: https://www.youtube.com/watch?v=3tqOBv8BmXI

[1] https://orib.dev/gefs.pdf § 9.1

I don't mean a literal trim command to the block device, but hints that get passed to the RAID layer to mark how blocks should be spread among the backing devices. I haven't put much thought into the details, but I suspect that there might not be so much information needed, so the RAID layer could be both generic and smart. It may not work out.

I'll probably be picking Allan's brain on a few things in the coming few months; amusingly, he mentioned doesn't use ZFS for ZFS development so that he can unload and reload the module, and he's interested in something that won't corrupt when he panics the kernel.

Hi author :) Must say that 8k+ lines is a little bit annoying and uneasy to handle... But also bribgs a lot of hope and happiness :)

To the point:

- llm'ed or not, dasn't matter, just quality matter

- raid ? I know nothing about that but looks like pure hardware raid (if that exists), no "raid layers" at all and fs raid aware are three different animals. But adding something about raids will complicate things before "production ready" stability. Which, of course, we want ASAP ;)

- 8k+ seems easy to manage and bend so maybe key-value only partitions ?

- obviously wishlist is easy to construct (key-value storage, encryption, power off resistance, mail reading ;) ) so maybe some plugin system or at least guidelines for peoples before we will have repos of patches DWM-style ? :)

- that 5 second is clearly stated but a bit strange limit and obviously peoples will want to do something with that

- man give us producion readiness before you will be puched by some corporation, swamped with work and hidden from daylight, pls ? Pleas do not fall into Compiz trap...

- thank you :)

> I don't mean a literal trim command to the block device, but hints that get passed to the RAID layer to mark how blocks should be spread among the backing devices.

At this point in software/file system history, having some kind of TRIM functionality I think is pretty important: either built in, or a separate utility (like fstrim(8) for ext4, etc).

Are you planning to (eventually?) do a RAID (or at least mirror) layer, or will this strictly stick do file systems?

Reply on news.ycombinator.com