Hi,

The volume is now restored from a backup of yesterday. As there have
been no changes since then, no data has been lost. I also tried to do a
tar of the nilfs volume having errors in order to see how this failed
partition would be handled. The partition had 13 gb of data and the tar
file keeped growing, I cancelled at 46 gb, so I think there was a loop
in here somewhere. I also received numerous nilfs related error
messages. I have attached them to the end of this mail.
As the backup of yesterday worked flawlessly, the corruption must have
occured today.

As I am doing video editing on nilfs2 filesystems, and so I don't want
the cleaner to interfere with it, I always do mount -i and if I am short
on space, I call the cleaner manually and send it a SIGTERM signal, once
I see no more cleaning activity. I have modified the number of segments
to clean from 2 to 20 in order to speed up cleaning.

As this moring, I had 95% of used space, I called the cleaner manually.
The cleaner seemed to work normally so after there was no more disk
activity, I sent it a SIGTERM signal. As I am running on gentoo, I did
an emerge --sync followed by an emerge --update --deep --ask world, so
there was lots of io on this partition (it was the root one). During
this, the system crashed completely  without reaction to any key. As I
find no data on this crash in the log files, I can't say if the nilfs
corruption was leading to this crash or if this crash was leading to the
nilfs corruption.

After this crash, I first saw error messages from nilfs.

I did a dd if=/dev/sda3 of=imagefile bs=8192 of the partition prior to
the restore, so if you like to further investigate into this, the
corrupted partition is still mountable via a loop device. If this data
is useless for you, please tell me so, then I will delete the image file.

Bye,
David Arendt

Ryusuke Konishi wrote:
> On Tue, 17 Mar 2009 00:09:05 +0900 (JST), Ryusuke Konishi wrote:
>   
>> Hi David,
>> On Mon, 16 Mar 2009 11:18:13 +0100, David Arendt wrote:
>>     
>>> Hi,
>>>
>>> this morning I discovered this in /var/log/messages
>>>
>>> Mar 16 10:59:00 server NILFS error (device sda3): nilfs_check_page: bad
>>> entry in directory #37945: unaligned directory entry - offset=0,
>>> inode=1919250021, rec_len=14411, name_len=67
>>>
>>> I am using nilfs 2.0.10.
>>>
>>> What should I do about this error ? Should I ignore it or should special
>>> care be taken about it ?
>>>
>>>       
>> offset=0 --> first entry of the directory.
>> inode=1919250021 --> unnatural inode number. seems invalid.
>> rec_len=14411 --> invalid.
>>
>> So, this directory is completely broken. Maybe b-tree of the directory
>> is pointing to a wrong block.
>>
>> Is this reproducible by umount/mount and ls -R ?
>>     
>
> The directory's inode number was shown in the log!
> You can find it by:
>
>  $ find /mount-dir -inum 37945 -ls
>
>
> Regards,
> Ryusuke Konishi
>
>