Skip site navigation (1)Skip section navigation (2)
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>