5 ms·

> If you want to get the fs back to a state before there was corruption, you use the transaction history. How? ZFS refuses to mount/import a corrupt filesystem

> If you want to get the fs back to a state before there was corruption, you use the transaction history. How? ZFS refuses to mount/import a corrupt filesystem. In my case, the latest superblock (or some internal bookkeeping structures that the superblock points to) was corrupted in a way that ZFS completely gave up. So what I ended up doing is to manually invalidate the latest superblocks until ZFS was able to mount the filesystem. I may have lost the changes written in the few minutes before the corruption, but that's still way better than loosing everything. Before I decided to poke around the raw disk with dd (to invalidate the superblocks by overwriting them with zeros), I googled around and I wasn't the only one with that problem. One other guy asked on the ZFS mailing list and the response was along the lines of 'Your filesystem is FUBAR, restore from backup'. You may argue that ZFS itself should do what I did (dropping a few minutes of transaction history and roll back to the latest non-corrupt state) upon mounting. Fair enough. I don't really care if that functionality is built into ZFS or an external fsck binary. The fact is that ZFS wasn't able to recover from the situation. One that I would argue is very trivial to recover from if you know the internal ZFS on-disk structure.

deelowe 14y ago
So, you're argument then is that this is something a fsck would normally do? You may have found a corner case in the fs and perhaps this sort of thing should be added to the import command, but I'm not sure simply having an "fsck" fixes this. I just think the import command appears to have a bug/needs a feature.
- wereHamster 14y ago
  How's zdb different from fsck? Nobody cares whether the tool is called fsck, scrub or zdb. You just need to have a tool which can recover from corruption. And for very long the ZFS developers didn't think the end-users needed it. Maybe zdb was there all the time. But it wasn't advertised or documented. People were told their filesystem is FUBAR when it wasn't.
  - glabifrons 14y ago
    "How's zdb different from fsck?" That's answered very well in the article connected to this other currently active HN discussion: https://news.ycombinator.com/item?id=5460988 https://news.ycombinator.com/item?id=5460988 In short, fsck simply checks to see that the metadata makes sense, and that all inodes belong to files, and that all files belong to directories, and if it finds any that don't, it attaches them to a file with a number for a name in lost+found. It's pretty crude compared to a filesystem debugger. If you want to compare apples-to-apples, you'd be better off asking how zdb compares to debugfs (for ext2/3/4) as both are filesystem debuggers. You could also ask "How's zfs scrub different from fsck?" and the answer to that would be: zfs scrub checks every bit of data and metadata against saved checksums to ensure integrity of everything on-disk. In comparison, fsck cannot detect data corruption at all, and can only detect metadata corruption when an inode points to an illegal disk region (for example). Even that comparison shows fsck is crude when compared to scrub. The tool to recover from corruption is a rollback: usage: clear [-nF] <pool> [device]
deleted 14y ago
[deleted]
glabifrons 14y ago
"How? ZFS refuses to mount/import a corrupt filesystem." zpool clear -F $POOLNAME http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-support.html http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-re...

deelowe 14y ago

So, you're argument then is that this is something a fsck would normally do? You may have found a corner case in the fs and perhaps this sort of thing should be added to the import command, but I'm not sure simply having an "fsck" fixes this. I just think the import command appears to have a bug/needs a feature.

wereHamster 14y ago
How's zdb different from fsck? Nobody cares whether the tool is called fsck, scrub or zdb. You just need to have a tool which can recover from corruption. And for very long the ZFS developers didn't think the end-users needed it. Maybe zdb was there all the time. But it wasn't advertised or documented. People were told their filesystem is FUBAR when it wasn't.
- glabifrons 14y ago
  "How's zdb different from fsck?" That's answered very well in the article connected to this other currently active HN discussion: https://news.ycombinator.com/item?id=5460988 https://news.ycombinator.com/item?id=5460988 In short, fsck simply checks to see that the metadata makes sense, and that all inodes belong to files, and that all files belong to directories, and if it finds any that don't, it attaches them to a file with a number for a name in lost+found. It's pretty crude compared to a filesystem debugger. If you want to compare apples-to-apples, you'd be better off asking how zdb compares to debugfs (for ext2/3/4) as both are filesystem debuggers. You could also ask "How's zfs scrub different from fsck?" and the answer to that would be: zfs scrub checks every bit of data and metadata against saved checksums to ensure integrity of everything on-disk. In comparison, fsck cannot detect data corruption at all, and can only detect metadata corruption when an inode points to an illegal disk region (for example). Even that comparison shows fsck is crude when compared to scrub. The tool to recover from corruption is a rollback: usage: clear [-nF] <pool> [device]

deleted 14y ago

[deleted]

glabifrons 14y ago

"How? ZFS refuses to mount/import a corrupt filesystem." zpool clear -F $POOLNAME http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-support.html http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-re...