From owner-freebsd-hardware@FreeBSD.ORG Mon Apr 4 20:25:34 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 3ED1C106564A; Mon, 4 Apr 2011 20:25:34 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id D09B08FC08; Mon, 4 Apr 2011 20:25:33 +0000 (UTC) Received: by qyk35 with SMTP id 35so1316018qyk.13 for ; Mon, 04 Apr 2011 13:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3FWOIUfcVH5YTnkAEFEI0XcjUc5j16i+KSLrQ4bDBRA=; b=hBfhZPi4fs7dRpAUTB+sg2J+DNam5tKyWuKB84CJs6XVZW1MN/kbfaFfsccMARCCD4 13N0px4aXBBO/wIiEiU+5WcVBagrQVZTfJ3cPStoLSLC65chBEzV4m9wpcp/RHJhR5IH nALIrj6UiqILlYNZKM6cQnHLyjyCpkVgsw5aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hz4TlVCB7+3NWrVkk5fkHJV/cQ2d2SvQpHTX2HG3GMGO/m93NIzZg6FVB96Ca4V1y7 eFfTeHbdOZ+JKCmc9Wu7sbNUf5+lJciXf8p7+JaVr8J2vdZfO7fgFlYgNOW7c8eivVsj ihQwgNBIqDFXicwgFcyy9DmDa1EMdFa3Yf2M8= MIME-Version: 1.0 Received: by 10.224.202.132 with SMTP id fe4mr6272112qab.249.1301946988992; Mon, 04 Apr 2011 12:56:28 -0700 (PDT) Received: by 10.224.67.75 with HTTP; Mon, 4 Apr 2011 12:56:28 -0700 (PDT) In-Reply-To: <20110405011652.N1521@besplex.bde.org> References: <22830765.20110404101040@serebryakov.spb.ru> <201104041541.47737.hselasky@c2i.net> <20110405011652.N1521@besplex.bde.org> Date: Mon, 4 Apr 2011 15:56:28 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Bruce Evans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hardware@freebsd.org, Ivan Voras , Hans Petter Selasky 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 20:25:34 -0000 On Mon, Apr 4, 2011 at 11:51 AM, Bruce Evans 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