Date: Tue, 5 Apr 2011 01:51:56 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Ivan Voras <ivoras@freebsd.org>, freebsd-hardware@freebsd.org Subject: Re: Advanced disk format at WD20EARS: what should "camcontrol identify" show? Message-ID: <20110405011652.N1521@besplex.bde.org> In-Reply-To: <201104041541.47737.hselasky@c2i.net> References: <22830765.20110404101040@serebryakov.spb.ru> <incf8j$dn3$1@dough.gmane.org> <201104041541.47737.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110405011652.N1521>