From gd78059@sac.sfbay.sun.com Sun Nov 29 13:56:37 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nATLub9d010922 for ; Sun, 29 Nov 2009 13:56:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nATLuaSm018436; Sun, 29 Nov 2009 15:56:37 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTW00J014YC6F00@nwk-avmta-2.sfbay.sun.com>; Sun, 29 Nov 2009 13:56:36 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTW00FCZ4YCK370@nwk-avmta-2.sfbay.sun.com>; Sun, 29 Nov 2009 13:56:36 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nATLuYjT023322; Sun, 29 Nov 2009 13:56:34 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nATLuX3S010917; Sun, 29 Nov 2009 13:56:33 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nATLuXjC010913; Sun, 29 Nov 2009 13:56:33 -0800 (PST) Date: Sun, 29 Nov 2009 13:56:33 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com, James.McPherson@sun.com Message-id: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 12646 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: bd - generic block device driver 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 29 November, 2009 4. Technical Description Background ---------- There are a number of storage devices which express a simple block oriented architecture, but which are not truly SCSI devices. Examples of such devices are various flash media (e.g. SDcard, CF, and Memory Stick) and more recently storage adapters like the DDRdrive X1 (www.ddrdrive.com). These devices are not natively SCSI, and don't understand on their own the SCSI command set. As part of PSARC 2007/654, we introduced a translation layer (blk2scsa) which processes SCSI packets and allows these devices to be presented on a logical SCSI bus so that they can be supported by sd(7D). While this approach has so far met with some success, we've gained some experience and this approach has been found to add significant additional complexity to the system, with consequent impacts on performance, diagnosability, and maintainability. The action of creating a SCSI packet (done by sd(7d)) only to have to parse it in software later in the HBA is fairly inefficient. We therefore would like introduce a new block device driver (bd), to be used instead of blk2scsa, in order to simplify the system and increase total performance, with fewer total lines of supporting code. Because we might in the future like to offers support for some of these storage adapters on Solaris 10, we are requesting Patch binding, although we have no specific plans to backport at this time. Architecture ------------ The "bd" driver will be used as a block-oriented device driver for devices that need general block device support. Adapter device drivers will depend on this driver (-N drv/bd), and using functions supplied by it (described below in the "Block DDI", act as nexus drivers with bd leaves. bd itself supports labeling by importing the cmlb common labeling code, so these devices can support all of the same labeling conventions as magnetic SCSI disk devices. bd also supports the necessary dkio(7I) ioctls. Additionally, bd exports a new controller type in the dk_cinfo structure (used with DKIOCINFO), DKC_BD (#defined to value 24 in our current prototype, although this may change if the value is used by another project before we integrate). This new controller type is used to enable the use of a new plugin for libsmedia, sm_bd.so.1, which provides basic functionality for bd targets. bd has support for breaking large transfers up into smaller ones using partial DMA, or even for PIO style devices, so that adapter drivers need not concern themselves with this particular complexity. bd manages DMA mapping (if required) on behalf of the adapter driver, providing a scatter/gather list of DMA cookies to the driver as part of each job (if the adapter driver supports DMA.) Assumptions and Limitations --------------------------- bd targets may be hotpluggable, and may be removable. There is no support in this integration for door lock, media load, or ejection mechanisms. bd targets are assumed to have linear addressibility, and a fixed 512 byte block size. (Adapter drivers that require a different native block size may use read-modify-write if necessary.) bd is not optimized for rotating media. (sd, ssd, and cmdk are better suited to such media.) bd supports devices with an arbitrarily deep queue size, although the queue size itself is a fixed value determined at device registration. This allows for a very simple flow control model. bd provides no reprioritization. Jobs are submitted to the adapter device driver in the order received. However, they may be completed by the adapter driver in any order that is convenient for the adapter. bd lacks support for request cancellation. Once a job is submitted, it either completes or fails. bd lacks support for configurable timeouts. Once a job is submitted, it stays in the queue until it is serviced by the adapter driver. The adapter driver may elect to use a watchdog mechanism to provide timeouts at its own discretion. It is responsible for choosing an appropriate value for the timeout, if any is used. bd lacks any support in this integration for write cache management. If the adapter has a write cache, the adapter driver is wholly responsible for managing it "reasonably" and safely. bd assumes that if an adapter supports multiple bd targets, a simple integer index is sufficient to address each one. bd assumes the adapter driver will manage suspend/resume safely with respect to job submission. bd takes no special actions on suspend or resume -- that's up to the adapter driver to manage. bd assumes that adapter devices are able to manage their own power without the need for help from the framework. Since current bd media have neglible startup costs (no spin-up time), this is easy enough. (Although nothing prevents a driver with a higher startup cost from making use of the power(9e) framework to reduce thrashing on spin-up or spin-down.) The current prototype has an API for supporting hosting of crash dumps, but does not yet implement the dump(9e) support required. We may not get to doing this before integration. Consumers --------- Initially, the "bd" prototype will deliver with a separate driver for the DDRdrive X1 solid state storage device. That driver will be discussed in a separate PSARC case of its own which will depend on this case. As part of our prototype, we have also converted the SDcard memory card support to use bd instead of blk2scsa, which could potentially allow blk2scsa itself to be EOF'd. This effort will be discussed in a separate case as well, which will depend on this one. Block DDI --------- The following describes the DDI used by block device drivers. The following header must be included by all bd adapter drivers. #include The following type is exposed to adapter drivers, and represents an opaque handle for a bd_target device. typedef struct bd_handle *bd_handle_t; /* opaque */ Adapter driver entry points are supplied via the following structure: typedef struct bd_ops { int o_version; void (*o_drive_info)(void *, bd_drive_t *); int (*o_media_info)(void *, bd_media_t *); int (*o_read)(void *, bd_xfer_t *); int (*o_write)(void *, bd_xfer_t *); int (*o_dump)(void *, bd_xfer_t *); } bd_ops_t; This structure is supplied by the adapter during handle allocation (see bd_alloc_handle() below.) The o_version field must be set by the adapter to BD_OPS_VERSION_0, and may be used to support versioning of the DDI in the future. The o_drive_info() entry point describes the logical drive. The first argument (void *) is a pointer to the driver soft state supplied at handle allocation time. The second argument is a pointer to a structure with the following definition: struct bd_drive { uint32_t d_qsize; uint32_t d_maxxfer; uint64_t d_wwn; boolean_t d_removable; boolean_t d_hotpluggable; }; The d_qsize indicates the depth of the job request queue. The d_maxxfer, if non-zero, represents the largest transfer that can be processed by the device. The d_wwn, if non-zero, represents a SCSI-3 style WWN for use in creating a devid. The remaining elements describe the capabilities of the device. The o_media_info() entry point describes the current media in the drive. (Drives with non-removable media will always return the same values here.) The media description is a follows: typedef struct bd_media { uint64_t m_nblks; boolean_t m_readonly; } The m_nblks is the total number of addressable blocks for the media, and the m_readonly indicates a non-writable media if true. The o_read() and o_write() entry points are used to handle a read or write transfer. The o_read or o_write function returns either 0 on success, or an errno. If 0 is returned, then the adapter is responsible for calling bd_xfer_done() asynchronously when the transfer is finished (whether succesfully or not.) The adapter driver MAY NOT call bd_xfer_done() on a request if it returns an errno. The adapter driver MAY NOT call bd_xfer_done() synchronously from this function (else recursive lock entry will result.) The bd_xfer_t type has the following public members: typedef struct bd_xfer { daddr_t x_blkno; size_t x_nblks; ddi_dma_handle_t x_dmah; ddi_dma_cookie_t x_dmac; unsigned x_ndmac; caddr_t x_kaddr; } bd_xfer_t; The x_blkno is the logical block address that the transfer starts at, and the x_nblks member is the total number of blocks to be transfered (it will always be a positive value.) If the device supports DMA, the x_dmah, x_dmac, and x_ndmac describe the DMA transfer. If x_ndmac is larger than 1, then the adapter driver must use ddi_dma_nextcookie(9f) to obtain the DMA cookie for the next entry in the scatter/gather list. If the adapter device does not support DMA, the x_kaddr is the kernel virtual address for the transfer. The o_dump() entry point is used to write blocks to a disk synchronously, in support of dump(9e). It may not block or use interrupts, and may not call bd_xfer_done(). Instead, it simply returns 0 or an errno when the transfer is complete. The following functions may be called by the adapter driver: bd_handle_t bd_alloc_handle(dev_info_t *dip, unsigned addr, void *private, bd_ops_t *ops, ddi_dma_attr_t *attr); Allocates a handle for a target bd device. The dip is for the adapter device (parent). The addr is the address or index of the bd target on the adapter. (Adapters that only support single targets should probably supply 0 here.) The private is a pointer to driver state that is supplied to the entry points in the ops vector. The attr describes the DMA capabilities of the adapter (for transfers). If the adapter driver does not use DMA, then NULL may be supplied for attr. This function may be called in user or kernel context only. void bd_free_handle(bd_handle_t handle); Frees a previously allocated handle. Note that it is an error to free a handle that is attached. May be called in user or kernel context only. int bd_attach_handle(bd_handle_t handle); Attaches a handle, creating a node in the device tree for the bd target device, and attaching its driver. Returns DDI_SUCCESS on success or DDI_FAILURE on failure. May be called in user or kernel context only. int bd_detach_handle(bd_handle_t handle); Detaches a handle from the system, normally as part of a DDI_DETACH operation or as part of a hotplug operation. Returns DDI_SUCCESS on success or DDI_FAILURE on failure. May be called in user or kernel context only. void bd_state_change(bd_handle_t handle); Indicates a state change (media removal or insertion) occurred for the given handle. Only useful for removable media. May be called in kernel, user, or interrupt context. Caller must not hold any locks. void bd_xfer_done(bd_xfer_t *xfer, int result); Called by the adapter when the named transfer (xfer) is complete. The result is 0 for a successful transfer, or an errno if the transfer failed. May be called in kernel, user, or interrupt context. Caller must not hold any locks. void bd_mod_init(struct dev_ops *); void bd_mod_fini(struct dev_ops *); Called by the adapter driver to configure its dev_ops structure during _init(9e), or to deconfigure it during _fini(9e). Imported Interfaces ------------------- Interface Stability Comments cmlb Consolidation Private Disk labelling support. Includes the misc/cmlb module and the cmlb API. nexus NDI Consolidation Private Needed for nexus device support. libsmedia Consolidation Private Generic storage media library, we import interfaces to supply a plugin. Exported Interfaces ------------------- bd(7d) Committed bd device driver. dkio(7I) Committed Standard ioctls for disks. DKC_BD Committed New dkio controller type. Block DDI Consolidation Private Used by adapter drivers. See Block DDI above. sm_bd.so.1 Consolidation Private libsmedia plugin. Both 32 and 64-bit versions. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Alan.Coopersmith@sun.com Sun Nov 29 22:57:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAU6v5ex017039 for ; Sun, 29 Nov 2009 22:57:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAU6v4mi029531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 29 Nov 2009 22:57:05 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTW0010FTZ4ZC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 29 Nov 2009 23:57:04 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTW009Z3TZ3ISE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 29 Nov 2009 23:57:03 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAU6v3mT023143 for ; Sun, 29 Nov 2009 22:57:03 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTW00500TYGOZ00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 29 Nov 2009 22:57:03 -0800 (PST) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTW003X6TZ2Q200@fe-sfbay-09.sun.com>; Sun, 29 Nov 2009 22:57:02 -0800 (PST) Date: Sun, 29 Nov 2009 22:57:02 -0800 From: Alan Coopersmith Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, James.McPherson@sun.com Message-id: <4B136CBE.9060301@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 833 Garrett D'Amore - sun microsystems wrote: > The "bd" driver will be used as a block-oriented device driver for devices > that need general block device support. > Because we might in the future like to offers support for some of > these storage adapters on Solaris 10, we are requesting Patch binding, > although we have no specific plans to backport at this time. "bd" is an unfortunate driver name as a very very different bd driver shipped with SunOS 4 through Solaris 10, for the ancient SunButtons & SunDials input devices. (See bd(7M) on a Solaris 10 or older system.) While that wouldn't be a stopper on Nevada (though it might be confusing to those who upgrade), it would seem to block backporting to S10. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Garrett.Damore@sun.com Mon Nov 30 00:02:39 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAU82d4p010648 for ; Mon, 30 Nov 2009 00:02:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAU82HNb008678 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 30 Nov 2009 02:02:38 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTW00I01X03US00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Nov 2009 00:02:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTW00K06X023JD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Nov 2009 00:02:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAU82QW0026512 for ; Mon, 30 Nov 2009 00:02:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTW00200WW31I00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Nov 2009 00:02:26 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTW003Q4X02Q290@fe-sfbay-09.sun.com>; Mon, 30 Nov 2009 00:02:26 -0800 (PST) Date: Mon, 30 Nov 2009 00:02:25 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B136CBE.9060301@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, James.McPherson@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B137C11.7050801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1252 Alan Coopersmith wrote: > Garrett D'Amore - sun microsystems wrote: > >> The "bd" driver will be used as a block-oriented device driver for devices >> that need general block device support. >> Because we might in the future like to offers support for some of >> these storage adapters on Solaris 10, we are requesting Patch binding, >> although we have no specific plans to backport at this time. >> > > "bd" is an unfortunate driver name as a very very different bd driver shipped > with SunOS 4 through Solaris 10, for the ancient SunButtons & SunDials input > devices. (See bd(7M) on a Solaris 10 or older system.) > > While that wouldn't be a stopper on Nevada (though it might be confusing to > those who upgrade), it would seem to block backporting to S10. > > Wow, not sure how I missed that! I'll change the name... the kernel module name will change "blkdev". However all other symbols and names will remain unchanged. (I should have figured it was too easy to use a two character name here! :-p ) (If people are really bothered by this, I could also change the name to "gbd" -- for "generic block device", and change the symbols to gbd_xx and DKC_GBD. I'm disclined to do that at the moment, however.) -- Garrett From gdamore@sun.com Tue Dec 1 23:57:59 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB27vxIN025314 for ; Tue, 1 Dec 2009 23:57:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB27vvO0062097 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 00:57:58 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU00040NM4MI800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 23:57:58 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU00046MM4M9M00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 23:57:58 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB27vwl4005124 for ; Tue, 01 Dec 2009 23:57:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU000900M0M8500@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 23:57:58 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU000LTZM4LV140@fe-sfbay-09.sun.com>; Tue, 01 Dec 2009 23:57:57 -0800 (PST) Date: Tue, 01 Dec 2009 23:57:57 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B137C11.7050801@sun.com> Sender: Garrett.Damore@sun.com To: Garrett.Damore@sun.com Cc: Alan Coopersmith , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, James.McPherson@sun.com Message-id: <4B161E05.7060409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1643 Garrett D'Amore wrote: > Alan Coopersmith wrote: >> Garrett D'Amore - sun microsystems wrote: >> >>> The "bd" driver will be used as a block-oriented device driver for >>> devices >>> that need general block device support. >>> Because we might in the future like to offers support for some of >>> these storage adapters on Solaris 10, we are requesting Patch binding, >>> although we have no specific plans to backport at this time. >>> >> >> "bd" is an unfortunate driver name as a very very different bd driver >> shipped >> with SunOS 4 through Solaris 10, for the ancient SunButtons & >> SunDials input >> devices. (See bd(7M) on a Solaris 10 or older system.) >> >> While that wouldn't be a stopper on Nevada (though it might be >> confusing to >> those who upgrade), it would seem to block backporting to S10. >> >> > > Wow, not sure how I missed that! > > I'll change the name... the kernel module name will change "blkdev". > However all other symbols and names will remain unchanged. (I should > have figured it was too easy to use a two character name here! :-p ) > > (If people are really bothered by this, I could also change the name > to "gbd" -- for "generic block device", and change the symbols to > gbd_xx and DKC_GBD. I'm disclined to do that at the moment, however.) Okay, in my current prototype the new name is "blkdev", and I've also changed "sm_bd.so" to "sm_blkdev.so". I left DKC_BD as is, and the functions and types documented here still start with "bd_" for brevity. Hopefully I'll get a +1 on this case. (Right now the stuff in my proto area is looking rock solid.) - Garrett From Darren.Moffat@Sun.COM Wed Dec 2 01:31:03 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB29V2tQ010040 for ; Wed, 2 Dec 2009 01:31:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB29V2wr004287 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 03:31:02 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU000H01QFQG900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 02:31:02 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU0001LPQFP1YA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 02:31:02 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB29V0Ub022901 for ; Wed, 02 Dec 2009 09:31:01 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU000D00POJ8M00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 09:30:51 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU000L9LQF1HC30@fe-emea-09.sun.com>; Wed, 02 Dec 2009 09:30:37 +0000 (GMT) Date: Wed, 02 Dec 2009 09:30:36 +0000 From: Darren J Moffat Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B161E05.7060409@sun.com> Sender: Darren.Moffat@Sun.COM To: "Garrett D'Amore" Cc: Garrett.Damore@Sun.COM, PSARC-ext@Sun.COM, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Message-id: <4B1633BC.7050403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 246 With the updated name I have only one possible small issue. You said the driver is hardcoded to 512 byte blocks, yet the industry is moving towards 4k blocks. Is that likely to be an issue for devices driven by 'blkdev' ? -- Darren J Moffat From olga.kryzhanovska@gmail.com Wed Dec 2 05:56:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2DuACV014275 for ; Wed, 2 Dec 2009 05:56:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2Du8Ir027050; Wed, 2 Dec 2009 05:56:08 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100L0D2PKXE00@brm-avmta-1.central.sun.com>; Wed, 02 Dec 2009 06:56:08 -0700 (MST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU1001182PJVVB0@brm-avmta-1.central.sun.com>; Wed, 02 Dec 2009 06:56:07 -0700 (MST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB2DktU7014373; Wed, 02 Dec 2009 13:56:06 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-7987372; Wed, 02 Dec 2009 13:56:06 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-105972438; Wed, 02 Dec 2009 13:56:06 +0000 (Z) Received: from mail-fx0-f220.google.com ([209.85.220.220] [209.85.220.220]) by relay1i.sun.com with ESMTP id BT-MMP-9323621; Wed, 02 Dec 2009 13:56:06 +0000 (Z) Received: by fxm20 with SMTP id 20so419671fxm.35 for ; Wed, 02 Dec 2009 05:55:55 -0800 (PST) Received: by 10.223.4.214 with SMTP id 22mr22147fas.34.1259762155706; Wed, 02 Dec 2009 05:55:55 -0800 (PST) Date: Wed, 02 Dec 2009 14:55:55 +0100 From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B1633BC.7050403@Sun.COM> To: Darren J Moffat Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" , Garrett.Damore@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=j/wLgQD+YWsOLiAqICqEzbh3zRfK07xnYOHPsFDWU7o=; b=lrpEnpuKYi4+LbFIQ4Pl+kZIn+l32dHVJm7q3glOjvyZ9ZE2WsNSiNE01VNV/gqWQ2 zGD3zRvDPPh7eyT47M5ZSjLxcijQw8fx5ufCDCTMOWgftxXOXL+zDMAMDrPthUrWzIf8 WEDYqDFhGP5KgfHwhZSWDOu6RtBq72ZxF9Ky0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iBnbVDP2bOC34O1QCl/oqZ+ZDEvepWgVRErxYIavjQ4peisawfXuN0nKwlnLj+/jcl 1yTRYojATWGvVtsSnSccl4LgUFq/XIjRAp6TwSB05mZ3hi1p+DweF30I3xVO8/J+EdbK J2ZlEkiif5WVdmQwb5jd62nrMQoDPdUZ1+0P0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> Status: RO Content-Length: 909 I believe this a large issue. Not all devices support 512 byte blocks or have a block size which is a multiple of 512. On Wed, Dec 2, 2009 at 10:30 AM, Darren J Moffat wrote: > With the updated name I have only one possible small issue. > > You said the driver is hardcoded to 512 byte blocks, yet the industry is > moving towards 4k blocks. Is that likely to be an issue for devices driven > by 'blkdev' ? > > -- > Darren J Moffat > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From gdamore@sun.com Wed Dec 2 07:52:18 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2FqIbP017119 for ; Wed, 2 Dec 2009 07:52:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2FqBlw001760 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 07:52:17 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100A0V8353U00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:52:17 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU10054P82TVN40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:52:06 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2Fq5qN018395 for ; Wed, 02 Dec 2009 07:52:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU10060081IBY00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 07:52:05 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU10010Y82TXT90@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 07:52:05 -0800 (PST) Date: Wed, 02 Dec 2009 07:52:04 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B1633BC.7050403@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Message-id: <4B168D24.9080808@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 767 Darren J Moffat wrote: > With the updated name I have only one possible small issue. > > You said the driver is hardcoded to 512 byte blocks, yet the industry > is moving towards 4k blocks. Is that likely to be an issue for > devices driven by 'blkdev' ? I don't think so. If the application (or other code) issues smaller I/Os, the underlying driver will have to implement as RMW. If the filesystem or app code uses 4K aligned and sized buffers, then there won't be a need to do RMW. We might need to change the code slightly to express the 4K size in the various ioctls, but that can happen latter when I run into such a device. (The current devices supported by this device driver all use 512 byte blocks.) - Garrett > > -- > Darren J Moffat From Darren.Moffat@sun.com Wed Dec 2 07:56:50 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2FuovT017486 for ; Wed, 2 Dec 2009 07:56:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2Fumju011155 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 07:56:50 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100A238APMX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:56:49 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU1005KF8AOVU50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:56:49 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2FuknY022590 for ; Wed, 02 Dec 2009 15:56:48 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU1002006HKNC00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 15:56:40 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU100HN78A81LB0@fe-emea-09.sun.com>; Wed, 02 Dec 2009 15:56:33 +0000 (GMT) Date: Wed, 02 Dec 2009 15:56:32 +0000 From: Darren J Moffat Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B168D24.9080808@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Message-id: <4B168E30.90009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 1033 Garrett D'Amore wrote: > Darren J Moffat wrote: >> With the updated name I have only one possible small issue. >> >> You said the driver is hardcoded to 512 byte blocks, yet the industry >> is moving towards 4k blocks. Is that likely to be an issue for >> devices driven by 'blkdev' ? > > I don't think so. If the application (or other code) issues smaller > I/Os, the underlying driver will have to implement as RMW. If the > filesystem or app code uses 4K aligned and sized buffers, then there > won't be a need to do RMW. I understood how that side would work. > We might need to change the code slightly to express the 4K size in the > various ioctls, but that can happen latter when I run into such a > device. (The current devices supported by this device driver all use > 512 byte blocks.) My concern is when there are devices that use 4K size blocks instead of 512 byte blocks. Is there anything in the architecture of bd that means they can't easily be supported by this bd driver ? -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Dec 2 08:06:13 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2G6C0Y017693 for ; Wed, 2 Dec 2009 08:06:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2G69wV018297 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 08:06:12 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU10091F8QCDE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:06:12 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU1004YN8QBYH10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:06:11 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB2G08kP022224 for ; Wed, 02 Dec 2009 16:06:11 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-3712849 for PSARC-ext@sun.com; Wed, 02 Dec 2009 16:06:10 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-106131770 for PSARC-ext@sun.com; Wed, 02 Dec 2009 16:06:10 +0000 (Z) Received: from relay01-muc.antispameurope.com ([217.64.175.51] [217.64.175.51]) by relay1i.sun.com with ESMTP id BT-MMP-9499427 for PSARC-ext@sun.com; Wed, 02 Dec 2009 16:05:59 +0000 (Z) Received: by relay01-muc.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 2D229254410; Wed, 02 Dec 2009 17:05:58 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-muc.antispameurope.com (ASE-Secure-MTA) with ESMTP id 45B5A254410; Wed, 02 Dec 2009 17:05:56 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nB2G5uh9015897; Wed, 02 Dec 2009 17:05:56 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 02 Dec 2009 17:05:56 +0100 Date: Wed, 02 Dec 2009 17:05:56 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B168E30.90009@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: gdamore@sun.com, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4b169064.lyZ0QBmnDhYMD6ms%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 02 Dec 2009 16:05:56.0214 (UTC) FILETIME=[54A1F160:01CA7369] Status: RO Content-Length: 1217 Darren J Moffat wrote: > > We might need to change the code slightly to express the 4K size in the > > various ioctls, but that can happen latter when I run into such a > > device. (The current devices supported by this device driver all use > > 512 byte blocks.) > > My concern is when there are devices that use 4K size blocks instead of > 512 byte blocks. Is there anything in the architecture of bd that means > they can't easily be supported by this bd driver ? What about "odd" (in this case not really odd numbers) sector sizes that are used on CDs (2336, 2448, 2352)? What about the 64k physical sector size on BluRay media? Note that we currently cannot set up a 64k transfer with USCSI on all underlying transports. DVDs and BluRays support "logical" sector sizes of 2048 bytes but this will not work with all constraints as there sometimes is a need for aligned transfers. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From gdamore@sun.com Wed Dec 2 08:29:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2GTeI3018138 for ; Wed, 2 Dec 2009 08:29:40 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2GTVSc005000 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 08:29:39 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU1000019TEVI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:29:38 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100LD49TD6140@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:29:37 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2GTbIr021862 for ; Wed, 02 Dec 2009 08:29:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU1002009KMCM00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:29:37 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1005FQ9T9RD10@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 08:29:34 -0800 (PST) Date: Wed, 02 Dec 2009 08:29:33 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4b169064.lyZ0QBmnDhYMD6ms%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4B1695ED.3040306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4b169064.lyZ0QBmnDhYMD6ms%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1511 Joerg Schilling wrote: > Darren J Moffat wrote: > > >>> We might need to change the code slightly to express the 4K size in the >>> various ioctls, but that can happen latter when I run into such a >>> device. (The current devices supported by this device driver all use >>> 512 byte blocks.) >>> >> My concern is when there are devices that use 4K size blocks instead of >> 512 byte blocks. Is there anything in the architecture of bd that means >> they can't easily be supported by this bd driver ? >> > > What about "odd" (in this case not really odd numbers) sector sizes that > are used on CDs (2336, 2448, 2352)? > > What about the 64k physical sector size on BluRay media? Note that we currently > cannot set up a 64k transfer with USCSI on all underlying transports. > > DVDs and BluRays support "logical" sector sizes of 2048 bytes but this will > not work with all constraints as there sometimes is a need for aligned > transfers. > My intent is not that blkdev be the solution for all possible media. Specifically, it is *not* designed for spinning media. Those weird (non-power-of-two) sector sizes are not relevant. blkdev does not support USCSI at all, because its not a SCSI transport. Its for devices that don't support the SCSI command set at all. Devices like the ones you mention already are handled by "sd", and are responsible for a lot of the complexity in sd that I'm hoping to avoid in blkdev. -- Garrett > Jörg > > From gdamore@Sun.COM Wed Dec 2 08:34:26 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2GYQO8018306 for ; Wed, 2 Dec 2009 08:34:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2GYOqm010575 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 08:34:26 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100E03A1D6700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:34:25 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU10040HA1DYK40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:34:25 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2GYPHI022274 for ; Wed, 02 Dec 2009 08:34:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU1009009VPG200@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:34:25 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1007O4A1C6B90@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 08:34:25 -0800 (PST) Date: Wed, 02 Dec 2009 08:34:24 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B168E30.90009@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Darren J Moffat Cc: Garrett.Damore@Sun.COM, PSARC-ext@Sun.COM, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Message-id: <4B169710.9010004@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2019 Okay, I'm going to propose solving this properly. The solution is that the following structure: struct bd_media { uint64_t m_nblks; boolean_t m_readonly; }; Will grow a new member expressing the block size: struct bd_media { uint64_t m_nblks; uint32_t m_blksize; boolean_t m_readonly; }; *However*, in order to keep things simple and efficient in the code, the rule is that the blksize *must* be a power of two. If the block size is not a power of two, then the driver will have to do the RMW thing to fake one up. (With the associated performance penalties.) This should allow non-spinning media to work fine with blkdev, even with larger block sizes. Note that I can only test 512 byte blocks, so architecturally the solution will be complete, but the resulting code *may* have bugs that I won't know about until we have media with larger block size requirements. - Garrett Darren J Moffat wrote: > Garrett D'Amore wrote: >> Darren J Moffat wrote: >>> With the updated name I have only one possible small issue. >>> >>> You said the driver is hardcoded to 512 byte blocks, yet the >>> industry is moving towards 4k blocks. Is that likely to be an issue >>> for devices driven by 'blkdev' ? >> >> I don't think so. If the application (or other code) issues smaller >> I/Os, the underlying driver will have to implement as RMW. If the >> filesystem or app code uses 4K aligned and sized buffers, then there >> won't be a need to do RMW. > > I understood how that side would work. > >> We might need to change the code slightly to express the 4K size in >> the various ioctls, but that can happen latter when I run into such a >> device. (The current devices supported by this device driver all use >> 512 byte blocks.) > > My concern is when there are devices that use 4K size blocks instead > of 512 byte blocks. Is there anything in the architecture of bd that > means they can't easily be supported by this bd driver ? > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Dec 2 08:40:13 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2GeCoH018787 for ; Wed, 2 Dec 2009 08:40:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2GeAZJ029978 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 08:40:12 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU10011LAB0FB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Dec 2009 08:40:12 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100LM5AAY6150@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Dec 2009 08:40:10 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB2GUp4C020842 for ; Wed, 02 Dec 2009 16:40:10 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-1818171 for PSARC-ext@Sun.COM; Wed, 02 Dec 2009 16:40:09 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-79417151 for PSARC-ext@Sun.COM; Wed, 02 Dec 2009 16:40:09 +0000 (Z) Received: from relay02-muc.antispameurope.com ([217.64.175.52] [217.64.175.52]) by relay4i.sun.com with ESMTP id BT-MMP-35958763 for PSARC-ext@Sun.COM; Wed, 02 Dec 2009 16:40:09 +0000 (Z) Received: by relay02-muc.antispameurope.com (ASE-Secure-MTA, from userid 1000) id C92942D054F; Wed, 02 Dec 2009 17:40:08 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-muc.antispameurope.com (ASE-Secure-MTA) with ESMTP id 14E522D054F; Wed, 02 Dec 2009 17:40:07 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nB2Ge6R8016915; Wed, 02 Dec 2009 17:40:06 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 02 Dec 2009 17:40:06 +0100 Date: Wed, 02 Dec 2009 17:40:06 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B169710.9010004@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: gdamore@sun.com, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4b169866.Zaok3PgsfN57JpJ9%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.075sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 02 Dec 2009 16:40:06.0631 (UTC) FILETIME=[1AC6BF70:01CA736E] Status: RO Content-Length: 825 "Garrett D'Amore" wrote: > Okay, I'm going to propose solving this properly. The solution is that > the following structure: > > struct bd_media { > uint64_t m_nblks; > boolean_t m_readonly; > }; > > Will grow a new member expressing the block size: > > struct bd_media { > uint64_t m_nblks; > uint32_t m_blksize; > boolean_t m_readonly; > }; the structure content looks OK, but I and many other people will read "bd_media" as BluRay-Disk Media..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Wed Dec 2 08:40:42 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2GefSH018839 for ; Wed, 2 Dec 2009 08:40:42 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB2GecW7004423 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 09:40:41 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU10011FABSGL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:40:40 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100LQGABR5T40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 08:40:40 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2GedEn028367 for ; Wed, 02 Dec 2009 16:40:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100H009B7Y100@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 16:40:26 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU100MV5AB75HD0@fe-emea-10.sun.com>; Wed, 02 Dec 2009 16:40:19 +0000 (GMT) Date: Wed, 02 Dec 2009 16:40:19 +0000 From: Darren J Moffat Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B169710.9010004@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Message-id: <4B169873.7080904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 456 Garrett D'Amore wrote: > Okay, I'm going to propose solving this properly. The solution is that > the following structure: > > struct bd_media { > uint64_t m_nblks; > boolean_t m_readonly; > }; > > Will grow a new member expressing the block size: > > struct bd_media { > uint64_t m_nblks; > uint32_t m_blksize; > boolean_t m_readonly; > }; I'm happy to give the case a +1 now. -- Darren J Moffat From Neal.Pollack@sun.com Wed Dec 2 09:04:10 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2H4Ato020166 for ; Wed, 2 Dec 2009 09:04:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2H49GF028635 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 11:04:09 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU10020HBEXQ300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 09:04:09 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100L2UBEW5V90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 09:04:08 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2H43fr023922 for ; Wed, 02 Dec 2009 09:04:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100C00ANHI200@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 09:04:03 -0800 (PST) Received: from [10.1.48.130] ([unknown] [10.1.48.130]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1007KRBEQ7Y50@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 09:04:03 -0800 (PST) Date: Wed, 02 Dec 2009 09:04:02 -0800 From: Neal Pollack Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4b169866.Zaok3PgsfN57JpJ9%Joerg.Schilling@fokus.fraunhofer.de> Sender: Neal.Pollack@sun.com To: Joerg Schilling Cc: gdamore@sun.com, Darren.Moffat@sun.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4B169E02.4040109@Sun.Com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mSCysVKYzrZj7hVBVVPBWw)" X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> <4b169866.Zaok3PgsfN57JpJ9%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 2616 This is a multi-part message in MIME format. --Boundary_(ID_mSCysVKYzrZj7hVBVVPBWw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT On 12/ 2/09 08:40 AM, Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >> Okay, I'm going to propose solving this properly. The solution is that >> the following structure: >> >> struct bd_media { >> uint64_t m_nblks; >> boolean_t m_readonly; >> }; >> >> Will grow a new member expressing the block size: >> >> struct bd_media { >> uint64_t m_nblks; >> uint32_t m_blksize; >> boolean_t m_readonly; >> }; >> > > the structure content looks OK, but I and many other people > will read "bd_media" as BluRay-Disk Media..... > agreed. bd_anything is commonly understood in the industry to apply to bluray. I am not a voting member, but give the case a silent +1 if the structure name can be anything else :-) > Jörg > > --Boundary_(ID_mSCysVKYzrZj7hVBVVPBWw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 12/ 2/09 08:40 AM, Joerg Schilling wrote: 
"Garrett D'Amore" <gdamore@Sun.COM> wrote:

  
Okay, I'm going to propose solving this properly.  The solution is that 
the following structure:

struct bd_media {
    uint64_t        m_nblks;
    boolean_t        m_readonly;
};

Will grow a new member expressing the block size:

struct bd_media {
    uint64_t        m_nblks;
    uint32_t         m_blksize;
    boolean_t        m_readonly;
};
    

the structure content looks OK, but I and many other people
will read "bd_media" as BluRay-Disk Media.....

agreed.   bd_anything is commonly understood in the industry
to apply to bluray.

I am not a voting member, but give the case a silent +1 if
the structure name can be anything else :-)


Jörg

--Boundary_(ID_mSCysVKYzrZj7hVBVVPBWw)-- From gdamore@sun.com Wed Dec 2 09:38:22 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2HcMQs021770 for ; Wed, 2 Dec 2009 09:38:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB2HcLOx053208 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 10:38:21 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100K01CZXRM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 10:38:21 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100IM6CZXQN10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 10:38:21 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2HcKrX029165 for ; Wed, 02 Dec 2009 09:38:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100800CYOZC00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 09:38:20 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1003ZBCZV8N10@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 09:38:20 -0800 (PST) Date: Wed, 02 Dec 2009 09:38:19 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B169E02.4040109@Sun.Com> Sender: Garrett.Damore@sun.com To: Neal Pollack Cc: Joerg Schilling , Darren.Moffat@sun.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4B16A60B.2000202@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> <4b169866.Zaok3PgsfN57JpJ9%Joerg.Schilling@fokus.fraunhofer.de> <4B169E02.4040109@Sun.Com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1112 Neal Pollack wrote: > On 12/ 2/09 08:40 AM, Joerg Schilling wrote: >> "Garrett D'Amore" wrote: >> >> >>> Okay, I'm going to propose solving this properly. The solution is that >>> the following structure: >>> >>> struct bd_media { >>> uint64_t m_nblks; >>> boolean_t m_readonly; >>> }; >>> >>> Will grow a new member expressing the block size: >>> >>> struct bd_media { >>> uint64_t m_nblks; >>> uint32_t m_blksize; >>> boolean_t m_readonly; >>> }; >>> >> >> the structure content looks OK, but I and many other people >> will read "bd_media" as BluRay-Disk Media..... >> > > agreed. bd_anything is commonly understood in the industry > to apply to bluray. > > I am not a voting member, but give the case a silent +1 if > the structure name can be anything else :-) The structure isn't used anywhere where I believe this confusion is likely to be an issue. Specifically, it is only exchanged between the "blkdev" framework, and blkdev adapter drivers. Neither of these have anything to do with bluray. - Garrett From olga.kryzhanovska@gmail.com Wed Dec 2 12:52:45 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2Kqjel028842 for ; Wed, 2 Dec 2009 12:52:45 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2KqgDs022925; Wed, 2 Dec 2009 14:52:43 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100F0DLZVNJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Dec 2009 12:52:43 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100ESFLZUU660@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Dec 2009 12:52:42 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2KqfGP020039; Wed, 02 Dec 2009 20:52:41 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay41i.sun.com with ESMTP id BT-MMP-1841598; Wed, 02 Dec 2009 20:52:26 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-79646092; Wed, 02 Dec 2009 20:52:25 +0000 (Z) Received: from mail-fx0-f220.google.com ([209.85.220.220] [209.85.220.220]) by relay4i.sun.com with ESMTP id BT-MMP-4754019; Wed, 02 Dec 2009 20:52:25 +0000 (Z) Received: by fxm20 with SMTP id 20so1121616fxm.35 for ; Wed, 02 Dec 2009 12:52:17 -0800 (PST) Received: by 10.223.6.137 with SMTP id 9mr101360faz.60.1259787137595; Wed, 02 Dec 2009 12:52:17 -0800 (PST) Date: Wed, 02 Dec 2009 21:52:17 +0100 From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B169710.9010004@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" , Garrett.Damore@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5DGK4lsjb6fYQ0nk3Y2OcQIe9wEbJir7LDxC80Z/wYk=; b=u0GDq3kiUVKtQfm7jny2DRi8Sbru0pWeJtn1h+rE/pNrv25fDbTNiJ3CciI14FGf4V ed5eQuL/2pz/q73eTKzLGrWF7nGneBBrFnp6a71Mhoi/Nq3+myBIh1OBOwvDGBo/wYk2 tO65FmtSgk05dlVF4KV47eNTHxQ72qVtBi5EU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CyeZ4d5F2NrRClUPpZNs8t2HxWdosISo/G41945AK90jTQNIOxl1XstYuYVfA2Jmpv VXkYMUMA2g0IfzA88R/A9A4/MmGYwJI2pEGSxgz5Wckm+Zxi0AwzeVw1kVsNGL111QGa eIbYaNzq8WVGPKHBMKak8qwle/ISTmuz7acPo= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> Status: RO Content-Length: 2799 Why is m_blksize unsigned 32bit? Do you want to repeat the story of '640KB are enough'? Please make m_blksize an uint64 for the sake of future users who want to address more than 4GB as block. On Wed, Dec 2, 2009 at 5:34 PM, Garrett D'Amore wrote: > Okay, I'm going to propose solving this properly. The solution is that the > following structure: > > struct bd_media { > uint64_t m_nblks; > boolean_t m_readonly; > }; > > Will grow a new member expressing the block size: > > struct bd_media { > uint64_t m_nblks; > uint32_t m_blksize; > boolean_t m_readonly; > }; > > *However*, in order to keep things simple and efficient in the code, the > rule is that the blksize *must* be a power of two. If the block size is not > a power of two, then the driver will have to do the RMW thing to fake one > up. (With the associated performance penalties.) > > This should allow non-spinning media to work fine with blkdev, even with > larger block sizes. > > Note that I can only test 512 byte blocks, so architecturally the solution > will be complete, but the resulting code *may* have bugs that I won't know > about until we have media with larger block size requirements. > > - Garrett > > Darren J Moffat wrote: >> >> Garrett D'Amore wrote: >>> >>> Darren J Moffat wrote: >>>> >>>> With the updated name I have only one possible small issue. >>>> >>>> You said the driver is hardcoded to 512 byte blocks, yet the industry is >>>> moving towards 4k blocks. Is that likely to be an issue for devices driven >>>> by 'blkdev' ? >>> >>> I don't think so. If the application (or other code) issues smaller >>> I/Os, the underlying driver will have to implement as RMW. If the >>> filesystem or app code uses 4K aligned and sized buffers, then there won't >>> be a need to do RMW. >> >> I understood how that side would work. >> >>> We might need to change the code slightly to express the 4K size in the >>> various ioctls, but that can happen latter when I run into such a device. >>> (The current devices supported by this device driver all use 512 byte >>> blocks.) >> >> My concern is when there are devices that use 4K size blocks instead of >> 512 byte blocks. Is there anything in the architecture of bd that means >> they can't easily be supported by this bd driver ? >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From gdamore@Sun.COM Wed Dec 2 14:40:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2MeJjp001519 for ; Wed, 2 Dec 2009 14:40:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB2MeILG011881 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 15:40:19 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU10040JQZ6J700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 15:40:18 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100E0LQZ47380@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 15:40:16 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2MeGm6003958 for ; Wed, 02 Dec 2009 14:40:16 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100600QRDAG00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 14:40:16 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU100CU2QZ3DDE0@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 14:40:16 -0800 (PST) Date: Wed, 02 Dec 2009 14:40:15 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: Sender: Garrett.Damore@Sun.COM To: =?UTF-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= Cc: Darren J Moffat , PSARC-ext@Sun.COM, Alan Coopersmith , "Garrett D'Amore - sun microsystems" , Garrett.Damore@Sun.COM Message-id: <4B16ECCF.1000604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 3251 Š¾Š»ŃŒŠ³Š° ŠŗрыŠ¶Š°Š½Š¾Š²ŃŠŗŠ°Ń wrote: > Why is m_blksize unsigned 32bit? > Do you want to repeat the story of '640KB are enough'? > Please make m_blksize an uint64 for the sake of future users who want > to address more than 4GB as block. > The block size is the minimum addressable unit of data. It is *not* the maximum address. In fact, with the way this is specified, you could in theory describe a device capable of storing 2^92 bytes of data. Although to achieve that, you'd have to use 4GB blocks. The largest block size in any common use today is 64K, which is far far short of 4GB. If you had a 4GB block size, then you would *have* to transfer full 4GB just to do a minimum read. I don't think any such devices are likely within the next decade or three. (Maybe not ever.) - Garrett > On Wed, Dec 2, 2009 at 5:34 PM, Garrett D'Amore wrote: > >> Okay, I'm going to propose solving this properly. The solution is that the >> following structure: >> >> struct bd_media { >> uint64_t m_nblks; >> boolean_t m_readonly; >> }; >> >> Will grow a new member expressing the block size: >> >> struct bd_media { >> uint64_t m_nblks; >> uint32_t m_blksize; >> boolean_t m_readonly; >> }; >> >> *However*, in order to keep things simple and efficient in the code, the >> rule is that the blksize *must* be a power of two. If the block size is not >> a power of two, then the driver will have to do the RMW thing to fake one >> up. (With the associated performance penalties.) >> >> This should allow non-spinning media to work fine with blkdev, even with >> larger block sizes. >> >> Note that I can only test 512 byte blocks, so architecturally the solution >> will be complete, but the resulting code *may* have bugs that I won't know >> about until we have media with larger block size requirements. >> >> - Garrett >> >> Darren J Moffat wrote: >> >>> Garrett D'Amore wrote: >>> >>>> Darren J Moffat wrote: >>>> >>>>> With the updated name I have only one possible small issue. >>>>> >>>>> You said the driver is hardcoded to 512 byte blocks, yet the industry is >>>>> moving towards 4k blocks. Is that likely to be an issue for devices driven >>>>> by 'blkdev' ? >>>>> >>>> I don't think so. If the application (or other code) issues smaller >>>> I/Os, the underlying driver will have to implement as RMW. If the >>>> filesystem or app code uses 4K aligned and sized buffers, then there won't >>>> be a need to do RMW. >>>> >>> I understood how that side would work. >>> >>> >>>> We might need to change the code slightly to express the 4K size in the >>>> various ioctls, but that can happen latter when I run into such a device. >>>> (The current devices supported by this device driver all use 512 byte >>>> blocks.) >>>> >>> My concern is when there are devices that use 4K size blocks instead of >>> 512 byte blocks. Is there anything in the architecture of bd that means >>> they can't easily be supported by this bd driver ? >>> >>> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> >> > > > > From Garrett.Damore@sun.com Wed Dec 2 15:38:32 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2NcWmc003431 for ; Wed, 2 Dec 2009 15:38:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2NcW43020545 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Dec 2009 15:38:32 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU100A0DTO8K400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 16:38:32 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU100E9XTO76ZB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 16:38:32 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2NcVXl007514 for ; Wed, 02 Dec 2009 15:38:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100800TLLQ000@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 15:38:31 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU10034ETO6QU20@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 15:38:31 -0800 (PST) Date: Wed, 02 Dec 2009 15:38:30 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B16ECCF.1000604@sun.com> Sender: Garrett.Damore@sun.com To: =?UTF-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= Cc: Darren J Moffat , PSARC-ext@sun.com, Alan Coopersmith , "Garrett D'Amore - sun microsystems" Reply-to: Garrett.Damore@sun.com Message-id: <4B16FA76.10108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> <4B16ECCF.1000604@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 3837 Garrett D'Amore wrote: > Š¾Š»ŃŒŠ³Š° ŠŗрыŠ¶Š°Š½Š¾Š²ŃŠŗŠ°Ń wrote: >> Why is m_blksize unsigned 32bit? >> Do you want to repeat the story of '640KB are enough'? >> Please make m_blksize an uint64 for the sake of future users who want >> to address more than 4GB as block. >> > The block size is the minimum addressable unit of data. It is *not* > the maximum address. In fact, with the way this is specified, you > could in theory describe a device capable of storing 2^92 bytes of > data. Although to achieve that, you'd have to use 4GB blocks. Sorry, that's in error... it should be 2^96. (Apparently I had trouble adding 64 and 32.) For further details, assuming only a 512 byte addressable block, today you can 2^73 bytes worth of data. I think the ZFS folks have done some analysis about the amount of data that really relates to. Its way, way bigger than we'll see in my lifetime, I think. - Garrett > > The largest block size in any common use today is 64K, which is far > far short of 4GB. If you had a 4GB block size, then you would *have* > to transfer full 4GB just to do a minimum read. I don't think any > such devices are likely within the next decade or three. (Maybe not > ever.) > > - Garrett > >> On Wed, Dec 2, 2009 at 5:34 PM, Garrett D'Amore wrote: >> >>> Okay, I'm going to propose solving this properly. The solution is >>> that the >>> following structure: >>> >>> struct bd_media { >>> uint64_t m_nblks; >>> boolean_t m_readonly; >>> }; >>> >>> Will grow a new member expressing the block size: >>> >>> struct bd_media { >>> uint64_t m_nblks; >>> uint32_t m_blksize; >>> boolean_t m_readonly; >>> }; >>> >>> *However*, in order to keep things simple and efficient in the code, >>> the >>> rule is that the blksize *must* be a power of two. If the block >>> size is not >>> a power of two, then the driver will have to do the RMW thing to >>> fake one >>> up. (With the associated performance penalties.) >>> >>> This should allow non-spinning media to work fine with blkdev, even >>> with >>> larger block sizes. >>> >>> Note that I can only test 512 byte blocks, so architecturally the >>> solution >>> will be complete, but the resulting code *may* have bugs that I >>> won't know >>> about until we have media with larger block size requirements. >>> >>> - Garrett >>> >>> Darren J Moffat wrote: >>> >>>> Garrett D'Amore wrote: >>>> >>>>> Darren J Moffat wrote: >>>>> >>>>>> With the updated name I have only one possible small issue. >>>>>> >>>>>> You said the driver is hardcoded to 512 byte blocks, yet the >>>>>> industry is >>>>>> moving towards 4k blocks. Is that likely to be an issue for >>>>>> devices driven >>>>>> by 'blkdev' ? >>>>>> >>>>> I don't think so. If the application (or other code) issues smaller >>>>> I/Os, the underlying driver will have to implement as RMW. If the >>>>> filesystem or app code uses 4K aligned and sized buffers, then >>>>> there won't >>>>> be a need to do RMW. >>>>> >>>> I understood how that side would work. >>>> >>>> >>>>> We might need to change the code slightly to express the 4K size >>>>> in the >>>>> various ioctls, but that can happen latter when I run into such a >>>>> device. >>>>> (The current devices supported by this device driver all use 512 >>>>> byte >>>>> blocks.) >>>>> >>>> My concern is when there are devices that use 4K size blocks >>>> instead of >>>> 512 byte blocks. Is there anything in the architecture of bd that >>>> means >>>> they can't easily be supported by this bd driver ? >>>> >>>> >>> _______________________________________________ >>> opensolaris-arc mailing list >>> opensolaris-arc@opensolaris.org >>> >>> >> >> >> >> > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Dec 3 01:53:14 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB39rEv6029217 for ; Thu, 3 Dec 2009 01:53:14 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB39rBZN007725 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 3 Dec 2009 01:53:14 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU20070FM4PVA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Dec 2009 02:53:13 -0700 (MST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU2003H5M4OFW20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Dec 2009 02:53:13 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB39iO8i011179 for ; Thu, 03 Dec 2009 09:53:12 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay43i.sun.com with ESMTP id BT-MMP-7583638 for PSARC-ext@sun.com; Thu, 03 Dec 2009 09:53:12 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-80242018 for PSARC-ext@sun.com; Thu, 03 Dec 2009 09:53:11 +0000 (Z) Received: from relay02-muc.antispameurope.com ([217.64.175.52] [217.64.175.52]) by relay4i.sun.com with ESMTP id BT-MMP-11500283 for PSARC-ext@sun.com; Thu, 03 Dec 2009 09:53:11 +0000 (Z) Received: by relay02-muc.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 303BF2D0591; Thu, 03 Dec 2009 10:53:09 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-muc.antispameurope.com (ASE-Secure-MTA) with ESMTP id BF55E2D0500; Thu, 03 Dec 2009 10:53:07 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nB39r7AK015728; Thu, 03 Dec 2009 10:53:07 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 03 Dec 2009 10:53:07 +0100 Date: Thu, 03 Dec 2009 10:53:07 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: olga.kryzhanovska@gmail.com, gdamore@sun.com Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Garrett.Damore@sun.com, Alan.Coopersmith@sun.com Message-id: <4b178a83.i5sZujUDWp5HFa8T%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.072sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Dec 2009 09:53:07.0847 (UTC) FILETIME=[6A75C170:01CA73FE] Status: RO Content-Length: 804 ????? ???????????? wrote: > Why is m_blksize unsigned 32bit? > Do you want to repeat the story of '640KB are enough'? > Please make m_blksize an uint64 for the sake of future users who want > to address more than 4GB as block. When do you expect this to happen? The following sector sizes have been in use during the past 40 years: 256 512 800 8000 2048 516 4096 With this tendency, I would expect that it takes another 1000 years for your expectation to become reality. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Dec 3 03:05:39 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3B5dqr000750 for ; Thu, 3 Dec 2009 03:05:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB3B5bQF009105 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 3 Dec 2009 04:05:38 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU20021HPHDL200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Dec 2009 03:05:37 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU200NMBPH54320@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 03 Dec 2009 03:05:29 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB3B3d6G010973 for ; Thu, 03 Dec 2009 11:05:29 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-4874785 for PSARC-ext@sun.com; Thu, 03 Dec 2009 11:05:28 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-107311526 for PSARC-ext@sun.com; Thu, 03 Dec 2009 11:05:28 +0000 (Z) Received: from relay01-muc.antispameurope.com ([217.64.175.51] [217.64.175.51]) by relay1i.sun.com with ESMTP id BT-MMP-10820700 for PSARC-ext@sun.com; Thu, 03 Dec 2009 11:05:28 +0000 (Z) Received: by relay01-muc.antispameurope.com (ASE-Secure-MTA, from userid 1000) id A0E5725451A; Thu, 03 Dec 2009 12:05:27 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-muc.antispameurope.com (ASE-Secure-MTA) with ESMTP id A6FB32544FE; Thu, 03 Dec 2009 12:05:25 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nB3B5P6n017469; Thu, 03 Dec 2009 12:05:25 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 03 Dec 2009 12:05:25 +0100 Date: Thu, 03 Dec 2009 12:05:24 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4B16FA76.10108@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: olga.kryzhanovska@gmail.com, Garrett.Damore@sun.com Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Message-id: <4b179b74.gV1stTjDYcTDYfm1%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> <4B16ECCF.1000604@sun.com> <4B16FA76.10108@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Dec 2009 11:05:25.0075 (UTC) FILETIME=[83A63A30:01CA7408] Status: RO Content-Length: 1147 "Garrett D'Amore" wrote: > Garrett D'Amore wrote: > > ?????????? ???????????????????????? wrote: > >> Why is m_blksize unsigned 32bit? > >> Do you want to repeat the story of '640KB are enough'? > >> Please make m_blksize an uint64 for the sake of future users who want > >> to address more than 4GB as block. > >> > > The block size is the minimum addressable unit of data. It is *not* > > the maximum address. In fact, with the way this is specified, you > > could in theory describe a device capable of storing 2^92 bytes of > > data. Although to achieve that, you'd have to use 4GB blocks. > > Sorry, that's in error... it should be 2^96. (Apparently I had trouble > adding 64 and 32.) And BTW, if you asume one bit per atom, you would need already more than one ton of active storage mass for 95 bits ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Garrett.Damore@sun.com Tue Dec 8 07:36:19 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB8FaJsP009124 for ; Tue, 8 Dec 2009 07:36:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB8FaIEZ002836 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Dec 2009 07:36:19 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUC00C2NBCIQA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:36:18 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUC008TMBCHYZ10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:36:17 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB8FaHqX021041 for ; Tue, 08 Dec 2009 07:36:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUC00000B4R0600@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:36:17 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUC004FYBCB9I80@fe-sfbay-09.sun.com>; Tue, 08 Dec 2009 07:36:11 -0800 (PST) Date: Tue, 08 Dec 2009 07:36:11 -0800 From: "Garrett D'Amore" Subject: Re: bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009] In-reply-to: <4b179b74.gV1stTjDYcTDYfm1%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: olga.kryzhanovska@gmail.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com, Alan.Coopersmith@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B1E726B.4010002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911292156.nATLuXjC010913@sac.sfbay.sun.com> <4B136CBE.9060301@sun.com> <4B137C11.7050801@sun.com> <4B161E05.7060409@sun.com> <4B1633BC.7050403@Sun.COM> <4B168D24.9080808@sun.com> <4B168E30.90009@Sun.COM> <4B169710.9010004@sun.com> <4B16ECCF.1000604@sun.com> <4B16FA76.10108@sun.com> <4b179b74.gV1stTjDYcTDYfm1%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1054 FYI, this case was approved last week at PSARC. I'm marking it closed approved. - Garrett Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >> Garrett D'Amore wrote: >> >>> ?????????? ???????????????????????? wrote: >>> >>>> Why is m_blksize unsigned 32bit? >>>> Do you want to repeat the story of '640KB are enough'? >>>> Please make m_blksize an uint64 for the sake of future users who want >>>> to address more than 4GB as block. >>>> >>>> >>> The block size is the minimum addressable unit of data. It is *not* >>> the maximum address. In fact, with the way this is specified, you >>> could in theory describe a device capable of storing 2^92 bytes of >>> data. Although to achieve that, you'd have to use 4GB blocks. >>> >> Sorry, that's in error... it should be 2^96. (Apparently I had trouble >> adding 64 and 32.) >> > > And BTW, if you asume one bit per atom, you would need already more than > one ton of active storage mass for 95 bits ;-) > > Jörg > > From gdamore@sun.com Sun Feb 28 23:22:20 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o217MKZi000464 for ; Sun, 28 Feb 2010 23:22:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o217MJwU002682 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 28 Feb 2010 23:22:19 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KYL00E07DT7L800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 01 Mar 2010 00:22:19 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYL00NFCDT61K80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 01 Mar 2010 00:22:19 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o217MIbh010102 for ; Sun, 28 Feb 2010 23:22:18 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYL00H00DPOH700@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Sun, 28 Feb 2010 23:22:18 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYL0092EDT6A230@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Sun, 28 Feb 2010 23:22:18 -0800 (PST) Date: Sun, 28 Feb 2010 23:22:17 -0800 From: "Garrett D'Amore" Subject: PSARC 2009/646 bd - generic block device driver Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <4B8B6B29.6010203@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2872 The following represents an update to the case for blkdev. The blkdev framework has not delivered anything yet, and so I'm sending this as an update to the existing and previously approved case. If anyone feels this warrants promotion to a fast track of its own, please let me know asap. I won't integrate anything until after Wednesday, to give any one who wants to engage in further discussion (or request such a promotion) a chance to do so. The justification for these changes comes about as a result of feedback from external consumers who are looking at this driver and framework for future use, and need it extended to support some additional functionality for write cache management and device ids. 1) The d_wwn field is removed from struct bd_drive. Instead, the client drivers will supply an optional entry point, xx_devid_init(), which has the following prototype: int xx_devid_init(dev_info_t *dip, void *arg, ddi_devid_t *devid); The blkdev target will call this entry point (if defined) to establish a device id (see ddi_devid_init(9f)) for the target. This is more flexible than a simple WWN, since it will allow other types of device ids besides WWNs to be used. (For example, an ATA workalike driver could use DEVID_ATA_SERIAL.) The dip is the target device's dev_info_t which was created by the framework, and the "arg" field is client driver's private state structure, and the devid is a pointer to receive the created ddi_devid_t. Generally, both the dip and the devid pointer will be passed directly to ddi_devid_init(9f) and not used for anything else. This function returns the return code from ddi_devid_init(9F). This function is always called in kernel context as part of attach(9E) processing. 2) A new entry point for write cache management is provided, which has the following form: int xx_wcache_ctl(void *a, int op); op is one of: BD_WCACHE_SYNC - flush any write cache out to disk BD_WCACHE_EN - enable the write cache BD_WCACHE_DIS - disable the write cache returned value is either 0 for success, or an errno. This function is always called in kernel or user context. At this time we are not distinguishing between volatile and non-volatile write caches. 3) The bd_ops structure changes to accommodate the new entry points: struct bd_ops { int o_version; void (*o_drive_info)(void *, bd_drive_t *); int (*o_media_info)(void *, bd_media_t *); int (*o_devid_init)(void *, dev_info_t *, ddi_devid_t *); int (*o_wcache_ctl)(void *, int); int (*o_read)(void *, bd_xfer_t *); int (*o_write)(void *, bd_xfer_t *); int (*o_dump)(void *, bd_xfer_t *); }; Note that these interfaces will remain Consolidation Private.