Date: Thu, 13 Feb 2014 01:51:48 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: AF-4Kn and DEV_BSIZE Message-ID: <CF216531.105B11%rpokala@panasas.com>
next in thread | raw e-mail | index | archive | help
Hi hackers,
At Panasas, we're working on supporting AF-4Kn drives (and also optimizing
for AF-512e drives while we're at it) in our legacy codebase, which is
based on:
7.2-RELEASE
- a bunch of drivers we don't need
- a bunch of utilities we don't use
+ a bunch of bug fixes merged from 7-STABLE
+ a bunch of drivers back-ported from {8,9,10}-STABLE
+ a bunch of internal changes
Since 7-STABLE doesn't support AF-4Kn, I'm looking at 10-STABLE for
inspiration.
We're only interested in SATA, so this basically breaks down into:
ata(4) / ad(4) [1]
GEOM [2]
General kernel stuff
I have a pretty good handle on the drivers and GEOM, but I'd like to
discuss the "General kernel stuff" bucket. Of particular concern is
DEV_BSIZE - and it's relatives: DEV_BSHIFT, btodb() and dbtob() - which
are used pretty much everywhere. A bunch of that is in places that don't
come anywhere near the drives, so I'm not worried about them. But when I
see those macros used in places that *do* come near the drives, I get
nervous. For example:
sys/kern/vfs_aio.c
sys/kern/vfs_bio.c
sys/kern/kern_physio.c
sys/vm/swap_pager.c
sys/vm/vnode_pager.c
Swapping, paging, and block IO all come near the drives.
On the one hand, the fact that we're doing things in terms of 512-byte
blocks all those places suggests that lots of stuff has to change to work
with 4KB drive blocks. On the other hand, when I compare the use of those
macros in our code base against what's in 10-STABLE, they are
substantively the same; since 10-STABLE supports AF-4Kn, that implies it's
okay to use those macros those ways. But I'm fuzzy on *how*, if we're
passing around 512-byte buffers, everything still works okay with AF-4Kn
drives.
Can someone shed some light?
Thanks,
Ravi
[1] The elephant in the room was the move from the old ATA driver to
ATACAM. Fortunately, the code in sys/cam/ata/ata_da.c::adaregister() that
maps from the logical and physical sector sizes detected from the drive,
to the more abstract 'struct disk' used by GEOM, is pretty easy to
understand and shoehorn into the 7-ish drivers. Once that's done and the
disk softc is carrying around the logical sector size, then a bunch of
places get changed to use that value instead of DEV_BSIZE. There are a few
other nits, but that's the bulk of the changes needed for ata(4) / ad(4).
[2] geom_disk.c::g_disk_create() copies 'struct disk's 'd_sectorsize' and
'd_stripesize' into the provider's 'sectorsize' and 'stripesize'. The rest
of the GEOM stack uses those correctly, so there aren't any real changes
required in GEOM. Hurray!
--rp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CF216531.105B11%rpokala>