Date: Tue, 30 Mar 2010 11:09:16 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Bruce Evans <bde@zeta.org.au>, Andriy Gapon <avg@icyb.net.ua>, freebsd-current@freebsd.org, Andriy Gapon <avg@freebsd.org>, Kostik Belousov <kostikbel@gmail.com> Subject: Re: newfs_msdos and DVD-RAM Message-ID: <20100330080916.GI2415@deviant.kiev.zoral.com.ua> In-Reply-To: <20100330101734.R5158@delplex.bde.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100330101734.R5158@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/KyuVX2Jeo6C4NIo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2010 at 10:40:07AM +1100, Bruce Evans wrote: > On Mon, 29 Mar 2010, Andriy Gapon wrote: >=20 > >... > >I am not a FAT expert and I know to take Wikipedia with a grain of salt. > >But please take a look at this: > >http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector > > > >In our formula: > >SecPerClust *=3D pmp->pm_BlkPerSec; > >we have the following parameters: > >SecPerClust[in] - sectors per cluster > >pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / DEV_BSI= ZE) > >SecPerClust[out] - bytes per cluster divided by 512 > > > >So we have: > >sectors per cluster: 64 > >bytes per sector: 4096 > > > >That Wikipedia article says: "However, the value must not be such that t= he=20 > >number > >of bytes per cluster becomes greater than 32 KB." >=20 > 64K works under FreeBSD, and I often do performance tests with it (it giv= es > very bad performance). It should be avoided for portability too. >=20 > >But in our case it's 256K, the same value that is passed as 'size'=20 > >parameter to > >bread() in the crash stack trace below. >=20 > This error should be detected more cleanly. ffs fails the mount if the > block size exceeds 64K. ffs can handle larger block sizes, and it is > unfortunate that it is limited by the non-ffs parameter MAXBSIZE, but > MAXBSIZE has been 64K and non-fuzzy for so long that the portability > considerations for using larger values are even clearer -- larger sizes > shouldn't be used, but 64K works almost everywhere. I used to often do > performance tests with block size 64K for ffs. It gives very bad > performance, and since theire are more combinations of block sizes to > test for ffs than for msdosfs, I stopped testing block size 64K for ffs > long ago. >=20 > msdosfs has lots more sanity tests for its BPB than does ffs for its > superblock. Some of these were considered insane and removed, and there > never seems to have been one for this. >=20 > >By the way, that 32KB limit means that value of SecPerClust[out] should= =20 > >never be > >greater than 64 and SecPerClust[in] is limited to 128, so its current mu= st=20 > >be of > >sufficient size to hold all allowed values. > > > >Thus, clearly, it is a fault of a tool that formatted the media for FAT. > >It should have picked correct values, or rejected incorrect values if=20 > >those were > >provided as overrides via command line options. >=20 > If 256K works under WinDOS, then we should try to support it too. mav@ > wants to increase MAXPHYS. I don't really believe in this, but if MAXPHYS > is increased then it would be reasonable to increase MAXPHYS too, but > probably not to more than 128K. >=20 > >>fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 > >[snip] > >>Unread portion of the kernel message buffer: > >>panic: getblk: size(262144) > MAXBSIZE(65536) > >[snip] > >>#11 0xffffffff803bedfb in panic (fmt=3DVariable "fmt" is not available. > >>) at /usr/src/sys/kern/kern_shutdown.c:562 >=20 > BTW, why can't gdb find any variables? They are just stack variables who= se > address is easy to find. >=20 > >>... > >>#14 0xffffffff8042f24e in bread (vp=3DVariable "vp" is not available. > >>) at /usr/src/sys/kern/vfs_bio.c:748 >=20 > ... and isn't vp a variable? Maybe the bad default -O2 is destroying > debugging. Kernels intended for being debugged (and that is almost all > kernels) shouldn't be compiled with many optimizations. Post-gcc-3, -O2 > breaks even backtraces by inlining static functions that are called only > once. Dwarf interpreter in the very old gdb 6.1.1 that is provided in our tree is same old and buggy. I found that latest gdbs, like 6.8, 7.1 etc work much better even with slightly newer gcc 4.2.1 from the tree. amd64 calling conventions do not make this easier. --/KyuVX2Jeo6C4NIo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuxsawACgkQC3+MBN1Mb4idRgCg3JrETuvFBCdbyMY3M9/ytnwc ZI0AnR+UT4aBlMdk+rXGHjlYSW2r8Et5 =2+ap -----END PGP SIGNATURE----- --/KyuVX2Jeo6C4NIo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100330080916.GI2415>