On Tue, 29 Jun 2010 18:34:13 +0200, Hubert Kario <h...@qbs.com.pl> wrote: > On Tuesday 29 June 2010 12:37:45 Daniel Kozlowski wrote: >> On Mon, Jun 28, 2010 at 10:31 PM, Rodrigo E. De León Plicet >> >> <rdele...@gmail.com> wrote: >> > On Mon, Jun 28, 2010 at 8:48 AM, Daniel Kozlowski >> > >> > <dan.kozlow...@gmail.com> wrote: >> >> Sean Bartell <wingedtachikoma <at> gmail.com> writes: >> >>> > Is there a more aggressive filesystem restorer than btrfsck? It >> >>> > simply gives up immediately with the following error: >> >>> > >> >>> > btrfsck: disk-io.c:739: open_ctree_fd: Assertion >> >>> > `!(!tree_root->node)' failed. >> >>> >> >>> btrfsck currently only checks whether a filesystem is consistent. It >> >>> doesn't try to perform any recovery or error correction at all, so >> >>> it's >> >>> mostly useful to developers. Any error handling occurs while the >> >>> filesystem is mounted. >> >> >> >> Is there any plan to implement this functionality. It would seem to me >> >> to be a pretty basic feature that is missing ? >> > >> > If Btrfs aims to be at least half of what ZFS is, then it will not >> > impose a need for fsck at all. >> > >> > Read "No, ZFS really doesn't need a fsck" at the following URL: >> > >> > http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.h >> > tml >> >> Interesting idea. it would seem to me however that the functionality >> described in that article is more concerned with a bad transaction >> rather then something like a hardware failure where a block written >> more then 128 transactions ago is now corrupted and consiquently the >> entire partition is now unmountable( that is what I think i am looking >> at with BTRFS ) > > Still, the FS alone should be able to recover from such situations. With
> multiple superblocks the probability that the fs is unmountable is very > small > and if all superblocks are corrupted then you need a data recovery > prorgram, > not fsck. On Tue, 29 Jun 2010 18:34:13 +0200, Hubert Kario <h...@qbs.com.pl> wrote: > On Tuesday 29 June 2010 12:37:45 Daniel Kozlowski wrote: >> On Mon, Jun 28, 2010 at 10:31 PM, Rodrigo E. De León Plicet >> >> <rdele...@gmail.com> wrote: >> > On Mon, Jun 28, 2010 at 8:48 AM, Daniel Kozlowski >> > >> > <dan.kozlow...@gmail.com> wrote: >> >> Sean Bartell <wingedtachikoma <at> gmail.com> writes: >> >>> > Is there a more aggressive filesystem restorer than btrfsck? It >> >>> > simply gives up immediately with the following error: >> >>> > >> >>> > btrfsck: disk-io.c:739: open_ctree_fd: Assertion >> >>> > `!(!tree_root->node)' failed. >> >>> >> >>> btrfsck currently only checks whether a filesystem is consistent. It >> >>> doesn't try to perform any recovery or error correction at all, so >> >>> it's >> >>> mostly useful to developers. Any error handling occurs while the >> >>> filesystem is mounted. >> >> >> >> Is there any plan to implement this functionality. It would seem to me >> >> to be a pretty basic feature that is missing ? >> > >> > If Btrfs aims to be at least half of what ZFS is, then it will not >> > impose a need for fsck at all. >> > >> > Read "No, ZFS really doesn't need a fsck" at the following URL: >> > >> > http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.h >> > tml >> >> Interesting idea. it would seem to me however that the functionality >> described in that article is more concerned with a bad transaction >> rather then something like a hardware failure where a block written >> more then 128 transactions ago is now corrupted and consiquently the >> entire partition is now unmountable( that is what I think i am looking >> at with BTRFS ) > > Still, the FS alone should be able to recover from such situations. With > multiple superblocks the probability that the fs is unmountable is very > small > and if all superblocks are corrupted then you need a data recovery > prorgram, > not fsck. While it would be great to have a filesystem that can recover from such situations, or at least fail gracefully, I'd also like to be able to verify/repair the filesystem offline, without mounting it and potentially making things worse. For example, say you have a single-disk filesystem, and while it can detect corruption it can't repair it. That's the sort of scenario where you want to specify what to do, interactively or with command line options. I don't want the only choice to be bringing it online and destructively forcing it into a consistent state based on variables I don't control like when someone attempts to access the file. Regards, -Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
