From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 23:40:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CCE106566C; Mon, 29 Mar 2010 23:40:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 159E08FC08; Mon, 29 Mar 2010 23:40:15 +0000 (UTC) Received: from c122-106-158-90.carlnfd1.nsw.optusnet.com.au (c122-106-158-90.carlnfd1.nsw.optusnet.com.au [122.106.158.90]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o2TNe7jv001070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 10:40:08 +1100 Date: Tue, 30 Mar 2010 10:40:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <4BB0A053.9060007@freebsd.org> Message-ID: <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 30 Mar 2010 02:00:57 +0000 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 23:40:16 -0000 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: > http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector > > 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 number > 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@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=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 once. Bruce