From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 13 01:53:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE534125 for ; Thu, 13 Feb 2014 01:53:52 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id A4451153C for ; Thu, 13 Feb 2014 01:53:52 +0000 (UTC) Received: from seabiscuit.panasas.com (seabiscuit.panasas.com [172.17.132.204]) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id s1D1poEA017122 for ; Wed, 12 Feb 2014 20:51:50 -0500 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.01.0438.000; Wed, 12 Feb 2014 17:51:49 -0800 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: AF-4Kn and DEV_BSIZE Thread-Topic: AF-4Kn and DEV_BSIZE Thread-Index: AQHPKF4nznad8D6aXki/11oesZDAuw== Date: Thu, 13 Feb 2014 01:51:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [172.17.133.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:53:52 -0000 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