On 08/17/16 08:57, Warner Losh wrote:
On Wed, Aug 17, 2016 at 9:26 AM, Nathan Whitehorn
<nwhiteh...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
