newfs_msdos and DVD-RAM
kostikbel at gmail.com
Tue Mar 30 08:09:56 UTC 2010
On Tue, Mar 30, 2010 at 10:40:07AM +1100, Bruce Evans wrote:
> On Mon, 29 Mar 2010, Andriy Gapon wrote:
> >I am not a FAT expert and I know to take Wikipedia with a grain of salt.
> >But please take a look at this:
> >In our formula:
> >SecPerClust *= pmp->pm_BlkPerSec;
> >we have the following parameters:
> >SecPerClust[in] - sectors per cluster
> >pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / DEV_BSIZE)
> >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 the
> >of bytes per cluster becomes greater than 32 KB."
> 64K works under FreeBSD, and I often do performance tests with it (it gives
> very bad performance). It should be avoided for portability too.
> >But in our case it's 256K, the same value that is passed as 'size'
> >parameter to
> >bread() in the crash stack trace below.
> 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.
> 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.
> >By the way, that 32KB limit means that value of SecPerClust[out] should
> >never be
> >greater than 64 and SecPerClust[in] is limited to 128, so its current must
> >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
> >those were
> >provided as overrides via command line options.
> 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.
> >>fk at r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1
> >>Unread portion of the kernel message buffer:
> >>panic: getblk: size(262144) > MAXBSIZE(65536)
> >>#11 0xffffffff803bedfb in panic (fmt=Variable "fmt" is not available.
> >>) at /usr/src/sys/kern/kern_shutdown.c:562
> BTW, why can't gdb find any variables? They are just stack variables whose
> address is easy to find.
> >>#14 0xffffffff8042f24e in bread (vp=Variable "vp" is not available.
> >>) at /usr/src/sys/kern/vfs_bio.c:748
> ... 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100330/5e454f66/attachment.pgp
More information about the freebsd-current