On Thu, 23 Jun 2011 11:21:03 -0700, Zahid Chowdhury wrote: > Hello Ryusuke, > After the new kernel module (2.0.22) the nilfs partition mounted > with no problems. I have encountered no problems since then. Doing > a lssu(1) does not show segment 759 to be on the list of used > segments any further: > > lssu -a /dev/sda2 > SEGNUM DATE TIME STAT NBLOCKS > 0 2011-06-23 10:56:42 -d- 2047 > 1 2011-06-23 10:56:42 -d- 2048 > 2 2011-06-23 10:56:42 -d- 2048 > 3 2011-06-23 10:56:42 -d- 2048 > 4 2011-06-23 10:56:44 -d- 2048 > 5 2011-06-23 10:56:46 -d- 2048 > 7 2011-06-23 10:56:46 -d- 2048 > 8 2011-06-23 10:56:47 -d- 2048 > 9 2011-06-23 10:56:47 -d- 2048 > 10 2011-06-23 10:56:47 -d- 2048 > 11 2011-06-23 10:56:47 -d- 2048 > 12 2011-06-23 10:56:47 -d- 2048 > 13 2011-06-23 10:56:52 -d- 2048 > 14 2011-06-23 10:56:52 -d- 2048 > 16 2011-06-23 10:56:52 -d- 2048 > 17 2011-06-23 10:56:52 -d- 2048 > 18 2011-06-23 10:56:52 -d- 2048 > 19 2011-06-23 10:56:53 -d- 2048 p> 20 2011-06-23 10:56:54 ad- 1273 > 21 ---------- --:--:-- ad- 0 > 946 2011-06-23 10:52:27 -d- 2048 > 947 2011-06-23 10:52:28 -d- 2048 > 948 2011-06-23 10:52:28 -d- 2048 > 949 2011-06-23 10:52:28 -d- 2048 > . > . > . > Though dumpseg 759 does not show anything untoward (I don't think its used any further, correct?): > > dumpseg /dev/sda2 759 > segment: segnum = 759 > sequence number = 608068, next segnum = 760 > partial segment: blocknr = 1554432, nblocks = 2048 > creation time = 2011-06-23 10:48:02 > nfinfo = 652 > finfo > ino = 7984, cno = 13, nblocks = 756, ndatblk = 756 > vblocknr = 146359, blkoff = 30686, blocknr = 1554444 > vblocknr = 146360, blkoff = 30687, blocknr = 1554445 > . > . > . > finfo > ino = 16619, cno = 3763620, nblocks = 2, ndatblk = 2 > vblocknr = 224656, blkoff = 304, blocknr = 1555200 > vblocknr = 224635, blkoff = 305, blocknr = 1555201 > finfo > ino = 16619, cno = 3763616, nblocks = 1, ndatblk = 1 > vblocknr = 224551, blkoff = 303, blocknr = 1555202 > . > . > . Hmm, the segment looks to be overwritten with new data after the partition was successfully mounted. I don't know if it's certainly safe now, but It might be needless fear. > One other question I have for anybody on the list or Ryusuke, on a > corruption of nilfs on older kernels (pre 2.6.30) should I leave > fsck0.nilfs2 to run on the initscripts besides the new 2.0.22 kernel > module or is this really redundant? Thanks for any > help/comments. All, as far as I can see, this is a pretty cool > filesystem. For now, fsck0.nilfs2 is just a manual rollback tool. There is no merit to run it from initscripts since it doesn't verify filesystem consistency. ( Clearly, making a true fsck is one of TODO items. ) As for fsck0.nilfs2, you only have to use it when you couldn't mount the partition. I hope this never happens for the 2.0.22 module. Thanks for your interest and help. Regards, Ryusuke Konishi > Zahid > > -----Original Message----- > From: Ryusuke Konishi [mailto:konishi.ryusuke@xxxxxxxxxxxxx] > Sent: Thursday, June 23, 2011 4:25 AM > To: Zahid Chowdhury > Cc: linux-nilfs@xxxxxxxxxxxxxxx > Subject: Re: mount & fsck of nilfs partition fail. > > On Mon, 20 Jun 2011 11:27:49 -0700, Zahid Chowdhury wrote: > > Hello Ryusuke, > > > > Sorry, I was away on the w/e. I've attached the console trace and > > the out file again for posterity. I will be upgrading to the > > recently released 2.0.22 version, and will try to mount the > > corrupted filesystem with it - unlikely, it will work, though it > > should help on future filesystems based on nilfs2? Thanks for the > > fsck help and the new release for older kernels. Please let me > > know if you need anything further, such that I can recover the > > corrupted filesystem. > > > > Zahid > > > > The console trace: > > /sbin/fsck0.nilfs2 -f -v /dev/sda2 > > Super-block: > > revision = 2.0 > > blocksize = 4096 > > write time = 2011-06-11 23:22:03 > > indicated log: blocknr = 1648528 > > segnum = 804, seq = 401758, cno=3250953 > > > > Unclean FS. > > The latest log is lost. Trying rollback recovery.. > > ...... > > Searching the latest checkpoint. > > get_latest_cno: log_start=1556429 (segnum=759): nfinfo=6, fblocknr=1556430 > > get_latest_cno: finfo: ino=17874, sum-blocknr=1556429, offset=80, nblocks=2, ndatablk=1, fblocknr=1556430 > > get_latest_cno: finfo: ino=17875, sum-blocknr=1556429, offset=128, nblocks=1, ndatablk=1, fblocknr=1556432 > > get_latest_cno: finfo: ino=6, sum-blocknr=1556429, offset=168, nblocks=2, ndatablk=1, fblocknr=1556433 > > get_latest_cno: finfo: ino=4, sum-blocknr=1556429, offset=216, nblocks=3, ndatablk=2, fblocknr=1556435 > > get_latest_cno: finfo: ino=4499, sum-blocknr=1556429, offset=280, nblocks=1306282328, ndatablk=0, fblocknr=1556438 > > According to this log, the summary information of segment #759 looks > broken. This may cause future GC failure or filesystem corruption. > > Could you confirm whether the segment summary is actually broken or > not ? This can be done with dumpseg tool: > > # dumpseg /dev/sda2 759 > > If it looks actually broken, I recommend you to back up all data as > soon as possible. > > Regards, > Ryusuke Konishi > -- > 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 -- 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
