Date: Sun, 6 Nov 2005 17:49:17 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Taras Savchuk <taras.savchuk@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] Message-ID: <20051106144917.GA81664@comp.chem.msu.su> In-Reply-To: <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 03, 2005 at 03:25:28PM +0300, Taras Savchuk wrote: > On 11/3/05, Taras Savchuk <taras.savchuk@gmail.com> wrote: > > > > My SATA HDD with UFS2 crashed. While checking HDD fsck said, that > > alternate super block at block 32 is not present. In 'man fsck' I saw, that > > in UFS2 (my file system) alternate super block is usually located in block > > 160 (For UFS1 - in 32). So the question is: why fsck trying to find > > alternate superblock in wrong block for UFS2? I can suppose, that fsck dont > > know file system type (UFS1 or UFS2) while checking, but such assumption > > seems to be wrong. > > PS: With '-b 160' option fsck done work well. Isn't the type, UFS1 or UFS2, indicated by a magic number in the superblock itself? I used to believe so. If it's true, fsck cannot know the FS type prior to locating a superblock copy. OTOH, with UFS2 having become popular, fsck might try both locations, 32 and 160. Care to file a PR? -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051106144917.GA81664>