On Mon, Apr 4, 2011 at 11:51 AM, Bruce Evans <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "[email protected]"
