Date: Tue, 20 Dec 2011 19:03:52 +0100 From: Peter Holm <peter@holm.cc> To: Kostik Belousov <kostikbel@gmail.com> Cc: Michiel Boland <boland37@xs4all.nl>, freebsd-stable@freebsd.org, Peter Jeremy <peterjeremy@acm.org> Subject: Re: fsck_ufs out of swapspace Message-ID: <20111220180352.GA58342@x2.osted.lan> In-Reply-To: <20111220094832.GL50300@deviant.kiev.zoral.com.ua> References: <4EECFD6A.2030905@xs4all.nl> <2E07A04E-0FBF-47BE-96E7-F615FE78056E@gromit.dlib.vt.edu> <4EEFAC55.6050507@xs4all.nl> <20111219225143.GD2391@server.vk2pj.dyndns.org> <20111220094832.GL50300@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 20, 2011 at 11:48:33AM +0200, Kostik Belousov wrote: > On Tue, Dec 20, 2011 at 09:51:43AM +1100, Peter Jeremy wrote: > > On 2011-Dec-19 22:27:49 +0100, Michiel Boland <boland37@xs4all.nl> wrote: > > >Problem solved - it was indeed an endian thing. > > >The problem is that fsck uses a real_dev_bsize variable that is declared long, > > >but the DIOCGSECTORSIZE ioctl takes an u_int argument. > > > > To be accurate, this isn't an endian problem, it's a general problem > > of passing a pointer to an incorrectly sized object. The bug is > > masked on amd64 & iA64 because real_dev_bsize is statically allocated > > and therefore initialised to zero. This means the failure to assign > > the top 32 bits in the ioctl doesn't affect the final result. > > > > >A PR has been submitted. > > > > sparc64/163460 for the record. Thank you for tracking that down. > > The easier fix is to change the type of real_dev_bsize. I used long only > because other n variables keeping the sector size are long, but there > is no much reason to use long there. > > Peter, would you, please retest the +J on non-512 byte sectors, with the > patch attached ? > No problems seen while testing on both i386 and amd64 with a malloc MD disk, sector size of 4k and SUJ. - Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111220180352.GA58342>