Date: Mon, 4 Apr 2011 15:56:28 -0400 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-hardware@freebsd.org, Ivan Voras <ivoras@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: Advanced disk format at WD20EARS: what should "camcontrol identify" show? Message-ID: <BANLkTinmLY4GH-MjhVJq9jrETkEc=Bg42Q@mail.gmail.com> In-Reply-To: <20110405011652.N1521@besplex.bde.org> References: <22830765.20110404101040@serebryakov.spb.ru> <incf8j$dn3$1@dough.gmane.org> <201104041541.47737.hselasky@c2i.net> <20110405011652.N1521@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 4, 2011 at 11:51 AM, Bruce Evans <brde@optusnet.com.au> wrote: > 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 > _______________________________________________ > I do not know whether the following discussions may be useful or not : http://openindiana.org/pipermail/openindiana-discuss/2011-March/003132.html ( [OpenIndiana-discuss] 3TB disks for tank zpool? Can only use 2 TB. ) http://openindiana.org/pipermail/openindiana-discuss/2011-February/002515.html ( [OpenIndiana-discuss] Are there any issues re ZFS on 2TB disks (from WD??) with large blocksizes? ) http://openindiana.org/pipermail/openindiana-discuss/2011-February/002575.html ( [OpenIndiana-discuss] info about Solaris and the new 4K-Sector-Disks (e.g. WDxxEARS) ) Thank you very much . Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinmLY4GH-MjhVJq9jrETkEc=Bg42Q>