From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: ATA 4 KiB sector issues. Date: Mon, 08 Mar 2010 13:16:48 -0800 Message-ID: <4B956940.1060304@zytor.com> References: <4B947393.2050002@kernel.org> <1268031640.4389.11.camel@mulgrave.site> <4B9546E6.6050006@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from terminus.zytor.com ([198.137.202.10]:50160 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755744Ab0CHVRU (ORCPT ); Mon, 8 Mar 2010 16:17:20 -0500 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: "Martin K. Petersen" Cc: James Bottomley , Tejun Heo , "linux-ide@vger.kernel.org" , lkml , Daniel Taylor , Jeff Garzik , Mark Lord , tytso@mit.edu, hirofumi@mail.parknet.co.jp, Andrew Morton , Alan Cox , irtiger@gmail.com, Matthew Wilcox , aschnell@suse.de, knikanth@suse.de, jdelvare@suse.de On 03/08/2010 12:19 PM, Martin K. Petersen wrote: >>>>>> "hpa" == H Peter Anvin writes: > > hpa> On the flipside, though, there really is very little net benefit to > hpa> 4K as opposed to 512 byte logical sectors: the additional protocol > hpa> overhead is relatively minimal, and as long as writes are aligned > hpa> full blocks, there shouldn't be any additional overhead on either > hpa> the OS or the drive side. On the plus side, you get full > hpa> compatibility with the existing software stack. The equation > hpa> really seems rather simple. > > 4KB sectors are not a win for anybody except the drive vendors. > Obviously. However, larger physical storage unit sizes -- 4K for spinning media, but frequently much larger for flash, for example -- is already in wide use, and having a huge mishmash of logical block sizes isn't going to work very well. > There is a push in the industry right now to keep the 512-byte logical > blocks forever. The first step would be to report misaligned accesses > or accesses that are not a multiple of the physical block size. Second > step would be to eventually reject any write that's not a properly > aligned multiple of the physical block size. I personally suspect that that is the way it is going to go, rather than trying to change the software ecosystem to a different logical block size. It has been tried in the past and failed, with the sole exception of CD-ROMs, pretty much. -hpa