svn commit: r304142 - head/usr.sbin/bsdinstall/partedit

[Nathan Whitehorn]

On 08/17/16 08:57, Warner Losh wrote:
> On Wed, Aug 17, 2016 at 9:26 AM, Nathan Whitehorn
> <nwhitehorn at freebsd.org> wrote:
>> Not true at all. All modern disks report their physical sector size, as
>> distinct from the logical one, in their ATA IDENTIFY data and ata_da.c uses
>> that.
> You are correct that there are two fields in the ATA IDENTIFY. However,
> you are incorrect in thinking that all modern disks report their actual
> physical sector size instead of a 'compatibility' number. We have dozens
> of quirks and are adding them at the rate of a couple a month to make the
> current imperfect magic happen.
>
>> There is also a small quirks table for some older spinning disks and a
>> few SSDs that lie and mostly hasn't needed additions in quite some time.
>> camcontrol identify correctly reports 4096 for the physical sector size on 5
>> different random AF-512e disks I just checked (some of those are also,
>> redundantly, in the quirks table). Since this seems to have become the
>> standard, I can't imagine that the quirks table would need to grow much in
>> the future for this issue.
> Any yet the table continues to grow. As someone who evaluates disks for a large
> streaming media company, you cannot begin to imagine the number of things
> that vendors get wrong... Life would be so much easier if you could actually
> trust vendors to report things correctly in their ATA IDENTIFY command.
> SCSI is better, but still not perfect.
>
> You should really listen to people that have been on the front line here.
> CAM does a decent job of getting things right. It isn't perfect and can never
> be perfect. Expecting it to magically change to be perfect is unreasonable
> and will literally never happen.
>
> Warner
>

OK, so then what is the solution here? We have a number of tools that 
need to know this information: gpart, sade, bsdinstall, zfs, graid, etc. 
If we want to have a consistent set of defaults -- for example, to use 
4K across the board, which I think is a good idea -- there should be a 
central place to set this that does not involve hacking a variety of 
independent tools. Do you disagree?

I don't care how that happens. It happens that the way we currently 
encode this is geom stripesize. If we feel like we can't get this right 
in drivers, then we should provide a tunable to set a minimum default 
alignment. You could implement this in lots of different ways. But 
having static values hardcoded in random places that makes similar tools 
(sade, gpart) behave inconsistently cannot possibly be the answer.

This is my point, from beginning to end. Is there any reason -- at all 
-- that we should prefer per-tool one-off changes to fixing the central 
mechanism we already have to give consistent results that we think are 
reliable?
-Nathan