On 03/19/2010 09:39 AM, Till Maas wrote: > On Fri, Mar 19, 2010 at 09:21:53AM -0400, Ric Wheeler wrote: >> On 03/19/2010 08:08 AM, Till Maas wrote: >>> On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: >>>> Alexander Boström wrote: >>>>> ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: >>>>> >>>>>> There has been a lot of work upstream on 4k sector support, and in general >>>>>> yes, we are ready. >>>>> >>>>> Problems can probably be expected in case the drive does not report its >>>>> real block size to the software, though, like my WD15EARS (I think) or >>>>> VMware's emulated SCSI drives. >>>> >>>> There's only so much we can do in the face of bad hardware ;) >>> >>> How about making it possible to overwrite the wrong reported values, >>> e.g. by making /sys/block/sdb/queue/[physical_block_size >>> writable,minimum_io_size} writable. > >> I think that would be a bad idea - if you know what you want to change, why not >> just invoke the tool with those specific parameters? > > It would not be that annoying, if it was only one tool. But there are > e.g. at least fdisk, mdadm, lvm, cryptsetup and mkfs.*/mkswap that all > have to properly align the data. > >> It would be very confusing to have us probe the device, get the real information >> from the storage device and then let a user update that information to something >> "false" :-) > > So add some interface to query whether the information was probed or set > by a user. Then it should not be that confusing. :-) > > Regards > Till > We are currently working to verify that storage devices work properly & report the information that they want us to use (doing this with several storage providers and have also raised this with EMC/VMware). Specifically for vmware, I think that our default will be good for them when a device fails to report. Specifically, their own tech report suggests using a non-default alignment (sector 128 iirc?). We can certainly work to verify this with them. If we see real world issues during this testing, we can start thinking about how to fix it. thanks! ric ric -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
