Good time of the day! I'v got a nilfs2 partition on a 1TB md RAID1 partition composed of two HDD's. Kernel 3.5.3, userspace utils v2.1.1. Gentoo linux distribution. Just updated utils to 2.1.4 but no failure since. After power shutdown, mount takes about several hours. For the first time I thought that it won't mount at all and tried to use fsck tool, found somewhere in the internet(don't really remember). It reported that superblock is ok. Than I commented the check in the source file and the default number of blocks to check appeared to be too small. It failed to find the next superblock. I've increased the number, but increasing it to *100 didn't help. So, probably the reserved SB is too far from away and it takes too long to find it. Does anybody knows, how can it be speed up? I know, UPS is a solution, but I consider it be a bug. nilfs-tune -l /dev/md0 nilfs-tune 2.1.1 Filesystem volume name: (none) Filesystem UUID: 9adc7cf2-4c04-4030-91d9-fae9a19ded03 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: Wed Feb 29 20:32:28 2012 Last mount time: Fri Oct 26 23:54:26 2012 Last write time: Mon Oct 29 20:05:34 2012 Mount count: 11 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: 119233 Device size: 1000202649600 First data block: 1 # of blocks per segment: 2048 Reserved segments %: 5 Last checkpoint #: 1003256 Last block address: 160163840 Last sequence #: 3416007 Free blocks count: 53164032 Commit interval: 0 # of blks to create seg: 0 CRC seed: 0xc2316108 CRC check sum: 0x56f9857c CRC check data size: 0x00000118 -------------------------------------------------- Aleksandrov Sergey Vasil'evich -- 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
