From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiro SEKIBA Subject: Re: Segment magic number invalid Date: Wed, 19 May 2010 22:49:30 +0900 Message-ID: <871vd8dms5.wl%jir@sekiba.com> References: <20100517.114657.112904526.ryusuke@osrg.net> <20100517.162614.107743625.ryusuke@osrg.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20100517.162614.107743625.ryusuke-sG5X7nlA6pw@public.gmane.org> Sender: linux-nilfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="iso-8859-1" To: Ryusuke Konishi Cc: ninegua-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Hi, At Mon, 17 May 2010 16:26:14 +0900 (JST), Ryusuke Konishi wrote: >=20 > Hi, > On Mon, 17 May 2010 00:14:59 -0400, Paul L wrote: > > Wow, that does the trick! Here is the output after I change the num= ber to 500. > >=20 > > Super-block: > > revision =3D 2.0 > > blocksize =3D 4096 > > write time =3D 2010-05-14 13:58:33 > > indicated log: blocknr =3D 1608334 > > segnum =3D 785, seq =3D 307637, cno=3D671100 > >=20 > > Clean FS. > > The latest log is lost. Trying rollback recovery.. > > ................... > > Searching the latest checkpoint. > > Selected log: blocknr =3D 1304576 > > segnum =3D 637, seq =3D 307489, cno=3D670854 > > creation time =3D 2010-05-14 09:48:18 > > Do you wish to overwrite super block (y/N)? y > > Recovery will complete on mount. > >=20 > > I then mount /home, and things seem to work fine! Can I be sure tha= t > > everything will be ok from now on? Or should I backup and reformat? > > Thanks! >=20 > That was good!=20 >=20 > I recommend you to backup just now and reformat the partition since > the recovered filesystem rewound logs and may contain broken blocks > that GC later overrode. (If you were suspending GC, the filesystem i= s > guranteed to be consistent.) >=20 > It may be clean, but the fsck tool doesn't yet support sanity check. >=20 > > Actually, I now wonder what could have gone wrong in my case. I was= n't > > doing any disk intensive task and the machine wasn't suspended to r= am > > during the course. >=20 > This problem can happen if the block device doesn't support "write > barrier" properly. Unfortunately, such devices are not uncommon even > now. >=20 > I feel we should do something for it. How abou updating one of super blocks when super block update needed? I'm hoping that even "write barrier" is not supported, back up super bl= ock likely points valid older log. In case latest super block, which has greater CP, points invalid log, try to search log from the other super block that has older log and roll forwad the log until it finds newer super root. =46uther more, because each super block is less frequently updated, it may address low-end consumer flash super block hot-spot issue. thanks, regards > > On a separate note, I noticed that Nilfs2 has a higher chance of > > corruption when I mount over (a slightly sluggish) network. My back= up > > plan is also using Nilfs2, as detailed in this web page: > >=20 > > http://www.thev.net/PaulLiu/backup-plan.html > >=20 > > I rarely had any problem doing it over a USB hard drive, but when I > > remotely mount the backup image from a SMBFS over the network, I ra= n > > into problems of dangling nilfs_cleanerd, or just simply corrupted > > Nilfs2 partition for quite a few times, till the point that I rever= ted > > back to a local USB drive. Maybe this kind of use case can help you > > guys debugging the code and make it more robust. Just a wishful > > thought! >=20 > Thanks for the information. Looks helpful for debugging. >=20 > Thanks, > Ryusuke Konishi >=20 > > On Sun, May 16, 2010 at 10:46 PM, Ryusuke Konishi wrote: > > > Hi, > > > On Sun, 16 May 2010 14:32:05 -0400, Paul L wrote: > > >> Sorry, should have sent it to the list instead. > > >> > > >> =A0Thanks for the patch! I tried it, but seems it still can't fi= nd the > > >> =A0super root. Here is the output. What shall I do now? > > >> > > >> =A0Super-block: > > >> =A0 =A0 =A0revision =3D 2.0 > > >> =A0 =A0 =A0blocksize =3D 4096 > > >> =A0 =A0 =A0write time =3D 2010-05-14 13:58:33 > > >> =A0 =A0 =A0indicated log: blocknr =3D 1608334 > > >> =A0 =A0 =A0 =A0 =A0segnum =3D 785, seq =3D 307637, cno=3D671100 > > >> > > >> =A0Clean FS. > > >> =A0The latest log is lost. Trying rollback recovery.. > > >> =A0....... > > >> =A0fsck0.nilfs2: Cannot find super root > > > > > > Can you try increasing the number defined at the following line i= n > > > sbin/fsck/fsck0.nilfs2.c ? > > > > > > =A0#define =A0MAX_SCAN_SEGMENT =A0 =A0 =A0 =A0 =A050 > > > > > > Regards, > > > Ryusuke Konishi > > > > > >> > On 5/15/10, Ryusuke Konishi wrote: > > >> >> Hi, > > >> >> On Fri, 14 May 2010 20:24:02 -0400, Paul L wrote: > > >> >>> I have my home directory mounted as a nilfs2 partition. Toda= y what > > >> >>> happened was that first I noticed google-chrome reporting it= cannot > > >> >>> load user profile, I initially thought it was a google-chrom= e error. > > >> >>> At the time I was still able to view and modify my home dire= ctory. But > > >> >>> then after rebooting the system, my home partition no longer= mounts. > > >> >>> I'm using nilfs-2.0.19 and nilfs-utils-2.0.18 with Linux ker= nel > > >> >>> 2.6.28. > > >> >>> > > >> >>> Here is the error message from dmesg (after turning on debug= ging > > >> >>> message for nilfs2): > > >> >>> > > >> >>> NILFS nilfs_fill_super: start(silent=3D0) > > >> >>> NILFS(recovery) nilfs_search_super_root: looking segment > > >> >>> (seg_start=3D1607680, seg_end=3D1609727, segnum=3D785, seg_s= eq=3D307637) > > >> >>> NILFS(recovery) load_segment_summary: checking segment > > >> >>> (pseg_start=3D1608334, full_check=3D0) > > >> >>> NILFS(recovery) load_segment_summary: done (ret=3D3) > > >> >>> NILFS(recovery) nilfs_search_super_root: strayed: scan_newer= =3D0, ret=3D3 > > >> >>> NILFS warning: Segment magic number invalid > > >> >>> NILFS: error searching super root. > > >> >>> NILFS nilfs_fill_super: aborted > > >> >>> NILFS put_nilfs: the_nilfs on bdev mmcblk0p1 was freed > > >> >>> > > >> >>> I then dumped the first and last (backup) copy of the nilfs2= super > > >> >>> block, they are identical, and given below: > > >> >>> > > >> >>> 00000400 =A0 02 00 00 00 00 00 34 34 =A000 01 00 00 A1 6A E9= 71 > > >> >>> ......44.....j.q > > >> >>> 00000410 =A0 A3 F1 DD BE 02 00 00 00 =A0AF 07 00 00 00 00 00= 00 > > >> >>> ................ > > >> >>> 00000420 =A0 00 E0 BF D7 03 00 00 00 =A001 00 00 00 00 00 00= 00 > > >> >>> ................ > > >> >>> 00000430 =A0 00 08 00 00 05 00 00 00 =A07C 3D 0A 00 00 00 00= 00 > > >> >>> ........|=3D...... > > >> >>> 00000440 =A0 8E 8A 18 00 00 00 00 00 =A0B5 B1 04 00 00 00 00= 00 > > >> >>> ................ > > >> >>> 00000450 =A0 00 B8 23 00 00 00 00 00 =A0B9 AF F3 4A 00 00 00= 00 > > >> >>> ..#........J.... > > >> >>> 00000460 =A0 D9 E1 D6 4B 00 00 00 00 =A049 8F ED 4B 00 00 00= 00 > > >> >>> ...K....I..K.... > > >> >>> 00000470 =A0 37 00 32 00 03 00 01 00 =A0B9 AF F3 4A 00 00 00= 00 > > >> >>> 7.2........J....elp > > >> >>> 00000480 =A0 00 4E ED 00 00 00 00 00 =A000 00 00 00 0B 00 00= 00 > > >> >>> .N.............. > > >> >>> 00000490 =A0 80 00 20 00 C0 00 10 00 =A013 1C FC 11 D7 43 4C= 09 =A0.. > > >> >>> ..........CL. > > >> >>> 000004A0 =A0 81 64 93 0A F4 54 CF 5E =A048 4F 4D 45 00 00 00= 00 > > >> >>> .d...T.^HOME.... > > >> >>> > > >> >>> > > >> >>> I wonder if there is a fsck tool to help me recover the file= system. > > >> >>> Any help is greatly appreciated! > > >> >>> > > >> >>> PS: last time I had a different problem of losing partition = info, and > > >> >>> later successfully recovered with the help from people on th= e list. So > > >> >>> thanks! Now I'm actually backing up my files every two weeks= , but > > >> >>> it'll still be great if it can recover and even better if we= can trace > > >> >>> the problem. > > >> >> > > >> >> Your filesystem seems to have lost the latest log according t= o the > > >> >> report. > > >> >> > > >> >> The attached patch may help to recover it. =A0It is revised s= can tool > > >> >> for nilfs-utils-2.0.18. > > >> >> > > >> >> After compiling the tool, you can use it like: > > >> >> > > >> >> =A0# cd nilfs-utils-2.0.18 > > >> >> =A0# sbin/fsck/fsck0 > > >> >> > > >> >> The tool will confirm whether to update super blocks if it fi= nds the > > >> >> latest log. > > >> >> > > >> >> You may need to do > > >> >> > > >> >> =A0$ aclocal && autoheader && libtoolize -c --foce && automak= e -a -c && > > >> >> autoconf > > >> >> =A0$ ./configure > > >> >> > > >> >> before build the tool. > > >> >> > > >> >> With regards, > > >> >> Ryusuke Konishi > > >> >> > > >> > > > >> > > > >> > -- > > >> > Regards, > > >> > Paul Liu > > >> > > > >> > Yale Haskell Group > > >> > http://www.haskell.org/yale > > >> > > > >> > > >> > > >> -- > > >> Regards, > > >> Paul Liu > > >> > > >> Yale Haskell Group > > >> http://www.haskell.org/yale > > >> -- > > >> 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 =A0http://vger.kernel.org/majordomo-info.= html > > > > >=20 > >=20 > >=20 > > --=20 > > Regards, > > Paul Liu > >=20 > > Yale Haskell Group > > http://www.haskell.org/yale > -- > 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 >=20 >=20 >=20 --=20 Jiro SEKIBA -- 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