To view parent comment, click here.
To read all comments associated with this story, please click here.
PSARC has nothing to do with support cases or bug reports. PSARC stands for Plattform Support Architecture Review Commitee. That's a group of people in the Opensolaris design process discussing and voting about new additions to Solaris when it changes external interfaces or open new interfaces (ABI, command line commands et al) Looks bureaucratic at first, but at the end it's responsible for such stuff like the effectiveness of the binary compatibility guarantee and the systemic features like the dense coupling of containers, zfs snapshots and the new networking stack aka Crossbow for example.
Yeah. The problem/blessing with ZFS is that it detects many more errors than other filesystems, as it is end-to-end. ZFS being more sensitive than other filesystems, is a good thing. Which filesystem could have caught this?
http://blogs.sun.com/elowe/entry/zfs_saves_the_day_ta
And the problem was not ZFS fault. Instead, ZFS is the messenger. Dont shoot the messenger?






Member since:
2005-07-11
Another way to look at it is to ask whether or not LVM needs an fsck, since that's the layer in the ZFS storage system that's being worked on.
ZFS filesystems themselves rarely need fixing (I've never come across one, and haven't read about any online, but I've only been using ZFS for a year). They take care of that automatically using self-healing via checksums and redundancy, transactions, and copy-on-write.
The storage pool could become unimportable, but was usually fixable via arcane voodoo magic commands. Now, it's made a lot simpler (via the code implemented in the PSARC mentioned above -- PSARC is like a support case, or bug report, in Sun-speak).
There are tools for fixing LVM, though. And now there are tools to fix things at the storage pool layer in ZFS.
Asking for "fsck" doesn't make sense, though, as that's the wrong layer in the stack.