From owner-freebsd-hardware@FreeBSD.ORG Mon Apr 4 17:01:26 2011 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F66A1065670; Mon, 4 Apr 2011 17:01:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id BF6C68FC1D; Mon, 4 Apr 2011 17:01:25 +0000 (UTC) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p34Fq8Ia004994; Tue, 5 Apr 2011 01:52:08 +1000 Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p34FpukB026268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 01:51:58 +1000 Date: Tue, 5 Apr 2011 01:51:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hans Petter Selasky In-Reply-To: <201104041541.47737.hselasky@c2i.net> Message-ID: <20110405011652.N1521@besplex.bde.org> References: <22830765.20110404101040@serebryakov.spb.ru> <201104041541.47737.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ivan Voras , freebsd-hardware@freebsd.org Subject: Re: Advanced disk format at WD20EARS: what should "camcontrol identify" show? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:01:26 -0000 On Mon, 4 Apr 2011, Hans Petter Selasky wrote: > On Monday 04 April 2011 14:57:55 Ivan Voras wrote: >> On 04/04/2011 08:10, Lev Serebryakov wrote: >>> Hello, Alexander. > >> If you just replace a non-4K drive in a RAID5 with a 4K drive, it is >> very likely that there would be alignment problems with that drive. > > Some tools like fdisk don't work, because they cannot read/write 512 bytes on > a disk with blocksize greater than 512 bytes. fdisk is actually one of the few programs that attempts to support "arbitrary" power of 2 sector sizes correctly, by probing for a sector size that works. However, this arbitaryness is limited by fdisk's hard coding of bogus limits MIN_SEC_SIZE = 512 and MAX_SEC_SIZE = 2048, so it requires minor changes to work with a sector size of 4096, and it might have other bugs. fdisk also gets the sector size using g_sectorize(), but for some reason it only uses this in 1 function. Failure of g_sectorsize() now makes main() fail. Old versions of fdisk used the DIOCGSECTORSIZE ioctl and had a fall back to using a sector size of 512 in the 1 function (although this and even the result of a successful g_sectorsize() may be inconsistent with the probe). When I fixed my version of fsck_msdosfs to work with 2K-sectors, I made the corresponding limits 512 and 64K, so 4K should work. fsck_msdosfs remains portable and doesn't use g_sectorsize() or DIOCGSECTORSIZE, so it doesn't fail at either compile time or run time when they are not supported. All of the methods used by fdisk are wrong. The media or just the MBR for it may be kept in a regular file. (I always keep backups of MBRs in regular files and often run fdisk on these files to compare with the current MBRs.) Then g_sectorsize() and DIOCGSECTORSIZE should just fail. Indeed, DIOCGSECTORSIZE in an old version of fdisk does fail, and the fallback is used. I don't use the current broken version of fdisk which would fail. The probe method is adequate for fsck_msdosfs, since the boot parameter block gives the sector size for the media on which the file system lives (or lived or will live). Better programs like newfs and newfs_msdos allow specifying the sector size on the command line. Bruce