From cth@sac.sfbay.sun.com Mon Jun 11 10:54:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5BHspH8002867 for ; Mon, 11 Jun 2007 10:54:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5BHrHul020371; Tue, 12 Jun 2007 01:53:19 +0800 (SGT) 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 <0JJH00013GCTH500@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 10:53:17 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00K3KGCO4940@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 10:53:12 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5BHrCdb010600; Mon, 11 Jun 2007 10:53:12 -0700 (PDT) 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 l5BHsfcv002862; Mon, 11 Jun 2007 10:54:41 -0700 (PDT) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l5BHsfDN002858; Mon, 11 Jun 2007 10:54:41 -0700 (PDT) Date: Mon, 11 Jun 2007 10:54:41 -0700 (PDT) From: Christopher Horne Subject: Device Size Properties [PSARC/2007/339 FastTrack timeout 06/18/2007] To: PSARC-ext@sun.com Cc: carla.mowers@sun.com Message-id: <200706111754.l5BHsfDN002858@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 17060 I am sponsoring the following fasttrack for myself, requesting patch binding and a timeout of 06/18/2007. This proposal is being driven by FMA's need to know the capacity of a failed disk FRU. If capacity information is not available, identifying a "similar capacity" replacement requires detailed knowledge of how the failed disk vendor and product information maps to capacity. -Chris Template Version: @(#)sac_nextcase 1.61 05/24/07 SMI 1. Introduction 1.1. Project/Component Working Name: Device Size Properties 1.2. Name of Document Author/Supplier: Author: Chris Horne 1.3 Date of This Document: 11 June, 2007 4. Technical Description 4.1 Problem The Solaris WDD (Writing Device Drivers) defines the 64-bit "Nblocks" and "Size" properties, and deprecates the 32-bit "nblocks" and "size", but there is no Size(9P) or Nblocks(9P) man page (CR 1098989). The "Nblocks" and "Size" properties describe the size of a ddi_create_minor_node(9F) minor node partition). For devices that have multiple partitions, there is no simple, generic way to obtain the size of the device. 4.2 Proposal This proposal provides man pages for the existing "Nblocks" and "Size" partition size properties and defines three new properties, "blksize", "device-nblocks" and "device-blksize", to represent block device size. All these properties will be described in the new Size(9P) man page. The 'blksize' properties represents the data bearing block size. The term 'data bearing' refers to how much user data is stored in a block. If we support sector checksums in the future, a device with 520 byte sectors still has a data bearing block size of 512. If "blksize" is not defined at the partition level, then "device-blksize" applies to all partitions. If neither are defined then the DEV_BSIZE (512) default is implied. The "device-nblocks" property represents the number of 'blksize' blocks of data on a block device. The "device-nblocks" property is an 'int64' property, and "device-blksize" and "blksize" are 'int' properties. For FMA, fmd(1M) modules subscribe to DR sysevents to synchronize with DINFOCACHE snapshot changes - DR invalidates the DINFOCACHE snapshot. The "Dynamic Lun Expansion" PSARC/2006/373 case also uses sysevents to learn about capacity changes. 4.2.1 Compatibility The proposal changes the units of the existing "Nblocks" property from constant DEV_BSIZE byte blocks to variable "blksize" or "device-blksize" byte blocks. An old driver will not support the "blksize" or "device-blksize" properties. New consumer code (specfs/ldi) is responsible for falling back to BDEV_BSIZE when "blksize" and "device-blksize" don't exist. The allows an old driver that only supports "Nblocks" to work with both new and old consumer code - making this a compatible change for old drivers. With the change in "Nblocks" units, old consumer code that operates against a device with a block size other than DEV_BSIZE, and asks for "Nblocks", assuming DEV_BSIZE blocks, will now think the device is smaller. In general, consumer code needs to check the existence of "blksize" and "device-blksize" before defaulting to DEV_BSIZE, or use interface ldi_get_size(9F) (or bdev_Size()) which will now perform these checks. In considering this old consumer incompatibility, the fact that "Nblocks" is implemented as a dynamic property, and dynamic properties don't show up in devinfo snapshots, means that we only need to consider in-kernel consumers. Most in-kernel consumers that depend on "Nblocks", like Veritas VxFS/VxVM, use the private legacy undocumented bdev_Size()/bdev_size() interfaces instead of asking for the "Nblocks"/"nblocks" property value directly. The bdev_Size()/bdev_size() interfaces will continue to return blocks in DEV_BSIZE units. This limits exposure to in-kernel consumers that already support large sector devices and which directly request the "Nblocks" property value. Discounting this theoretical, very unlikely corner case, changing "Nblocks" units is a compatible change. For in-kernel consumers adding new support for large sector size devices, "Nblocks" understanding is just a minor consideration. When in-kernel consumers undertake large sector device support, they are encouraged to switch to LDI. Today, we already have LDI consumers that support large sector disks: ZFS uses ldi_getsize(9F) and DKIOCGETMEDIAINFO (CR6407365). The ZFS implementation has no direct dependency on "Nblocks". In the future, adding an ldi_get_blksize() interface would be a better solution than using DKIOCGETMEDIAINFO. To summarize, in the interest of preserving the 'number of blocks' semantic of "Nblocks", it is best to incur an incompatibility now - while the impact is limited to a theoretical, an very unlikely, corner case. If we are unwilling to accept this theoretical corner case incompatibility now, "Nblocks" will over time loose its 'block' semantic. 4.2.2 Stability The "Size" and "Nblocks" properties are already public - they are defined and discussed in the WDD. Their original 32bit form, "size" and "nblocks", were introduced in 1990 - prior to ARC existence. We are adding man(9P) documentation to these already-public 'committed' properties. Since "Nblocks" is defined in units of "blksize", and "blksize" has a fall back of "device-blksize", both "blksize" and "device-blksize" need the same 'committed' stability level as "Nblocks". Putting the stability level issue aside, the goal is a man page that describes meaningful things: device capacity is meaningful. 4.2.3 Delivery Since S10, all target drivers in ON use the private ddi_prop_op_nblocks() interface off their ddi_prop_op(9E) implementation to share the same dynamic partition property implementation (see 4814888 - this also supports deprecated 32-bit "nblocks" and "size" properties). All 'real device' target drivers that currently call ddi_prop_op_nblocks() should also support the new "device-nblocks"/"device-blksize" properties. The list of 'real device' target drivers is: common/io/scsi/targets/sd.c sun/io/dada/targets/dad.c intel/io/dktp/disk/cmdk.c common/io/pcmcia/pcdisk.c common/io/fd.c sun/io/fd.c As these drivers are updated to support large sectors, they should switch to the new private ddi_prop_op_nblocks_blksize() interface. To meet schedule requirements, the initial putback may only add "device-nblocks"/"device-blksize" support to sd. A subsequent putback will bring the other drivers listed above in sync. For the sd driver, the new "device-" property values track un_blockcount, un_sys_blocksize, and un_tgt_blocksize and will be implemented using ddi_prop_update_(9F). 4.2.4 Alternatives for device capacity This section describes alternative ways of obtaining device capacity. For some of the alternatives, having to open the device represents a common problem because: o You can only determine device size if you have the permissions needed to open the device. o You will not be able to determine device size if another application had an active exclusive open. o Opening each device does not scale well. With devinfo properties, if there are devices that need to be attached, a multi-threaded attach occurs. The alternatives considered were: o SCSA Alternative: The "SCSA SCSI-3 enhancements" PSARC/1996/113 case defined SCSA 'capabilities' for 'sector-size' and 'total-sectors'. This approach was discounted because SCSA capabilities are not available in devinfo snapshots. Also, not all target drivers that support size use a SCSA transport (cmdk, dad), so exposing SCSA capabilities would not provide a generic solution. o VTOC Alternative: The Intel VTOC sector size has a v_sectorsz field . This approach was discounted because there is no v_sectorsz field in the sparc vtoc structure. Also, you need to open the device to issue the ioctl to obtain the vtoc. o DKIOCGETMEDIAINFO Alternative: The dk_minfo structure returns dki_lbsize and dki_capacity. This approach was discounted because you need to open the device to issue the ioctl to obtain dk_minfo. o Whole-disk Alternative. Use existing "Nblocks" and "Size" properties of the 'whole disk' partition. This approach was discounted because the application needs to understand which partition represents the whole disk. This is a problem because the "whole-disk" minor node: o depends on platform: sparc: s2->':b' x86: p0->':q' o depends on labeling: efi: -> ':wd' o partition properties on unformatted media don't work. This approach was also discounted because the "Nblocks" and "Size" partition properties are typically dynamic, with values provided on-demand by the driver's prop_op(9E) implementation. Currently, dynamic properties are not available in the devinfo snapshot. Providing new "device-*" properties is seen as the cleanest, most efficient way of providing device capacity information. Disk drive vendors have been encouraging Sun to support larger sector sizes (1K, 2K, 4K). At some point such support will be mandatory for maximum performance and capacity. For block devices, a two property representation (device-nblocks X device-blksize) was chosen with this in mind. 4.2.5 Future The following guidance is provided relative to future direction: o A future case should provide an ldi_get_blksize() interface. o If a future project delivers T10 data reliability support with 520 byte sectors, a "device-pblksize" should be considered. o A future case should consider making 'blksize' information via va_blksize and st_blksize stat(2) field, in much the same way that partition size is currently available via the st_size stat(2) field. o A future case may need to provide a "device-size" property to represent the size of a non-block device. o Most drivers implement partition properties as dynamic properties via private common ddi_prop_op_nblocks() code. Currently, dynamic properties are not represented in di_init(3DEVINFO) snapshots. A future case should consider defining a new "ddi-dynamic-properties" property that will allow a driver to name it's dynamic properties. The devinfo driver will use the "ddi-dynamic-properties" value to provide a snapshot representation of dynamic properties. 4.3 Example Prtconf(1M) output of new properties. name='device-nblocks' type=int64 items=1 dev=none value=000000003a386030 name='device-blksize' type=int items=1 dev=none value=00000200 4.4 Interface Table ------------------------------------------------------------------------ Interface Level Comments ------------------------------------------------------------------------ New: device-blksize(9P) Committed block device size device-nblocks(9P) " properties blksize(9P) Committed partition block size property Existing Nblocks(9P) Committed WDD defined partition Size(9P) " size properties. 4.5 References o WDD. The "Nblocks" and "Size" properties are discussed in numerous places. There is a short "Device Sizes" section. http://docs.sun.com/app/docs/doc/816-4854/6mb1o3aja?q=816-4854#hic o CR 1098989 nblocks and size need to be documented . o SCSA SCSI-3 enhancements http://sac.sfbay/PSARC/1996/113/ http://www.opensolaris.org/os/community/arc/caselog/1996/113 o ldi_get_size(9F) Interface http://sac.sfbay/PSARC/2004/171 http://www.opensolaris.org/os/community/arc/caselog/2004/171 o Add DKIOCGETMEDIAINFO ioctl http://sac.sfbay/PSARC/1999/208 http://www.opensolaris.org/os/community/arc/caselog/1999/208 o Dynamic Lun Expansion http://sac.sfbay/PSARC/2006/373 http://www.opensolaris.org/os/community/arc/caselog/2006/373 o Libdevinfo snapshot cache http://sac.sfbay/PSARC/2004/169 http://www.opensolaris.org/os/community/arc/caselog/2004/169 o multi-terabyte disk support http://sac.sfbay/PSARC/2001/570 http://www.opensolaris.org/os/community/arc/caselog/2001/570 o CR 6407365 large-sector disk support in ZFS . o Veritas indirect dependency on "Nblocks" via bdev_size() http://sac.sfbay/PSARC/1998/442 SEVM: Sun StorEdge Volume Manager http://sac.sfbay/PSARC/2000/282 Veritas Volume Manager 3.1 http://sac.sfbay/PSARC/2001/232 Veritas Volume Manager 3.2 Sector Checksumming o T10 Architecture for End to End Data Protection http://www.t10.org/ftp/t10/document.03/03-291r0.pdf o SCSI transport checksumming http://sac.sfbay/PSARC/1997/188 http://www.opensolaris.org/os/community/arc/caselog/1997/188 o Disk Driver IOCTLs for Checksumming http://sac.sfbay/PSARC/2001/240/ http://www.opensolaris.org/os/community/arc/caselog/2001/240 4.6 New Size(9P) man page: See below. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack A.1 Size(9P) man page changes Kernel Properties for Drivers Size(9P) Kernel Properties for Drivers Nblocks(9P) Kernel Properties for Drivers blksize(9P) Kernel Properties for Drivers device-nblocks(9P) Kernel Properties for Drivers device-blksize(9P) NAME device size properties DESCRIPTION A driver can communicate size information to the system by the values associated with following properties. Size information falls into two categories: device size associated with a dev_info_t node, and minor node size associated with a ddi_create_minor_node(9F) dev_t (partition). device size property names: "device-nblocks" An int64_t property representing device size in device-blksize blocks. "device-blksize" An integer property representing the size in bytes of a block. If defined, the value must be a power of two. If not defined, DEV_BSIZE is implied. minor size property names: "Size" An int64_t property representing the size in bytes of a character minor device (S_IFCHR spec_type in ddi_create_minor_node). "Nblocks" An int64_t property representing the number blocks, in device-blksize units, of a block minor device (S_IFBLK spec_type in ddi_create_minor_node). "blksize" An integer property representing the size in bytes of a block. If defined, the value must be a power of two. If not defined, "device-blksize" value is implied. A driver that implements both block and character minor device nodes should support both "Size" and "Nblocks". Typically, the following is true: Size = Nblocks * blksize. A driver where all ddi_create_minor_node(9F) calls for a given instance are associated with the same physical block device should implement "device-nblocks". If the device has a fixed block size with a value other than DEV_BSIZE then "device-blksize" should be implemented. The driver is responsible for ensuring that property values are updated when device, media, or partition sizes change. For each represented item, if its size is know to be zero, the property value should be zero; if its size is unknown, the property should not be defined. A driver may choose to implement size properties within its prop_op(9E) implementation. This reduces system memory since no space is used to store the properties. The DDI property interfaces deal in signed numbers. All Size(9P) values should be considered unsigned. It is the responsibility of the code dealing with the property value to ensure that an unsigned interpretation occurs. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface stability | Evolving | |_____________________________|_____________________________| SEE ALSO attach(9E), detach(9E), prop_op(9E), ddi_create_minor_node(9F), inquiry-vendor-id(9P) Writing Device Drivers 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From David.Kahn@sun.com Mon Jun 11 16:37:35 2007 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 l5BNbZKq013168 for ; Mon, 11 Jun 2007 16:37:35 -0700 (PDT) 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.2) with ESMTP id l5BNZclH045381 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jun 2007 17:35:39 -0600 (MDT) 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 <0JJH0070VW83LE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jun 2007 16:36:03 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH002TYW80X9B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jun 2007 16:36:00 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5BNZx6p005386; Mon, 11 Jun 2007 16:35:59 -0700 (PDT) Received: from [192.168.0.7] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5BNZwm3016958; Mon, 11 Jun 2007 16:35:59 -0700 (PDT) Date: Mon, 11 Jun 2007 16:35:58 -0700 From: David Kahn Subject: Re: Device Size Properties [PSARC/2007/339 FastTrack timeout 06/18/2007] To: Christopher Horne Cc: PSARC-ext@sun.com, carla.mowers@sun.com Message-id: <466DDC5E.9070706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Status: RO Content-Length: 529 Chris, Is there any reason not to spell out the property names, as in block-size, device-block-size, etc? The property namespace is intended to be human readable names. Also, the 64-bit properties should really be described as arrays of 2 32-bit ints, hi, low. (if you want property compatibility with OF-encoding, which we usually tend to do. There's no such thing as a 64-bit int prop in OF.) It would be nice if the fast-track included the formal definitions for all these properties, in the usual form. Thanks, -David From Chris.Horne@sun.com Tue Jun 12 13:38:28 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5CKcRBa015517 for ; Tue, 12 Jun 2007 13:38:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5CKanbT024517; Tue, 12 Jun 2007 21:36:55 +0100 (BST) 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 <0JJJ00H09ILFLW00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jun 2007 13:36:51 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJJ00A8GILFG490@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jun 2007 13:36:51 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5CKaoZe016343; Tue, 12 Jun 2007 20:36:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJJ00M01ICWPL00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM); Tue, 12 Jun 2007 14:36:50 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJJ008P2ILD3ZY2@mail-amer.sun.com>; Tue, 12 Jun 2007 14:36:49 -0600 (MDT) Date: Tue, 12 Jun 2007 14:35:57 -0600 From: Chris Horne Subject: Re: Device Size Properties [PSARC/2007/339 FastTrack timeout 06/18/2007] In-reply-to: <466DDC5E.9070706@sun.com> Sender: Chris.Horne@sun.com To: David Kahn Cc: Christopher Horne , PSARC-ext@sun.com, Carla.Mowers@sun.com Message-id: <466F03AD.9040205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <466DDC5E.9070706@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 1165 Hi David The properties I am proposing are Solaris properties. It looks to me like OBP IEEE-1275 already supports different block sizes, but chose a "block-size ( -- block-len )" 'method' implementation in conjunction with the "deblocker" and "disk-label" standard support packages instead of a 'property' implementation. Also, it seems to me that using "block-size" as a Solaris property name, instead of "blksize", might cause confusion since the Solaris property name would then conflict with the already defined OBP "block-size" method. Please let me know if my understanding is flawed. -Chris > Chris, > > Is there any reason not to spell out the property names, > as in block-size, device-block-size, etc? The property > namespace is intended to be human readable names. > > Also, the 64-bit properties should really be described > as arrays of 2 32-bit ints, hi, low. (if you want > property compatibility with OF-encoding, which we > usually tend to do. There's no such thing as a 64-bit > int prop in OF.) > > It would be nice if the fast-track included the formal > definitions for all these properties, in the usual > form. > > Thanks, > -David > From David.Kahn@sun.com Tue Jun 12 16:39:08 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5CNd8DT022502 for ; Tue, 12 Jun 2007 16:39:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5CNbVHm011319 for <@sunmail3mpk.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jun 2007 00:37:36 +0100 (BST) 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 <0JJJ00303QYN3T00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 12 Jun 2007 16:37:35 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJJ00M9JQYNG370@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 12 Jun 2007 16:37:35 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5CNbYZa028741; Tue, 12 Jun 2007 16:37:34 -0700 (PDT) Received: from [192.168.0.7] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5CNbXMh074367; Tue, 12 Jun 2007 16:37:33 -0700 (PDT) Date: Tue, 12 Jun 2007 16:37:32 -0700 From: David Kahn Subject: Re: Device Size Properties [PSARC/2007/339 FastTrack timeout 06/18/2007] In-reply-to: <466F03AD.9040205@sun.com> To: Chris Horne Cc: Christopher Horne , PSARC-ext@sun.com, Carla.Mowers@sun.com Message-id: <466F2E3C.1040200@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <466DDC5E.9070706@sun.com> <466F03AD.9040205@sun.com> User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Status: RO Content-Length: 885 Chris Horne wrote: > Hi David > > The properties I am proposing are Solaris properties. Yes, that was understood. > It looks to me > like OBP IEEE-1275 already supports different block sizes, but chose a > "block-size ( -- block-len )" 'method' implementation in conjunction > with the "deblocker" and "disk-label" standard support packages instead > of a 'property' implementation. Also, it seems to me that using > "block-size" as a Solaris property name, instead of "blksize", might > cause confusion since the Solaris property name would then conflict > with the already defined OBP "block-size" method. > > Please let me know if my understanding is flawed. If you're concerned about confusion because the property namespace may overlap the method namespace (which are independent) then pick a different set of non-cryptic, non-abbreviated self-describing names. -David From Chris.Horne@sun.com Wed Jun 13 13:47:34 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5DKlXnp022677 for ; Wed, 13 Jun 2007 13:47:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5DKjw9g000468; Wed, 13 Jun 2007 21:45:59 +0100 (BST) 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 <0JJL00I03DON6000@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Jun 2007 13:45:59 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJL00AZXDOMU990@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Jun 2007 13:45:58 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5DKjwZx027491; Wed, 13 Jun 2007 20:45:58 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJL00M01CZLON00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM); Wed, 13 Jun 2007 14:45:58 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJL00IADDOLT9S3@mail-amer.sun.com>; Wed, 13 Jun 2007 14:45:58 -0600 (MDT) Date: Wed, 13 Jun 2007 14:45:04 -0600 From: Chris Horne Subject: Re: Device Size Properties [PSARC/2007/339 FastTrack timeout 06/18/2007] In-reply-to: <466F2E3C.1040200@sun.com> Sender: Chris.Horne@sun.com To: David Kahn Cc: Christopher Horne , PSARC-ext@sun.com, Carla.Mowers@sun.com Message-id: <46705750.4020909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <466DDC5E.9070706@sun.com> <466F03AD.9040205@sun.com> <466F2E3C.1040200@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 155 > 1.1. Project/Component Working Name: > Device Size Properties This fasttrack was approved, as specified, at today's PSARC meeting. -Chris