NILFS: corrupt root inode after Turbo Mode?

NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

Hi list.

I'm using nilfs2 on my Raspberry Pi rootfs. I've played around with
Raspberry Pi Turbo Mode and today it refused to boot. It's a headless
setup so I moved the SD Card to my other machine and tried to mount
rootfs partition:

maszyn ~ # mount.nilfs2 /dev/sdf3 /tmp/rpi
mount.nilfs2: Error while mounting /dev/sdf3 on /tmp/rpi: Invalid
argument

dmesg shows:
(...)
[43893.754525] segctord starting. Construction interval = 300 seconds,
CP frequency < 30 seconds
[43893.760245] NILFS: corrupt root inode.

Where should I go from here? I can hook it up via HDMI to some screen to
see if there's some error msg on rPi.

I'm using official Raspberry Pi linux 3.2.27 from github [1] (last
updated 2-4 days ago).

[1] https://github.com/raspberrypi/linux


Piotr Szymaniak.
-- 
 ALARM.
 Przyspieszasz kroku, zbiegasz po stoku. Nie mozesz sie ruszyc ni w przod,
ni w tyl, spojrz prosto w lufe i modl sie, bys zyl, zyl, zyl.
   -- Ken Kesey, "One Flew Over The Cuckoo's Nest"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> Hi list.
> 
> I'm using nilfs2 on my Raspberry Pi rootfs. I've played around with
> Raspberry Pi Turbo Mode and today it refused to boot. It's a headless
> setup so I moved the SD Card to my other machine and tried to mount
> rootfs partition:
> 

As I can understand Raspberry Pi Turbo Mode is a hardware overclocking.
So, I worry about proper working of SD-card controller. It is possible
that the reason of the issue can be not proper controller functioning or
concrete SD-card issue.

Could you try to reproduce the issue with using another SD-card in Turbo
and normal mode?

I think that first of all it needs to detect that it is NILFS2 issue but
not hardware or MMC stack issue.

With the best regards,
Vyacheslav Dubeyko.


> maszyn ~ # mount.nilfs2 /dev/sdf3 /tmp/rpi
> mount.nilfs2: Error while mounting /dev/sdf3 on /tmp/rpi: Invalid
> argument
> 
> dmesg shows:
> (...)
> [43893.754525] segctord starting. Construction interval = 300 seconds,
> CP frequency < 30 seconds
> [43893.760245] NILFS: corrupt root inode.
> 
> Where should I go from here? I can hook it up via HDMI to some screen to
> see if there's some error msg on rPi.
> 
> I'm using official Raspberry Pi linux 3.2.27 from github [1] (last
> updated 2-4 days ago).
> 
> [1] https://github.com/raspberrypi/linux
> 
> 
> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

On Tue, Oct 09, 2012 at 11:29:53AM +0400, Vyacheslav Dubeyko wrote:
> Hi,
> 
> On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> > Hi list.
> > 
> > I'm using nilfs2 on my Raspberry Pi rootfs. I've played around with
> > Raspberry Pi Turbo Mode and today it refused to boot. It's a headless
> > setup so I moved the SD Card to my other machine and tried to mount
> > rootfs partition:
> > 
> 
> As I can understand Raspberry Pi Turbo Mode is a hardware overclocking.
> So, I worry about proper working of SD-card controller. It is possible
> that the reason of the issue can be not proper controller functioning or
> concrete SD-card issue.

It's an “allowed” overcloking. I have another SD Card with Raspbian (and
without nilfs2) that works fine with Turbo Mode. At least it seems to
work fine. The second card was in Turbo Mode (@900MHz) for a few days
and was working. Yesterday i made it @1000MHz and it didn't boot.


> Could you try to reproduce the issue with using another SD-card in Turbo
> and normal mode?

Not now. Don't have any image of my setup with nilfs2. ):


> 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.

Piotr Szymaniak.


> With the best regards,
> Vyacheslav Dubeyko.
> 
> 
> > maszyn ~ # mount.nilfs2 /dev/sdf3 /tmp/rpi
> > mount.nilfs2: Error while mounting /dev/sdf3 on /tmp/rpi: Invalid
> > argument
> > 
> > dmesg shows:
> > (...)
> > [43893.754525] segctord starting. Construction interval = 300 seconds,
> > CP frequency < 30 seconds
> > [43893.760245] NILFS: corrupt root inode.
> > 
> > Where should I go from here? I can hook it up via HDMI to some screen to
> > see if there's some error msg on rPi.
> > 
> > I'm using official Raspberry Pi linux 3.2.27 from github [1] (last
> > updated 2-4 days ago).
> > 
> > [1] https://github.com/raspberrypi/linux
> > 
> > 
> > Piotr Szymaniak.
> 

-- 
  Powiedzieli nam,  że zbrodnia jest czymś złym i nieludzkim, a później
nauczyli nas zabijac.
  -- Wieslaw Gwiazdowski, "Mysliwi"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Tue, Oct 09, 2012 at 11:29:53AM +0400, Vyacheslav Dubeyko wrote:
> *snip*
> I think that first of all it needs to detect that it is NILFS2 issue but
> not hardware or MMC stack issue.

I did a dd from the card to local hard drive without issues.


Piotr Szymaniak.
-- 
Tak szybkie przemieszczanie się ośrodka niżowego i towarzyszącego
mu frontu chłodnego świadczy o odbudowie cyrkulacji zachodniej
z niewielkim odchyleniem północnym, transportującej do kraju
w najbliższych dniach świeże powietrze atlantyckie okraszone
islandzkim dymem wulkanicznym.
  -- Maciej Ostrowski, synoptyk ICM

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi Piotr,

On Tue, 2012-10-09 at 12:52 +0200, Piotr Szymaniak wrote:
> On Tue, Oct 09, 2012 at 11:29:53AM +0400, Vyacheslav Dubeyko wrote:
> > Hi,
> > 
> > On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> > > Hi list.
> > > 
> > > I'm using nilfs2 on my Raspberry Pi rootfs. I've played around with
> > > Raspberry Pi Turbo Mode and today it refused to boot. It's a headless
> > > setup so I moved the SD Card to my other machine and tried to mount
> > > rootfs partition:
> > > 
> > 
> > As I can understand Raspberry Pi Turbo Mode is a hardware overclocking.
> > So, I worry about proper working of SD-card controller. It is possible
> > that the reason of the issue can be not proper controller functioning or
> > concrete SD-card issue.
> 
> It's an “allowed” overcloking. I have another SD Card with Raspbian (and
> without nilfs2) that works fine with Turbo Mode. At least it seems to
> work fine. The second card was in Turbo Mode (@900MHz) for a few days
> and was working. Yesterday i made it @1000MHz and it didn't boot.
> 
> 
> > Could you try to reproduce the issue with using another SD-card in Turbo
> > and normal mode?
> 
> Not now. Don't have any image of my setup with nilfs2. ):
> 
> 
> > 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.
> 

First of all, I need some details about your NILFS2 partition for issue analysis.

I need in:
1. Full output of "lscp -a".
2. Full output of "lssu -a".
3. Output of dumpseg for segment #0.

Could you share these outputs?

Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.

With the best regards,
Vyacheslav Dubeyko.


> Piotr Szymaniak.
> 
> 
> > With the best regards,
> > Vyacheslav Dubeyko.
> > 
> > 
> > > maszyn ~ # mount.nilfs2 /dev/sdf3 /tmp/rpi
> > > mount.nilfs2: Error while mounting /dev/sdf3 on /tmp/rpi: Invalid
> > > argument
> > > 
> > > dmesg shows:
> > > (...)
> > > [43893.754525] segctord starting. Construction interval = 300 seconds,
> > > CP frequency < 30 seconds
> > > [43893.760245] NILFS: corrupt root inode.
> > > 
> > > Where should I go from here? I can hook it up via HDMI to some screen to
> > > see if there's some error msg on rPi.
> > > 
> > > I'm using official Raspberry Pi linux 3.2.27 from github [1] (last
> > > updated 2-4 days ago).
> > > 
> > > [1] https://github.com/raspberrypi/linux
> > > 
> > > 
> > > Piotr Szymaniak.
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 864 bytes --]

On Tue, Oct 09, 2012 at 04:08:34PM +0400, Vyacheslav Dubeyko wrote:
> First of all, I need some details about your NILFS2 partition for issue analysis.
> 
> I need in:
> 1. Full output of "lscp -a".
> 2. Full output of "lssu -a".
> 3. Output of dumpseg for segment #0.
> 
> Could you share these outputs?

Sure!
maszyn ~ # lscp -a /dev/sdf3
lscp: /dev/sdf3: cannot open NILFS
maszyn ~ # lssu -a /dev/sdf3
lssu: /dev/sdf3: cannot open NILFS

(the card is in a card reader)

> Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.

maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out

Attached.


Piotr Szymaniak.
-- 
Od  czasu  do  czasu  bij swoja zone,  jezeli ty nie wiesz za co ona na
pewno bedzie wiedziec.
  -- Przyslowie arabskie

[-- Attachment #1.2: dumpseg-0.out.bz2 --]
[-- Type: application/x-bzip2, Size: 10778 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Ryusuke Konishi]

Hi,
On Tue, 9 Oct 2012 15:58:33 +0200, Piotr Szymaniak wrote:
> On Tue, Oct 09, 2012 at 04:08:34PM +0400, Vyacheslav Dubeyko wrote:
> > First of all, I need some details about your NILFS2 partition for issue analysis.
> > 
> > I need in:
> > 1. Full output of "lscp -a".
> > 2. Full output of "lssu -a".
> > 3. Output of dumpseg for segment #0.
> > 
> > Could you share these outputs?
> 
> Sure!
> maszyn ~ # lscp -a /dev/sdf3
> lscp: /dev/sdf3: cannot open NILFS
> maszyn ~ # lssu -a /dev/sdf3
> lssu: /dev/sdf3: cannot open NILFS

lscp and lssu don't work if the target partition is not mounted, so
these seem to be its direct result.

> (the card is in a card reader)
> 
> > Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.
> 
> maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out
> 
> Attached.

The segment zero may not include any useful information.
Please try nilfs-tune command to know which segment should be investigated.

# nilfs-tune -l /dev/sdf3
...
Last checkpoint #:	  160345
Last block address:	    131015
Last sequence #:	      7675
..

In this example, the active super block points to the segment #63:

  (value of the "Last block address" field) / 2048 = 131015 / 2048 = 63

Note that you can track the latest segment from the pointed segment.
"next segnum" field and "sequence number" field in the dumpseg outputs
tell you information about its successive segments.


By the way, Raspberry Pi Linux seems to be the kernel for an ARM-based
machine.  Is there possibility that this is a platform dependent
problem?


Regards,
Ryusuke Konishi


> Piotr Szymaniak.
> -- 
> Od  czasu  do  czasu  bij swoja zone,  jezeli ty nie wiesz za co ona na
> pewno bedzie wiedziec.
>   -- Przyslowie arabskie
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Oct 9, 2012, at 8:24 PM, Ryusuke Konishi wrote:

> Hi,
> On Tue, 9 Oct 2012 15:58:33 +0200, Piotr Szymaniak wrote:
>> On Tue, Oct 09, 2012 at 04:08:34PM +0400, Vyacheslav Dubeyko wrote:
>>> First of all, I need some details about your NILFS2 partition for issue analysis.
>>> 
>>> I need in:
>>> 1. Full output of "lscp -a".
>>> 2. Full output of "lssu -a".
>>> 3. Output of dumpseg for segment #0.
>>> 
>>> Could you share these outputs?
>> 
>> Sure!
>> maszyn ~ # lscp -a /dev/sdf3
>> lscp: /dev/sdf3: cannot open NILFS
>> maszyn ~ # lssu -a /dev/sdf3
>> lssu: /dev/sdf3: cannot open NILFS
> 
> lscp and lssu don't work if the target partition is not mounted, so
> these seem to be its direct result.
> 
>> (the card is in a card reader)
>> 
>>> Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.
>> 
>> maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out
>> 
>> Attached.
> 
> The segment zero may not include any useful information.
> Please try nilfs-tune command to know which segment should be investigated.
> 
> # nilfs-tune -l /dev/sdf3
> ...
> Last checkpoint #:	  160345
> Last block address:	    131015
> Last sequence #:	      7675
> ..
> 
> In this example, the active super block points to the segment #63:
> 
>  (value of the "Last block address" field) / 2048 = 131015 / 2048 = 63
> 
> Note that you can track the latest segment from the pointed segment.
> "next segnum" field and "sequence number" field in the dumpseg outputs
> tell you information about its successive segments.
> 
> 
> By the way, Raspberry Pi Linux seems to be the kernel for an ARM-based
> machine.  Is there possibility that this is a platform dependent
> problem?
> 

Not so long ago I received e-mail from guy that uses NILFS2 on Android smartphone (this is ARM-based platform, as I can understand). He is completely happy.

Anyway, currently, I suspect that over-clocking is a reason (maybe I am wrong).

By the way, it makes sense to try last version of fsck patch. Of course, it can check superblocks only but this fsck.nilfs2 test can be valuable anyway. Sometimes, fsck can be a valuable tool. :-) Unfortunately, it has very small checking possibility now.

With the best regards,
Vyacheslav Dubeyko.

> 
> Regards,
> Ryusuke Konishi
> 
> 
>> Piotr Szymaniak.
>> -- 
>> Od  czasu  do  czasu  bij swoja zone,  jezeli ty nie wiesz za co ona na
>> pewno bedzie wiedziec.
>>  -- Przyslowie arabskie
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 1051 bytes --]

On Wed, Oct 10, 2012 at 01:24:40AM +0900, Ryusuke Konishi wrote:
> > (the card is in a card reader)
> > 
> > > Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.
> > 
> > maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out
> > 
> > Attached.
> 
> The segment zero may not include any useful information.
> Please try nilfs-tune command to know which segment should be investigated.
> 
> # nilfs-tune -l /dev/sdf3
> ...
> Last checkpoint #:	  160345
> Last block address:	    131015
> Last sequence #:	      7675
> ..

Last checkpoint #:	  1873
Last block address:	  734128
Last sequence #:	  358

So it seems to be segment #358.

dump attached.


Piotr Szymaniak.
-- 
 Relastatyka  czasowa utrzymywała ją w kuli nicości,  której nie należy
mylić z próżnią.  Kula składała się z absolutnej nicości,  w jakiej nie
mogłaby zaistnieć próżnia.
  -- Douglas Adams, "Restaurant at The End of The Universe"

[-- Attachment #1.2: dumpseg-358.out.bz2 --]
[-- Type: application/x-bzip2, Size: 7152 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Wed, 2012-10-10 at 09:39 +0200, Piotr Szymaniak wrote:
> On Wed, Oct 10, 2012 at 01:24:40AM +0900, Ryusuke Konishi wrote:
> > > (the card is in a card reader)
> > > 
> > > > Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.
> > > 
> > > maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out
> > > 
> > > Attached.
> > 
> > The segment zero may not include any useful information.
> > Please try nilfs-tune command to know which segment should be investigated.
> > 
> > # nilfs-tune -l /dev/sdf3
> > ...
> > Last checkpoint #:	  160345
> > Last block address:	    131015
> > Last sequence #:	      7675
> > ..
> 

Could you share full output of "nilfs-tune -l"? I can't start analysis without superblock's content.

Thanks,
Vyacheslav Dubeyko.


> Last checkpoint #:	  1873
> Last block address:	  734128
> Last sequence #:	  358
> 
> So it seems to be segment #358.
> 
> dump attached.
> 
> 
> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Wed, 2012-10-10 at 09:39 +0200, Piotr Szymaniak wrote:
> On Wed, Oct 10, 2012 at 01:24:40AM +0900, Ryusuke Konishi wrote:
> > > (the card is in a card reader)
> > > 
> > > > Maybe, you will have some troubles with getting of outputs. So, I need in your segment #0 (first 8 MB) raw output for issue analysis beginning, anyway.
> > > 
> > > maszyn ~ # dumpseg /dev/sdf3 0 > /tmp/dumpseg-0.out
> > > 
> > > Attached.
> > 
> > The segment zero may not include any useful information.
> > Please try nilfs-tune command to know which segment should be investigated.
> > 
> > # nilfs-tune -l /dev/sdf3
> > ...
> > Last checkpoint #:	  160345
> > Last block address:	    131015
> > Last sequence #:	      7675
> > ..

> Last checkpoint #:	  1873
> Last block address:	  734128
> Last sequence #:	  358
> 
> So it seems to be segment #358.
> 
> dump attached.
> 

I need in superblock's content anyway.

Currently, I need in raw dumps from two blocks after dump preliminary analysis. Because you have message about root inode corruption then it needs to check the root inode raw representation in ifile (ino = 6). As I can see from your dump that the third block of ifile is located in 734205 block (blkoff = 2, blocknr = 734205). Also I can see that root inode content (ino = 2) is located in 734158 block ( blkoff = 0, blocknr = 734158).

Could you share these 2 blocks content?

Or you can check that these blocks contains expected metadata info. I expect that some of these blocks doesn't contains valid metadata info.

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Wed, Oct 10, 2012 at 02:43:54PM +0400, Vyacheslav Dubeyko wrote:
> Could you share full output of "nilfs-tune -l"? I can't start analysis without superblock's content.

maszyn ~ # nilfs-tune -l /dev/sdf3
nilfs-tune 2.1.4
Filesystem volume name:   (none)
Filesystem UUID:          53760664-f9ed-4c8d-af42-c6ee2f16d956
Filesystem magic number:  0x3434
Filesystem revision #:    2.0
Filesystem features:      (none)
Filesystem state:         invalid or mounted
Filesystem OS type:       Linux
Block size:               4096
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
Mount count:              56
Maximum mount count:      50
Reserve blocks uid:       0 (user root)
Reserve blocks gid:       0 (group root)
First inode:              11
Inode size:               128
DAT entry size:           32
Checkpoint size:          192
Segment usage size:       16
Number of segments:       922
Device size:              7741636608
First data block:         1
# of blocks per segment:  2048
Reserved segments %:      5
Last checkpoint #:        1873
Last block address:       734128
Last sequence #:          358
Free blocks count:        1150976
Commit interval:          300
# of blks to create seg:  0
CRC seed:                 0x3e0bea06
CRC check sum:            0x2643ad60
CRC check data size:      0x00000118


Piotr Szymaniak.
-- 
 Jedna z głów  Zaphoda spojrzała w bok.  Druga  zrobiła  zaraz to samo,
gdyż  chciała zobaczyć,  na co patrzy pierwsza,  nie było to jednak nic
konkretnego.
  -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Wed, Oct 10, 2012 at 04:03:13PM +0400, Vyacheslav Dubeyko wrote:
> I need in superblock's content anyway.
> 
> Currently, I need in raw dumps from two blocks after dump preliminary analysis. Because you have message about root inode corruption then it needs to check the root inode raw representation in ifile (ino = 6). As I can see from your dump that the third block of ifile is located in 734205 block (blkoff = 2, blocknr = 734205). Also I can see that root inode content (ino = 2) is located in 734158 block ( blkoff = 0, blocknr = 734158).
> 
> Could you share these 2 blocks content?
> 
> Or you can check that these blocks contains expected metadata info. I expect that some of these blocks doesn't contains valid metadata info.

How should i make the dump?


Piotr Szymaniak.
-- 
Jesli  jego  talent byl darem bozym, to Bog jest niebezpiecznym szalen-
cem, ktorego nalezy natychmiast powstrzymac. Jesli Bog chcial usmiercic
Grega  Stillsona,  to czemu nie sprawil,  zeby pojawil sie na swiecie z
pepowina  owinieta wokol szyi?  Dlaczego nie udusil go kawalkiem miesa?
(...) Johnny  zdecydowal  nagle,  ze  pozwoli  Stillsonowi  zyc i w ten
sposob napluje Bogu w oczy.
  -- Stephen King, "The Dead Zone"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Thu, 2012-10-11 at 00:03 +0200, Piotr Szymaniak wrote:
> On Wed, Oct 10, 2012 at 04:03:13PM +0400, Vyacheslav Dubeyko wrote:
> > I need in superblock's content anyway.
> > 
> > Currently, I need in raw dumps from two blocks after dump preliminary analysis. Because you have message about root inode corruption then it needs to check the root inode raw representation in ifile (ino = 6). As I can see from your dump that the third block of ifile is located in 734205 block (blkoff = 2, blocknr = 734205). Also I can see that root inode content (ino = 2) is located in 734158 block ( blkoff = 0, blocknr = 734158).
> > 
> > Could you share these 2 blocks content?
> > 
> > Or you can check that these blocks contains expected metadata info. I expect that some of these blocks doesn't contains valid metadata info.
> 
> How should i make the dump?
> 

You can use dd for dumping (dd if=/dev/<device> of=<file> bs=<block size> skip=<offset to the block> count=<blocks count>).

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Thu, Oct 11, 2012 at 10:50:58AM +0400, Vyacheslav Dubeyko wrote:
> On Thu, 2012-10-11 at 00:03 +0200, Piotr Szymaniak wrote:
> > On Wed, Oct 10, 2012 at 04:03:13PM +0400, Vyacheslav Dubeyko wrote:
> > > I need in superblock's content anyway.
> > > 
> > > Currently, I need in raw dumps from two blocks after dump preliminary analysis. Because you have message about root inode corruption then it needs to check the root inode raw representation in ifile (ino = 6). As I can see from your dump that the third block of ifile is located in 734205 block (blkoff = 2, blocknr = 734205). Also I can see that root inode content (ino = 2) is located in 734158 block ( blkoff = 0, blocknr = 734158).
> > > 
> > > Could you share these 2 blocks content?
> > > 
> > > Or you can check that these blocks contains expected metadata info. I expect that some of these blocks doesn't contains valid metadata info.
> > 
> > How should i make the dump?
> > 
> 
> You can use dd for dumping (dd if=/dev/<device> of=<file> bs=<block size> skip=<offset to the block> count=<blocks count>).

So I should dump block 743205 and 734158? Ok, but I'm not familiar with
blkoff.

ie. blkoff = 2, blocknr = 734205 it means the dump should be block
734205 and (blkoff = 2) next two blocks? If this is correct then this
should work, right?
dd if=/dev/<device> of=<dump> bs=2048 skip=734205 count=3 (not sure if
dd counts skip= and count= from 0 or 1)
And similar with block 734158 but only one block (blkoff = 0)?


Piotr Szymaniak.
-- 
Oczywiscie wiedzial,  ze byla wojna - nie ta obecna,  glupia,  w ktorej
Amerykanie  dostawali  lomot od bandy zoltkow w czarnych pizamach - ale
druga wojna swiatowa.
  -- Stephen King, "Apt Pupil"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Thu, 2012-10-11 at 11:23 +0200, Piotr Szymaniak wrote:
> On Thu, Oct 11, 2012 at 10:50:58AM +0400, Vyacheslav Dubeyko wrote:
> > On Thu, 2012-10-11 at 00:03 +0200, Piotr Szymaniak wrote:
> > > On Wed, Oct 10, 2012 at 04:03:13PM +0400, Vyacheslav Dubeyko wrote:
> > > > I need in superblock's content anyway.
> > > > 
> > > > Currently, I need in raw dumps from two blocks after dump preliminary analysis. Because you have message about root inode corruption then it needs to check the root inode raw representation in ifile (ino = 6). As I can see from your dump that the third block of ifile is located in 734205 block (blkoff = 2, blocknr = 734205). Also I can see that root inode content (ino = 2) is located in 734158 block ( blkoff = 0, blocknr = 734158).
> > > > 
> > > > Could you share these 2 blocks content?
> > > > 
> > > > Or you can check that these blocks contains expected metadata info. I expect that some of these blocks doesn't contains valid metadata info.
> > > 
> > > How should i make the dump?
> > > 
> > 
> > You can use dd for dumping (dd if=/dev/<device> of=<file> bs=<block size> skip=<offset to the block> count=<blocks count>).
> 
> So I should dump block 743205 and 734158? Ok, but I'm not familiar with
> blkoff.
> 
> ie. blkoff = 2, blocknr = 734205 it means the dump should be block
> 734205 and (blkoff = 2) next two blocks? If this is correct then this
> should work, right?
> dd if=/dev/<device> of=<dump> bs=2048 skip=734205 count=3 (not sure if
> dd counts skip= and count= from 0 or 1)
> And similar with block 734158 but only one block (blkoff = 0)?
> 

Sorry, I confuse you by blkoff mentioning. The blkoff is logical offset from file begin (for example, from ifile begin). You need to take into account only blocknr.

It needs to dump block 743205 and 734158. Your superblock's content informs that block size is 4096 bytes.

For example, dd if=/dev/<device> of=<dump> bs=4096 skip=734205 count=1

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]

On Thu, Oct 11, 2012 at 02:12:00PM +0400, Vyacheslav Dubeyko wrote:
> On Thu, 2012-10-11 at 11:23 +0200, Piotr Szymaniak wrote:
> > So I should dump block 743205 and 734158? Ok, but I'm not familiar with
> > blkoff.
> > 
> > ie. blkoff = 2, blocknr = 734205 it means the dump should be block
> > 734205 and (blkoff = 2) next two blocks? If this is correct then this
> > should work, right?
> > dd if=/dev/<device> of=<dump> bs=2048 skip=734205 count=3 (not sure if
> > dd counts skip= and count= from 0 or 1)
> > And similar with block 734158 but only one block (blkoff = 0)?
> > 
> 
> Sorry, I confuse you by blkoff mentioning. The blkoff is logical offset from file begin (for example, from ifile begin). You need to take into account only blocknr.
> 
> It needs to dump block 743205 and 734158. Your superblock's content informs that block size is 4096 bytes.
> 
> For example, dd if=/dev/<device> of=<dump> bs=4096 skip=734205 count=1

Block 743205 is empty:
maszyn tmp (: cat dump.743205
maszyn tmp (: hexdump dump.743205
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000

Block 734158 attached.

Piotr Szymaniak.
-- 
W   tamtych   latach   wiejskie   rodziny   chodziły  do  lóżka  bardzo
wcześnie - "kiedy  robiło  się  ciemno  pod  stołem",  jak mawiała moja
własna matka - i spały kamiennym snem.
  -- Stephen King, "The Green Mile"

[-- Attachment #1.2: dump.734158.bz2 --]
[-- Type: application/x-bzip2, Size: 238 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Wed, 2012-10-10 at 22:39 +0200, Piotr Szymaniak wrote:
> maszyn ~ # nilfs-tune -l /dev/sdf3
...
> Filesystem state:         invalid or mounted
...
> 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
> Mount count:              56
> Maximum mount count:      50
...
> Number of segments:       922
> Device size:              7741636608
> First data block:         1
> # of blocks per segment:  2048
> Reserved segments %:      5
> Last checkpoint #:        1873
> Last block address:       734128
> Last sequence #:          358
> Free blocks count:        1150976
...

First of all, it is possible to see that file system was not unmounted. It was 56 mounts but during last mount superblock was not updated properly. It means that it was sudden power-off, kernel crush or superblock wasn't flushed because some reason.

Moreover, last mount time and last write time are strange. Usually, these fields have real time of last modifications but you haven't so. File system creation time is defined by means of mkfs utility but last mount time and write time are defined by driver. So, maybe it is a slight superblock corruption.

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)?

On Thu, 2012-10-11 at 20:03 +0200, Piotr Szymaniak wrote:
> On Thu, Oct 11, 2012 at 02:12:00PM +0400, Vyacheslav Dubeyko wrote:
> > On Thu, 2012-10-11 at 11:23 +0200, Piotr Szymaniak wrote:
> > > So I should dump block 743205 and 734158? Ok, but I'm not familiar with
> > > blkoff.
> > > 
> > > ie. blkoff = 2, blocknr = 734205 it means the dump should be block
> > > 734205 and (blkoff = 2) next two blocks? If this is correct then this
> > > should work, right?
> > > dd if=/dev/<device> of=<dump> bs=2048 skip=734205 count=3 (not sure if
> > > dd counts skip= and count= from 0 or 1)
> > > And similar with block 734158 but only one block (blkoff = 0)?
> > > 
> > 
> > Sorry, I confuse you by blkoff mentioning. The blkoff is logical offset from file begin (for example, from ifile begin). You need to take into account only blocknr.
> > 
> > It needs to dump block 743205 and 734158. Your superblock's content informs that block size is 4096 bytes.
> > 
> > For example, dd if=/dev/<device> of=<dump> bs=4096 skip=734205 count=1
> 
> Block 743205 is empty:
> maszyn tmp (: cat dump.743205
> maszyn tmp (: hexdump dump.743205
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001000
> 

It is bad. This block should contain root inode description. So, it is clear why you have such error message during mount trying.

I think that it needs to understand how deeply destroyed metadata files in last checkpoints. In dumpseg of #358 segment you have description of all blocks for ifile (ino = 6). Could you check what blocks are empty and what are not? Could you share results of checking ifile (ino = 6) blocks for all checkpoints that are described in dumpseg of #358 segment?

It needs to find in previous checkpoints valid ifile block (not empty) with blkoff = 2. Could you try to find? It needs to make dumpseg of previous segments and search not empty block of ifile (ino = 6) with blkoff = 2.

> Block 734158 attached.
> 

Block 734158 contains root folder (ino = 2) directory entries (bin, boott, dev, etc, home5, lib, media, mnt, opt, proc, root, run, sbin, sys, tmp, usr, var, test.318) as I can see.

Thereby, I can distinguish two problem: (1) file system recovering and (2) issue investigation.

Could you save raw dump of corrupted file system in untouched state for further investigations?

I think that the reason of such situation is absence or not proper flushing of dirty blocks. The question is what the reason of it. I can see several possible reasons: (1) hardware issue, (2) kernel crush, (3) file system issue. Anyway, it needs to describe the issue reproduction path for understanding the reason. Could you achieve reproduction of the issue and describe reproduction path?

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 1745 bytes --]

On Fri, Oct 12, 2012 at 11:10:32AM +0400, Vyacheslav Dubeyko wrote:
> > 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
> 
> First of all, it is possible to see that file system was not unmounted. It was 56 mounts but during last mount superblock was not updated properly. It means that it was sudden power-off, kernel crush or superblock wasn't flushed because some reason.
> 
> Moreover, last mount time and last write time are strange. Usually, these fields have real time of last modifications but you haven't so. File system creation time is defined by means of mkfs utility but last mount time and write time are defined by driver. So, maybe it is a slight superblock corruption.

Raspberry Pi doesn't have RTC, so it's always 1 Jan 1970 on boot and
then the date is set. That should at least explain the weird date of
last mount/write time.


> 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.

How to dump second superblock?
Number of segments:	  922
Device size:		  7741636608

Should I dump last 4096 bytes of device size?


Piotr Szymaniak.
-- 
 - Jezu Chryste, dostal ataku - szepnal Percy.
 - Jasne,  a moja  siostra  jest  babilonska  ladacznica - zasmial  sie
Brutal.  - W kazda sobotnia noc tanczy przed Mojzeszem taniec brzucha w
dlugim bialym welonie.
  -- Stephen King, "The Green Mile"

[-- Attachment #1.2: dumpseg.357.out.bz2 --]
[-- Type: application/x-bzip2, Size: 8701 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

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.

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 741 bytes --]

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”

[-- Attachment #1.2: secondary-sb.out.bz2 --]
[-- Type: application/x-bzip2, Size: 182 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Christian Smith]

On Tue, Oct 09, 2012 at 12:52:39PM +0200, Piotr Szymaniak wrote:
> On Tue, Oct 09, 2012 at 11:29:53AM +0400, Vyacheslav Dubeyko wrote:
> > Hi,
> > 
> > On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> > > Hi list.
> > > 
> > > I'm using nilfs2 on my Raspberry Pi rootfs. I've played around with
> > > Raspberry Pi Turbo Mode and today it refused to boot. It's a headless
> > > setup so I moved the SD Card to my other machine and tried to mount
> > > rootfs partition:
> > > 
> > 
> > As I can understand Raspberry Pi Turbo Mode is a hardware overclocking.
> > So, I worry about proper working of SD-card controller. It is possible
> > that the reason of the issue can be not proper controller functioning or
> > concrete SD-card issue.
> 
> It's an ???allowed??? overcloking. I have another SD Card with Raspbian (and
> without nilfs2) that works fine with Turbo Mode. At least it seems to
> work fine. The second card was in Turbo Mode (@900MHz) for a few days
> and was working. Yesterday i made it @1000MHz and it didn't boot.


It's allowed in that it no longer invalidates your warranty, but I don't think
there is any guarantee it will work.

Overclocking also puts more load on the PSU, so there is potentially less
power available for the SD Card to work with. Perhaps a write failed due
to power issues in Turbo mode? What is your PSU rating? 0.7A is the
recommended amount the PSU should be able to supply.


As an aside, I have also been thinking of using NILFS root, but struggled to
get the default kernel up and running with an initrd (to load the nilfs2
module). Did you use a built in nilfs2 driver?

A raspbian image with NILFS root would be awesome, given the performance
benefits of NILFS on lowe end FLASH media.

Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Fri, Oct 12, 2012 at 12:49:15PM +0100, Christian Smith wrote:
> On Tue, Oct 09, 2012 at 12:52:39PM +0200, Piotr Szymaniak wrote:
> > It's an ???allowed??? overcloking. I have another SD Card with Raspbian (and
> > without nilfs2) that works fine with Turbo Mode. At least it seems to
> > work fine. The second card was in Turbo Mode (@900MHz) for a few days
> > and was working. Yesterday i made it @1000MHz and it didn't boot.
> 
> It's allowed in that it no longer invalidates your warranty, but I don't think
> there is any guarantee it will work.
> 
> Overclocking also puts more load on the PSU, so there is potentially less
> power available for the SD Card to work with. Perhaps a write failed due
> to power issues in Turbo mode? What is your PSU rating? 0.7A is the
> recommended amount the PSU should be able to supply.

It seems to work fine with Raspbian, so I dubt it's an PSU issue (I've
tested Raspbian @1000MHz in the first place). Afair the PSU is 1 or 1,1A,
so that should not be a problem.


> As an aside, I have also been thinking of using NILFS root, but struggled to
> get the default kernel up and running with an initrd (to load the nilfs2
> module). Did you use a built in nilfs2 driver?

Yes, I'm using custom build kernel with build in nilfs2 support (and a
lot of stuff cut down since I won't use it (and even if, I can compile
them back, right?)).


Piotr Szymaniak.
-- 
Nie mam problemu z piciem.  Bez  problemu  pije,  upijam sie i walam po
podlodze.
  -- R. Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

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)
# -- 

Don't know if that is usefull. ;)

Piotr Szymaniak.
-- 
Zaphod nie miał ochoty zaczynać z nimi bójki, a ponieważ uważał, że jak
w odwadze  najlepsza jest ostrożność,  tak w ostrożności - tchórzostwo,
schował się odważnie do szafy.
  -- Douglas Adams, "Life, The Universe and Everything"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

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)?

I suppose that the dump was to big for the list, but I hope you guys got
it.

Piotr Szymaniak.
-- 
Gdybym  opowiadal  bajke,  powiedzialbym,  ze Andy walczyl zaciekle, az
zostawiono  go  w  spokoju.  Chcialbym  to  powiedziec,  ale  nie moge.
Wiezienie nie ma nic wspolnego z bajka, jest az nazbyt realne.
  -- Stephen King, "Rita Hayworth and Shawshank Redemption"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Sun, 2012-10-14 at 22:47 +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)?
> 
> I suppose that the dump was to big for the list, but I hope you guys got
> it.
> 

Please, send the dump only on my personal e-mail. I need in it for analysis.

Thanks,
Vyacheslav Dubeyko. 

> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

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).

Thanks,
Vyacheslav Dubeyko. 


> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

Today I tried to reproduce the issue on the basis of my current
understanding of issue's environment. In other words, I simply tried to
simulate situation that we can see on corrupted NILFS2 volume.

As I can understand, at the end of issue we have corrupted NILFS2 volume
that contains empty block (blkoff = 2) of ifile (ino = 6) in last
checkpoint. This block should contain description of critical inodes (as
minimum, special and root inodes). Let's imagine that we have correct
(not empty) block with blkoff = 2 of ifile in previous checkpoints.

I tried to reproduce the issue on the system:
Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

So, I made NILFS2 volume and then to create several files in root
folder. As a result, I had the NILFS2 volume with several checkpoints:

                 CNO        DATE     TIME  MODE  FLG     NBLKINC       ICNT
                   1  2012-10-10 14:38:35   cp    -           11          2
                   2  2012-10-10 14:49:59   cp    -          274          3
                   3  2012-10-10 14:50:05   cp    -          274          4
                   4  2012-10-10 14:50:12   cp    -          274          5
                   5  2012-10-10 14:50:47   cp    -         4879          5
                   6  2012-10-10 14:50:48   cp    -          630          5
                   7  2012-10-10 14:50:54   cp    -         2200          5
                   8  2012-10-18 10:54:19   cp    i            8          5

I can see from dumpseg output that I have block with blkoff = 2 of ifile
in several checkpoints:

finfo
      ino = 6, cno = 1, nblocks = 3, ndatblk = 3
        vblocknr = 4, blkoff = 2, blocknr = 5

finfo
      ino = 6, cno = 2, nblocks = 3, ndatblk = 3
        vblocknr = 10, blkoff = 2, blocknr = 275

finfo
      ino = 6, cno = 3, nblocks = 3, ndatblk = 3
         vblocknr = 16, blkoff = 2, blocknr = 549

finfo
      ino = 6, cno = 4, nblocks = 3, ndatblk = 3
        vblocknr = 22, blkoff = 2, blocknr = 823

finfo
      ino = 6, cno = 5, nblocks = 1, ndatblk = 1
        vblocknr = 29, blkoff = 2, blocknr = 13233

finfo
      ino = 6, cno = 6, nblocks = 1, ndatblk = 1
        vblocknr = 33, blkoff = 2, blocknr = 16975

finfo
      ino = 6, cno = 7, nblocks = 1, ndatblk = 1
        vblocknr = 39, blkoff = 2, blocknr = 26812

Firstly, I tried to reproduce situation without presence of any
snapshots in filesystem. I simply made such sequence of actions:
1. Check that volume is mounted successfully before any manipulation and unmount it (result was OK).
2. Fill the block #26812 by zeros:

sudo dd if=/dev/zero of=/dev/loop0 bs=4096 seek=26812 count=1

3. Try to mount the corrupted volume again (operation was failed with
errors):

[ 3294.873113] NILFS warning: Checksum error in segment payload
[ 3294.873122] NILFS: try rollback from an earlier position
[ 3294.877949] NILFS warning: Checksum error in segment payload
[ 3294.877954] NILFS: error searching super root.

4. Copy block #16975 (previous checkpoint #6) into block #26812 (next
checkpoint #7) and try to mount again (the mount operation was
successful).

Secondly, I tried to reproduce situation with presence of one snapshot
(cno = 5) on the volume:

                 CNO        DATE     TIME  MODE  FLG     NBLKINC       ICNT
                   1  2012-10-10 14:38:35   cp    -           11          2
                   2  2012-10-10 14:49:59   cp    -          274          3
                   3  2012-10-10 14:50:05   cp    -          274          4
                   4  2012-10-10 14:50:12   cp    -          274          5
                   5  2012-10-10 14:50:47   ss    -         4879          5
                   6  2012-10-10 14:50:48   cp    -          630          5
                   7  2012-10-10 14:50:54   cp    -         2200          5
                   8  2012-10-18 10:54:19   cp    i            8          5

I repeated the same sequence of actions:
1. Check operation mount firstly in RW mode and in RO mode for snapshot
case (result was OK).
2. Fill the block #26812 by zeros.
3. Try to mount the corrupted volume again (operation was failed with errors):

[ 5572.280128] NILFS: get root inode failed

4. Try to mount snapshot in RO mode (sudo mount -o ro,cp=5 /dev/loop0 /mnt/nilfs2). The operation was failed with error:

mount.nilfs2: Error while mounting /dev/loop0 on /mnt/nilfs2: Invalid argument

[22911.845694] NILFS: get root inode failed

5. Copy block #16975 (previous checkpoint #6) into block #26812 (next
checkpoint #7) and try to mount again (the mount operation was
successful).

[TO SUMMARIZE]
1. I hope that Piotr can restore your NILFS2 volume manually by copying
block of ifile (ino = 6) with blkoff = 2 from previous checkpoint.
2. There are different behavior in the case of presence of snapshots and
not. As I can understand, in the case of snapshot's absence the recovery
code try to work but with no success.
3. In this simulation of the issue it exists some difference in error
messages in comparison with Piotr's report. But, as I can understand,
the place in code of error messages generation is the same.
4. I think that it is very unexpected from the user point of view that
the operation of snapshot mount fails in the presence of it.
5. Moreover, from my point of view, the impossibility to get list of
checkpoints (lscp) or segment usage information (lssu) in the case of
unmountable file system state is inconvenient.

So, I hope that this simulation reproduces the reported issue. Anyway, I
am going to investigate the issue more deeply in the environment of
described simulation, check correctness of such simulation from file
system point of view and fix the issue.

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 1062 bytes --]

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.

Piotr Szymaniak.
-- 
Smiejmy sie! Kto wie czy swiat potrwa jeszcze trzy tygodnie?
  -- Beaumarchais Pierre Augustin

[-- Attachment #1.2: dump.698817.bz2 --]
[-- Type: application/x-bzip2, Size: 795 bytes --]

[-- Attachment #1.3: dump.719300.bz2 --]
[-- Type: application/x-bzip2, Size: 797 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 1853 bytes --]

On Fri, Oct 19, 2012 at 10:43:11AM +0400, Vyacheslav Dubeyko wrote:
> 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.

It looks more like my misspelling when I asked about how should I make
raw dump and after that it already was 743* instead of 734*. So my fault
here.

The dump looks like non-empty (attached), so I skipped this experiment
below.


> 
> 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.

-- 
 Piosenki  mają  dość  proste i skonstruowane według znanego  schematu:
istota-chłopiec spotyka w świetle srebrnego księżyca istotę-dziewczynę,
księżyc z bliżej nie wyjaśnionych przyczyn wybucha.
  -- Douglas Adams, "Restaurant at The End of The Universe"

[-- Attachment #1.2: dump.734205.bz2 --]
[-- Type: application/x-bzip2, Size: 801 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

Hi,

On Fri, 2012-10-19 at 12:14 +0200, Piotr Szymaniak wrote:
> On Fri, Oct 19, 2012 at 10:43:11AM +0400, Vyacheslav Dubeyko wrote:
> > 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.
> 
> It looks more like my misspelling when I asked about how should I make
> raw dump and after that it already was 743* instead of 734*. So my fault
> here.
> 
> The dump looks like non-empty (attached), so I skipped this experiment
> below.
> 

Sorry, for delay with answer. I was slightly busy.

So, currently, I have such picture. Your initial report was:

On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> dmesg shows:
> (...)
> [43893.754525] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> [43893.760245] NILFS: corrupt root inode.

This error message generates only in one place by
nilfs_get_root_dentry() method in super.c
(http://lxr.free-electrons.com/source/fs/nilfs2/super.c#L903):

903         if (!S_ISDIR(inode->i_mode) || !inode->i_blocks || !inode->i_size) {
904                 iput(inode);
905                 printk(KERN_ERR "NILFS: corrupt root inode.\n");
906                 ret = -EINVAL;
907                 goto out;
908         }

So, only corruption of any of three fields of inode can be a reason for
such error message, from my understanding. But from the dump of #734205
block I can see such content of root inode (ino = 2):

00000100  01 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000110  08 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00  |................|
00000120  03 5a 62 02 03 5a 62 02  00 00 00 00 00 00 00 00  |.Zb..Zb.........|
00000130  ed 41 13 00 00 00 00 00  00 00 00 00 00 00 00 00  |.A..............|
00000140  8f aa 0a 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[00000100] i_blocks = 0x1
[00000108] i_size = 0x1000
[00000130] i_mode = 0x41ed (040755)

It means that inode's content is placed in one block and this inode
describes folder. So, the on-disk inode is correct and should be read
correctly during mounting. I have compared vanilla kernel code with
https://github.com/raspberrypi/linux and can't see any significant
difference. Currently, I think that unstable functioning of SD-card
controller in the Turbo mode can be the reason of this error message but
maybe I haven't the clear picture.

Did you try to mount this NILFS2 volume on host machine in normal mode?
Do you have such error message with this NILFS2 volume in another
technical environment?

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

On Tue, Oct 23, 2012 at 10:31:53AM +0400, Vyacheslav Dubeyko wrote:
> Sorry, for delay with answer. I was slightly busy.

Hi,

Not a problem. Thanks for help. (:


> So, currently, I have such picture. Your initial report was:
> 
> On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> > dmesg shows:
> > (...)
> > [43893.754525] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> > [43893.760245] NILFS: corrupt root inode.
> 
> This error message generates only in one place by
> nilfs_get_root_dentry() method in super.c
> (http://lxr.free-electrons.com/source/fs/nilfs2/super.c#L903):
> 
> 903         if (!S_ISDIR(inode->i_mode) || !inode->i_blocks || !inode->i_size) {
> 904                 iput(inode);
> 905                 printk(KERN_ERR "NILFS: corrupt root inode.\n");
> 906                 ret = -EINVAL;
> 907                 goto out;
> 908         }
> 
> So, only corruption of any of three fields of inode can be a reason for
> such error message, from my understanding. But from the dump of #734205
> block I can see such content of root inode (ino = 2):
> 
> 00000100  01 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
> 00000110  08 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00  |................|
> 00000120  03 5a 62 02 03 5a 62 02  00 00 00 00 00 00 00 00  |.Zb..Zb.........|
> 00000130  ed 41 13 00 00 00 00 00  00 00 00 00 00 00 00 00  |.A..............|
> 00000140  8f aa 0a 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 
> [00000100] i_blocks = 0x1
> [00000108] i_size = 0x1000
> [00000130] i_mode = 0x41ed (040755)
> 
> It means that inode's content is placed in one block and this inode
> describes folder. So, the on-disk inode is correct and should be read
> correctly during mounting. I have compared vanilla kernel code with
> https://github.com/raspberrypi/linux and can't see any significant
> difference. Currently, I think that unstable functioning of SD-card
> controller in the Turbo mode can be the reason of this error message but
> maybe I haven't the clear picture.
> 
> Did you try to mount this NILFS2 volume on host machine in normal mode?
> Do you have such error message with this NILFS2 volume in another
> technical environment?

Yes, I tried to run it in normal mode (/boot is on small fat partition,
so I can tweak Turbo one way on another without touching rootfs). Also
all of the dumps are made on another machine (Gentoo x86 with kernel 3.6.2)
and it refuses to mount with above message.


Piotr Szymaniak.
-- 
 - Bufory.  Oto, dlaczego ja poslubilem.  I bylem glupcem, wstydzac sie
przed  soba  do  tego  przyznac.  Zupelnie  jak  faceci,  ktorzy kupuja
Playboya,  wmawiajac  sobie,  ze  to  tylko dla artykulow. - Otarl usta
wierzchem  dloni. - Zgoda, to infantylne, ale to mi sie wlasnie podoba.
Bufory.
  -- Graham Masterton, "Mirror"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Tue, 2012-10-23 at 10:41 +0200, Piotr Szymaniak wrote:
> On Tue, Oct 23, 2012 at 10:31:53AM +0400, Vyacheslav Dubeyko wrote:
> > Sorry, for delay with answer. I was slightly busy.
> 
> Hi,
> 
> Not a problem. Thanks for help. (:
> 
> 
> > So, currently, I have such picture. Your initial report was:
> > 
> > On Tue, 2012-10-09 at 00:25 +0200, Piotr Szymaniak wrote:
> > > dmesg shows:
> > > (...)
> > > [43893.754525] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> > > [43893.760245] NILFS: corrupt root inode.
> > 
> > This error message generates only in one place by
> > nilfs_get_root_dentry() method in super.c
> > (http://lxr.free-electrons.com/source/fs/nilfs2/super.c#L903):
> > 
> > 903         if (!S_ISDIR(inode->i_mode) || !inode->i_blocks || !inode->i_size) {
> > 904                 iput(inode);
> > 905                 printk(KERN_ERR "NILFS: corrupt root inode.\n");
> > 906                 ret = -EINVAL;
> > 907                 goto out;
> > 908         }
> > 
> > So, only corruption of any of three fields of inode can be a reason for
> > such error message, from my understanding. But from the dump of #734205
> > block I can see such content of root inode (ino = 2):
> > 
> > 00000100  01 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
> > 00000110  08 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00  |................|
> > 00000120  03 5a 62 02 03 5a 62 02  00 00 00 00 00 00 00 00  |.Zb..Zb.........|
> > 00000130  ed 41 13 00 00 00 00 00  00 00 00 00 00 00 00 00  |.A..............|
> > 00000140  8f aa 0a 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 
> > [00000100] i_blocks = 0x1
> > [00000108] i_size = 0x1000
> > [00000130] i_mode = 0x41ed (040755)
> > 
> > It means that inode's content is placed in one block and this inode
> > describes folder. So, the on-disk inode is correct and should be read
> > correctly during mounting. I have compared vanilla kernel code with
> > https://github.com/raspberrypi/linux and can't see any significant
> > difference. Currently, I think that unstable functioning of SD-card
> > controller in the Turbo mode can be the reason of this error message but
> > maybe I haven't the clear picture.
> > 
> > Did you try to mount this NILFS2 volume on host machine in normal mode?
> > Do you have such error message with this NILFS2 volume in another
> > technical environment?
> 
> Yes, I tried to run it in normal mode (/boot is on small fat partition,
> so I can tweak Turbo one way on another without touching rootfs). Also
> all of the dumps are made on another machine (Gentoo x86 with kernel 3.6.2)
> and it refuses to mount with above message.
> 

It is strange. Did you try to mount NILFS2 volume that is placed on
SD-card for the case of on another machine (Gentoo x86 with kernel
3.6.2)?

Could you try to mount volume's dump as loop device on machine (Gentoo
x86 with kernel 3.6.2)?

Could you share strace output (strace mount <device> <mount-point>) for
the case of mount trying?

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Tue, Oct 23, 2012 at 01:26:35PM +0400, Vyacheslav Dubeyko wrote:
> It is strange. Did you try to mount NILFS2 volume that is placed on
> SD-card for the case of on another machine (Gentoo x86 with kernel
> 3.6.2)?

Yes, all those messages are from this machine (it could be kernel 3.4.10
or 3.6 or 3.6.1 at the beginning of this thread).


> Could you try to mount volume's dump as loop device on machine (Gentoo
> x86 with kernel 3.6.2)?

Now this is weird. I have a complete image of the SD-card but never
tried to mount it. Now I did with:
mount -t nilfs2 -o loop,offset=[offset to nilfs2] raspi.img /mount/point
and it works.

I tried to mount this SD-card on the same machine (using card reader) and
had the mentioned error.

Now I'm a bit confused. Made SD-card image without issues, SD-card
refuses to mount, but the image works?

I will try to make another image and double check it.

What should I do if this works? mount the image, umount the image (that
should fix it?) and copy image back to SD-card?


> Could you share strace output (strace mount <device> <mount-point>) for
> the case of mount trying?

I will share the SD-card strace output later (if it still won't work,
see above).


Piotr Szymaniak.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Tue, 2012-10-23 at 13:54 +0200, Piotr Szymaniak wrote:
> On Tue, Oct 23, 2012 at 01:26:35PM +0400, Vyacheslav Dubeyko wrote:
> > It is strange. Did you try to mount NILFS2 volume that is placed on
> > SD-card for the case of on another machine (Gentoo x86 with kernel
> > 3.6.2)?
> 
> Yes, all those messages are from this machine (it could be kernel 3.4.10
> or 3.6 or 3.6.1 at the beginning of this thread).
> 
> 
> > Could you try to mount volume's dump as loop device on machine (Gentoo
> > x86 with kernel 3.6.2)?
> 
> Now this is weird. I have a complete image of the SD-card but never
> tried to mount it. Now I did with:
> mount -t nilfs2 -o loop,offset=[offset to nilfs2] raspi.img /mount/point
> and it works.
> 
> I tried to mount this SD-card on the same machine (using card reader) and
> had the mentioned error.
> 
> Now I'm a bit confused. Made SD-card image without issues, SD-card
> refuses to mount, but the image works?
> 
> I will try to make another image and double check it.
> 
> What should I do if this works? mount the image, umount the image (that
> should fix it?) and copy image back to SD-card?
> 

I think that the issue is the concrete SD-card's issue. So, if you
simply dump out the image on another SD-card then, I hope, all will work
fine.

With the best regards,
Vyacheslav Dubeyko.

> 
> > Could you share strace output (strace mount <device> <mount-point>) for
> > the case of mount trying?
> 
> I will share the SD-card strace output later (if it still won't work,
> see above).
> 
> 
> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NILFS: corrupt root inode after Turbo Mode?

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Tue, Oct 23, 2012 at 05:35:30PM +0400, Vyacheslav Dubeyko wrote:
> I think that the issue is the concrete SD-card's issue. So, if you
> simply dump out the image on another SD-card then, I hope, all will work
> fine.

But what could be the issue with SD-card?

Anyway, I did a second image, mounted it as before and it works. dmesg
shows:
[ 2740.544690] NILFS warning: broken superblock. using spare superblock (blocksize = 1024).
[ 2740.544754] NILFS warning: broken superblock. using spare superblock (blocksize = 4096).
[ 2740.544760] NILFS warning: mounting unchecked fs
[ 2740.861477] NILFS: recovery complete.
[ 2740.911019] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds

I will try to put the image after mount/umount back to the SD-card and
check if it works on Raspberry Pi.


Piotr Szymaniak.
-- 
 - (...) Nie wyobrazam sobie, co ta gora miesa moglaby ci dac, czego ja
nie   moglbym   ofiarowac.  Oczywiscie  poza  piecdziesiecioma  funtami
rozrosnietych miesni.
 - Moze mnie wlasnie pociagaja rozrosniete miesnie. (...) W koncu wielu
mezczyzn pociaga rozrosnieta tkanka tluszczowa piersi.
  -- Graham Masterton, "The Wells of Hell"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: NILFS: corrupt root inode after Turbo Mode?

[Vyacheslav Dubeyko]

On Wed, 2012-10-24 at 09:36 +0200, Piotr Szymaniak wrote:
> On Tue, Oct 23, 2012 at 05:35:30PM +0400, Vyacheslav Dubeyko wrote:
> > I think that the issue is the concrete SD-card's issue. So, if you
> > simply dump out the image on another SD-card then, I hope, all will work
> > fine.
> 
> But what could be the issue with SD-card?
> 

There are several possible reasons of the issue:
1. Volume corruption.
2. File system driver issue.
3. Hardware issue.

The volume corruption is steady reproducible in the case of file system
driver issue on any computer system with achieving necessary
environment. The reported issue is not so because you can't mount volume
on SD-card but you can mount it as image on loop device. And you have
different messages in these two cases.

The reported issue can be a NILFS2 file system driver issue with some
probability. But, as I understand, first of all, you mounted this NILFS2
volume many times in normal mode on this SD-card. Secondly, we haven't
reproduction path of the reported issue for the case of Turbo mode. So,
it is impossible to talk something about possible file system driver
issue without understanding of technical environment and file system
operations that were a reason.

The hardware issue can have more probability, from my point of view. The
MMC protocol describes negotiation procedure between SD-card and
SD-controller. It defines voltage, frequency and operation mode between
controller and card during initialization phase. So, I think that it
takes place some in-proper negotiation for the case of Turbo mode or,
maybe, issue of concrete hardware realization of SD-card controller or
SD-controller on board. Moreover, it is possible also situation of SD
card's NAND flash wearing. As a result, writing or reading operations
can be failed partially or completely sometimes.

With the best regards,
Vyacheslav Dubeyko.


> Anyway, I did a second image, mounted it as before and it works. dmesg
> shows:
> [ 2740.544690] NILFS warning: broken superblock. using spare superblock (blocksize = 1024).
> [ 2740.544754] NILFS warning: broken superblock. using spare superblock (blocksize = 4096).
> [ 2740.544760] NILFS warning: mounting unchecked fs
> [ 2740.861477] NILFS: recovery complete.
> [ 2740.911019] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> 
> I will try to put the image after mount/umount back to the SD-card and
> check if it works on Raspberry Pi.
> 
> 
> Piotr Szymaniak.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html