On Sat, 6 Dec 2008 20:53:08 +0100, Reinoud Zandijk <[EMAIL PROTECTED]> wrote: > Hi folks, hi Ryusuke, > > On Sun, Dec 07, 2008 at 04:05:09AM +0900, Ryusuke Konishi wrote: > > On Thu, 4 Dec 2008 14:04:31 +0100, Adrian Ulrich wrote: > > Sorry to keep you waiting. ;-) > > > > I will attach a patch against nilfs2-utils-2.0.6, which adds the > > tool 'fsck0.nilfs2'. > > > > # fsck0.nilfs2 <device name> > > > > will, hopefully, correct your partition. > > (I'm not sure because it's not yet tested enough) > > looks nice Ryusuke. Could the problem be averted though by *only* writing the > superblock on dismount or when the origional block would be overwritten. > Seperated by a disc flush of course :)
Well, unless NILFS itself had destroyed data by bugs, the filesystem should have a very good chance to be salvaged by only modifying the superblock like this tool does. The GC may have reused data blocks needed by the re-selected old checkpoint, but it is likely very few since there is time lag from when blocks are marked unused to when they are actually overwritten under the current GC policy (i.e. FIFO order poclicy). Is this answering your question? Regards, Ryusuke Konishi _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
