Date: Mon, 4 Feb 2008 17:41:02 -0500 From: Martin Cracauer <cracauer@cons.org> To: "Julian H. Stacey" <jhs@berklix.org> Cc: freebsd-fs@freebsd.org, Martin Cracauer <cracauer@cons.org> Subject: Re: fsck and mount disagree on whether superblocks are usable Message-ID: <20080204224102.GA11286@cons.org> In-Reply-To: <200802042104.m14L4lep052239@fire.js.berklix.net> References: <20080201172214.GA55957@cons.org> <200802021916.m12JGUjN049706@fire.js.berklix.net> <20080204163308.GA96092@cons.org> <200802041727.m14HREuN049123@fire.js.berklix.net> <20080204205801.GA7398@cons.org> <200802042104.m14L4lep052239@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian H. Stacey wrote on Mon, Feb 04, 2008 at 10:04:47PM +0100: > Martin Cracauer wrote: > > Julian H. Stacey wrote on Mon, Feb 04, 2008 at 06:27:14PM +0100: > > > Martin Cracauer wrote: > > > > Julian H. Stacey wrote on Sat, Feb 02, 2008 at 08:16:30PM +0100: > > > > > Martin Cracauer wrote: > > > > > > This is not an emergency but I find it odd. Mount and fsck agree on > > > > > > whether superblocks are usable. Mount can mount readonly, but fsck > > > > > > can use neither the primary superblock nor the alternatives. > > > > > > > > > > > > 32 is not a file system superblock > > > > > > > > > > Just in case, You know secondary block on newer FSs moved from 32 ? > > > > > Ref man fsck_ufs > > > > > -b Use the block specified immediately after the flag as the super > > > > > block for the file system. An alternate super block is usually > > > > > located at block 32 for UFS1, and block 160 for UFS2. > > > > > > > > Thanks, Julian. > > > > > > > > I'm honestly don't know how to tell whether I have ufs1 or ufs2. > > > > > > I didnt either, but wanted to know & just found one way: > > > > > > dumpfs /dev/____ | grep -i ufs > > > > Yupp, there you go. > > > The reason why it failed for me is that it was looking for the > > superblocks in the wrong place. > > > > This works: > > fsck_ffs -b 160 /dev/ad0s1a > > > > I now need to debug why the target machine's fsck seemed to think it's > > ufs1 or why else it looked at 32 when the source machine didn't. > > Yup, always nice to understand whats going on/went on, but at some > stage in your shoes, I'd copy all data to another place & then newfs > & copy back, for peace of mind :-) Why do you say that? `df -i` shows I only lost about 50,000 files :-) ~(grisu)1% df -i / Filesystem 1024-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a 137150084 91580772 34597306 73% 976369 16758285 6% / ~(wings)11# df -i /mnt/tmp Filesystem 1024-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a 137150084 88153916 38024162 70% 932371 16802283 5% /mnt/tmp I still want to find out what's going on here. The disk geometry as reported by both fdisk and disklabel is identical, so that's not it. I don't see the reason why fsck should get confused here and I think that people might get bitten by this phaenomen after doing something less insane than I did. Basically, a 7-stable fsck destroyed a 6-stable filesystem here in a situation where it might or might not be justified. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080204224102.GA11286>