ZFS Panic after freebsd-update

[Alban Hertroys]

On Jul 1, 2013, at 19:04, Jeremy Chadwick <jdc at koitsu.org> wrote:

> But even stable/X doesn't provide enough coverage at times (the recent
> fxp(4)/dhclient issue is proof of that).  It's just too bad so many
> people have this broken mindset of what "stability" means on FreeBSD.


As one of the few persons who have run into that issue I feel like I should speak up here and add that this issue was fixed within a very reasonable time span after raising the matter here on freebsd-stable at . You've personally been a great help in getting that fixed, so thank you for that.

Apparently there was one earlier report of the issue very late in the pre-release process, which does imply that fxp hardware is fairly rarely in use among FreeBSD users these days (which was the excuse for how the issue passed testing for 8.4/9.1 RELEASE). I don't think the release engineering team can really be blamed for not catching bugs that go unreported that far into the release cycle; they have to make a decision when to release at some point and the later it gets into the cycle the harder it is to turn that decision around. I can completely understand that.

That this happened was inconvenient, but it happens in stable. ISTR that "stable" doesn't mean stable in the sense that it won't crash, but rather that the API's won't change until the next release. I wish other OS companies were as reliable; both MS and Apple let a lot more slip by and they take a lot longer to release fixes as well.

Of course nobody likes when their system behaves erratically due to some error outside their control, but until that point FreeBSD has been rock-solid for me for years. And even with this issue, the system was usable.


To get back to the ZFS issue...
ZFS has always seen a fairly large fraction of raised issues on this list. Often those were user mistakes, ranging from putting not enough memory into the system to not assigning enough to the ZIL (once that became usable). ZFS on FreeBSD has come a long way since then. I don't think it's in quite as usable a state on, for example, Linux.

Yes, people are taking a risk when using ZFS for everything. The same goes for any FS. No matter which file system you use, if it breaks you're between a rock and a hard place. Depending on how badly broken it is, you may end up not being able to access your data and with some data that's not an option. That's what we have backups and test environments for, don't we?

File system code can break. It shouldn't, and I think it's safe to say that in FreeBSD's history it has been very rare indeed, but it does happen. The problem is probably more that it's so rare that people don't take measures for the few times it does happen; like how many of us have an atomic shelter available to them? Or a rubber boat? How many nuclear incidents have there been versus how many serious file-system breakages in FreeBSD? How many of us first test an update to STABLE on an identical test system before upgrading our production servers?

Jeremy, I know for a fact that you're a lot more on this list than I am and probably longer than I have been (I'm pretty sure you were around already back in the days when I started using FreeBSD 2.2.8), but in this case, as much respect as I have for you, I think you're overreacting a bit.

And finally, we're having this whole discussion about how problematic FreeBSD's been (or not) recently WHILE THE OP HASN"T EVEN GOTTEN BACK TO ANSWER DETAILS ABOUT HIS ISSUE YET. Perhaps it's a bit early for that? It's entirely possible that we're looking at some hardware issue here or a user error that triggered a corner case that wasn't handled or something like that.


P.S: Personally, I don't use ZFS because I'm a bit of a database nut and feel like log-based file-systems aren't a good match for database write loads, but that's mostly just me being pedantic.

Cheers,

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.