Date: Thu, 3 Nov 2005 22:49:13 +0300 From: Taras Savchuk <taras.savchuk@gmail.com> To: Xin LI <delphij@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] Message-ID: <84099c3d0511031149u53fee379of6158584e075d38d@mail.gmail.com> In-Reply-To: <a78074950511031120r6b51bbedt692b7ed614f0da45@mail.gmail.com> References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030535x400c80f4k7ab7ad1905d8f918@mail.gmail.com> <a78074950511031120r6b51bbedt692b7ed614f0da45@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/3/05, Xin LI <delphij@gmail.com> wrote: On 11/3/05, Taras Savchuk <taras.savchuk@gmail.com> wrote: > My SATA HDD with UFS2 crashed. While checking HDD fsck said, that alterna= te > super block at block 32 is not present. In 'man fsck' I saw, that in UFS2= =20 > (my file system) alternate super block is usually located in block 160 (F= or > 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 fi= le =20 > system type (UFS1 or UFS2) while checking, but such assumption seems to b= e > wrong. > > fsck with '-b 160' optione works well. I think this is a bug. You may want to dig into fsck_ffs/setup.c to =20 find out how to solve this... I'll try, but I'm not a big kernel-hacker. Thank you for answer.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84099c3d0511031149u53fee379of6158584e075d38d>