Hi, On Oct 12, 2012, at 3:40 PM, Piotr Szymaniak wrote: > On Fri, Oct 12, 2012 at 03:07:33PM +0400, Vyacheslav Dubeyko wrote: >> On Fri, 2012-10-12 at 12:31 +0200, Piotr Szymaniak wrote: >> >>> How to dump second superblock? >>> Number of segments: 922 >>> Device size: 7741636608 >>> >>> Should I dump last 4096 bytes of device size? >>> >> >> Yes, as I can understand, dump of last 4096 bytes of device size should contain second superblock. > > Attached. > > Piotr Szymaniak. > -- > Szczególnie ponurzy byli ludzie w prosektorium. Spoglądali na mnie > badawczym wzrokiem, jakby się dziwili, dlaczego jeszcze żyję, > i chcieli ocenić, ile ważę, ile mam krwi do wypompowania i treści > w jelitach do usunięcia. > -- Jacek Hugo‑Bader, „W rajskiej dolinie wśród zielska” > <secondary-sb.out.bz2> I have compared primary and secondary superblocks and discovered some differences: Primary SB: > Filesystem created: Fri Aug 3 08:37:06 2012 > Last mount time: Thu Jan 1 01:00:01 1970 > Last write time: Thu Jan 1 01:00:01 1970 Secondary SB: Filesystem created: 0x501b7192 Last mount time: 0x1 Last write time: 0x5073495e It is possible to see strange difference in last write time. I mean that in secondary superblock last write time contains real time that was updated after filesystem creation. If Raspberry Pi doesn't have RTC then it is not so clear how the last write time was updated and only in secondary superblock. Primary superblock: > Mount count: 56 ... > Number of segments: 922 > Device size: 7741636608 ... > Last checkpoint #: 1873 > Last block address: 734128 > Last sequence #: 358 > Free blocks count: 1150976 Secondary superblock: Mount count: 56 ... Number of segments: 922 Device size: 7741636608 ... Last checkpoint #: 1884 Last block address: 734512 Last sequence #: 358 Free blocks count: 1150976 So, we have identical mount counts, free blocks count, last sequence. But last checkpoint and last block address are different in primary and secondary superblocks. Primary SB: > Filesystem state: invalid or mounted Secondary SB: Filesystem state: unmounted cleanly. So, I have such feeling that secondary superblock was flushed during umount but primary superblock was not. On Oct 13, 2012, at 12:56 AM, Piotr Szymaniak wrote: On Tue, Oct 09, 2012 at 12:52:39PM +0200, Piotr Szymaniak wrote: >>> I think that first of all it needs to detect that it is NILFS2 issue but >>> not hardware or MMC stack issue. >> >> Will connect some screen via HDMI to check if there's some error msg. >> The card should be fine, but I will dd it to disk to check for read >> errors. > > Sorry for answering my own mail. Connected Raspberry Pi to a screen and > here's the output: > > # -- > segctord starting. Construction interval = 300 seconds. CP frequency < 30 seconds > NILFS: corrupt root inode. > List of all partitions: > b300 7883776 mmchlk0 driver: mmcblk > b301 57344 mmcblk0p1 00000000-0000-0000-0000-000000000000 > b302 262144 mmcblk0p2 00000000-0000-0000-0000-000000000000 > b303 7560192 mmcblk0p3 00000000-0000-0000-0000-000000000000 > 0800 7816704 sda driver: sd > 0801 7016688 sda1 00000000-0000-0000-0000-000000000000 > No filesystem could mount root, tried: nilfs2 > Kernel panic - not syncing: VFS: Unable to mount root is on unknown-block(179,3) > [<c001537c>] (unwind_backtrace+0x0/0xfc) from [<c0421c2c>] (dump_stack+0x20/0x24) > [<c0421c2c>] (dump_stack+0x20/0x24) from [<c0421de0>] (panic+0x70/0x1a0) > [<c0421de0>] (panic+0x70/0x1a0) from [<c05d4cf0>] (mount_block_root+0x1f4/0x254) > [<c05d4cf0>] (mount_block_root+0x1f4/0x256) from [<05d4f64>] (mount_root+0xf0/0x114) > [<c05d4f64>] (mount_root+0xf0/0x114) from [<c05d50e4>] (prepare_namespace+0x15c/0x1c0) > [<c05d50e4>] (prepare_namespace+0x15c/0x1c0) from [<c05d48dc>] (kernel_init+0x100/0x130) > [<c05d48dc>] (kernel_init+0x100/0x130) from [<c000f00c>] (kernel_thread_exit+0x0/0x8) > # -- I think that here we can see consequence but not the reason. The issue occurred more earlier during umount or flushing. Currently, I can't understand what filesystem activity ends with such issue. Anyway, it needs to reproduce the issue on your side. On Oct 12, 2012, at 2:31 PM, Piotr Szymaniak wrote: > On Fri, Oct 12, 2012 at 11:10:32AM +0400, Vyacheslav Dubeyko wrote: > [snip] >> Thereby, there is some probability of primary superblock inconsistency. Could you share raw dump of second superblock that is located at the volume end? Moreover, could you share dumpseg of next segment after last sequence # (namely, 359) and before of it (namely, 357)? > > apo ~ # dumpseg /dev/sdd3 359 > segment: segnum = 359 > > #357 attached. 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)? With the best regards, Vyacheslav Dubeyko. -- 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
