Hacker News Reader

Comment by daneel_w | Hacker News Reader

Are you sure it's not just a dodgy SSD that simply failed to persist data when losing power mid-write? I've had my share of sudden power cuts upon OpenBSD during the past 20+ years, and FFS has so far never gone corrupt on me.

View on HN

I do not believe so?

Drive is a 2TB Intel 670p NVMe SSD (INTEL SSDPEKNU020TZ) with 9078 power on hours and 42TBW - so pretty spry, but not at the start of the bathtub curve either.

It was mounted as fast storage for a Bitcoin node.

Perhaps the only 'unique' thing is it is using a NVMe to PCIe adapter card (Synology M2D20) due to this being my "legacy" server that's still rocking a Broadwell chip.

That does sound pretty spry. But it doesn't rule out that it utilizes slow storage which is fronted by a (too) large RAM buffer making the device appear much faster than it really is. Most SSDs are like this.

FFS corrupted multiple times on me, with intel video driver freezing on OpenBSD. My short OpenBSD sidetrack ended after reliably corrupting itself the third time... every time video driver panicking, leaving a corrupted filesystem after reboot, when I had eg. ports install going on during panic.

Windows ran fine on the machine (Lenovo 200) before, and Linux ran fine after. FFS (and the intel video drivers) are the weakest part of OpenBSD in my experience, I liked many other aspects.

If writes are happening while the power cuts you will lose that data. Journaling doesn't help against this. FFS will need a consistency check if it doesn't "unmount cleanly", but this isn't the same as the file system having been corrupted and losing data. If something really got corrupted and it was something else besides what you were writing in the moment the machine died, it sounds like a lot of data (for whatever reason large amounts of data was still buffered; usually an SSD is the reason) just hadn't persisted yet. With the exception of the old unadvisable softdeps feature, FFS doesn't defer a lot of writing. And It's possible to tell FFS to be fully synchronous, with the caveat that it becomes even slower than the sluggish performer it already is.

I've seen file corruption with FFS on some of my OpenBSD servers, though them being VMs is likely a factor there.

Qcow2 will zero blocks on power loss, at least in some configurations.

Reply on news.ycombinator.com