On Thu, 2012-10-18 at 22:15 +0200, Piotr Szymaniak wrote: > On Mon, Oct 15, 2012 at 10:18:08AM +0400, Vyacheslav Dubeyko wrote: > > On Sun, 2012-10-14 at 22:08 +0200, Piotr Szymaniak wrote: > > > On Sun, Oct 14, 2012 at 06:55:59PM +0400, Vyacheslav Dubeyko wrote: > > > > > > > > So, it is clear that #359 segment is empty. Moreover, #357 segment doesn't contain ifile block with blkoff = 2 as I can see from dumpseg output. Currently, I know that #358 segment contains empty ifile block with blkoff = 2. It needs to find segment which contains not empty block of ifile for blkoff = 2. Could you share dumpseg output of all previous segments (for #358)? > > > > > > dumpseg of blocks 340 → 357 attached (I hope, the file is ~200KB). > > > > > > > As I can see, checkpoints #1843 and #1819 contain ifile's block with blkoff = 2. > > > > Could you check state of blocks 719300 and 698817? If any of these blocks are not empty then, please, send the raw dump of non-empty block(s). > > Both dumps attached. > As I can see, both dumps contains blocks of ifile with inodes description. I check previous e-mails and can see that maybe you dump not proper block. Maybe it is my misspelling in some e-mail. It needed to dump #734205 but as I can see you share dump of #743205 block. Firstly, to check that block #734205 is really empty. Because if it is not empty then the situation is different. If the block #734205 is empty then I suggest to make some experiment: 1. Prepare dump of the corrupted partition: dd if=<partition (/dev/sdb1)> of=<image file> 2. Setup loop device for the image: losetup /dev/loop0 <image file> 3. Copy block #719300 of ifile (ino = 6) with blkoff = 2 of checkpoint #1843 into empty block #734205 (checkpoint #1874): dd if=/dev/loop0 of=/dev/loop0 bs=4096 skip=719300 seek=734205 count=1 4. Try to mount the loop device. Please, share results (console output and dmesg output) of this trying to mount. But, please, first of all, CHECK THAT TARGET BLOCK IS REALLY EMPTY. This manual manipulation can lead to loosing some filesystem state. Moreover, it can't fully recover filesystem but maybe driver can recover filesystem and to mount. With the best regards, Vyacheslav Dubeyko. > Piotr Szymaniak. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
