| News | Features | Interviews |
| Blog | Contact | Editorials |
| Should ZFS Have a fsck Tool? |
| By special contributor Pobrecito Hablador on 2009-11-02 21:19:10 |
| One of the advantages of ZFS is that it doesn't need a fsck. Replication, self-healing and scrubbing are a much better alternative. After a few years of ZFS life, can we say it was the correct decision? The reports in the mailing list are a good indicator of what happens in the real world, and it appears that once again, reality beats theory. The author of the article analyzes the implications of not having a fsck tool and tries to explain why he thinks Sun will add one at some point. |
|
| You are wrong. |
| By Burana on 2009-11-02 21:34:16 |
|
Most of your listed problems are related to the problem of buggy hardware, resulting in failed transactions. This PSARC http://c0t0d0s0.org/archives/606... will solve this. We don't need no stinking fsck. |
 - Score: 6 |
| RE: You are wrong. |
| By sbergman27 on 2009-11-02 21:39:36 |
|
> We don't need no stinking fsck. Because ZFS is unsinkable. |
| - Score: 1 |
| RE: You are wrong. |
| By phoenix on 2009-11-02 21:42:51 |
|
That, plus background scrubbing, give you the same end result as an fsck. No real need for a separate fsck. If needed, one can just alias "zpool scrub <poolname>" to fsck and be done with it. ;) |
| - Score: 5 |
| I have seen more technical insight... |
| By fernandotcl on 2009-11-02 21:51:55 |
| ...in cake recipes... |
| - Score: 0 |
| fsck isn't the end all of file system repair |
| By jrash on 2009-11-02 22:15:06 |
| I doubt that a ZFS fsck would be able to recover the trashed file systems in those posts/bug reports. File systems like Ext2/3 have simple designs that can be easily repaired by an fsck, however ZFS is an extremely complex file system and I don't see what an fsck would do that the file system doesn't do already. |
| - Score: 1 |
| . |
| By renhoek on 2009-11-02 22:19:31 |
| And what is this fsck supposed to check and fix? As soon as somebody can answer this a fsck tool wil be made i think. |
| - Score: 4 |
| ZFS was a good first step |
| By kragil on 2009-11-02 22:39:46 |
|
FS devs learned a few lessons. FS development became sexy again and everyone saw the need for a new filesysten. That said, ZFS will be the pioneer with arrows in his back. Other FSs will offer more features and better performance soonish with less resource usage and a more elegant design. (And I don't think Oracle with stop Solaris' negative growth rates.) |
| - Score: 1 |
| Did you read the article? |
| By JoeBuck on 2009-11-02 22:42:13 |
| The article states directly that the problems causing the corruption were related to bad hardware! Bad hardware is a fact of life, and the existence of bad hardware is the reason why some fsck-like tool is needed. |
| - Score: 3 |
| ZFS Is a rock solid. |
| By Troydm on 2009-11-02 22:43:57 |
| It won't fail that easily. i have a home server based on zfs and even frequent power losses don't render data useless proven by 2 years of 24/7 always online usage. Before i had ufs based setup and every 6-8 power loss rendered data so useless that even fsck couldn't fix the problem. ZFS is as solid as rock. |
| - Score: 3 |
| ZFS doesn't need a fsck |
| By c0t0d0s0 on 2009-11-02 22:54:28 |
|
At first a fsck doesn't solve a lot of problem. It checks the filesystem, but not the data. It's called fsck and not datackc for a reason. So we end of with a mountable filesystem, but the data in it ... that's a different story. With ZFS you can tackle the problem from a different perspective. At first you have to keep two things in mind (sorry, simplifications ahead): ZFS works with transaction groups and ZFS is copy-on-write. Furthermore you have to know that there isn't one uberblock, there are 128 of them, (transaction group number modulo 128 is the uberblock used for a certain transaction group). Given this points, there is a good chance, that you have an consistent state of your filesystem shortly before the crash and that it hasn't overwritten since due to the COW. So you just have to rollback the transaction-groups until you have a state that can be scrubbed without errors .... and you have a recovered state that is consistent and with validated integrity. You just lost the last few transactions. That can't be done with a fsck tool. You can't guarantee the the integrity of the data after the system reported back to you, that the filesystem has been recovered. You may call the results of PSARC 2009/479 something like an fsck tool, but it isn't. It just leverages the transactional behaviour of ZFS to enable other tools to do their work ( http://www.c0t0d0s0.org/archives... ) Just to end it here: ZFS doesn't need a fsck tool, because it doesn't solve the real problem. ZFS needs something better and with all the features of ZFS in conjunction with PSARC 2009/479 it will deliver something better. |
| - Score: 4 |
| News | Features | Interviews |
| Blog | Contact | Editorials |