From rsb@sac.sfbay.sun.com Fri Jan 25 12:47:57 2008 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 m0PKluYO019744 for ; Fri, 25 Jan 2008 12:47:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0PKlYAf026051; Fri, 25 Jan 2008 20:47:56 GMT 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 <0JV70040BWFUG000@nwk-avmta-1.sfbay.Sun.COM>; Fri, 25 Jan 2008 12:47:54 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV7003CAWFU8VD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 25 Jan 2008 12:47:54 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0PKlreV025574; Fri, 25 Jan 2008 12:47:53 -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 m0PKeM4k019676; Fri, 25 Jan 2008 12:40:22 -0800 (PST) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m0PKeMpj019672; Fri, 25 Jan 2008 14:40:22 -0600 (CST) Date: Fri, 25 Jan 2008 14:40:22 -0600 (CST) From: Rich.Brown@sun.com Subject: 64 bit offsets for VOP_DUMP [PSARC/2008/053 FastTrack timeout 02/01/2008] To: PSARC-ext@sun.com Cc: Rich.Brown@sun.com, Robert.Mastors@sun.com Message-id: <200801252040.m0PKeMpj019672@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6457 I'm submitting this fast-track for Bob Mastors. Requested binding is MINOR. Time-out is 1 Feb, 2008. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: 64 bit offsets for VOP_DUMP 1.2. Name of Document Author/Supplier: Author: Bob Mastors 1.3 Date of This Document: 25 January, 2008 4. Technical Description INTRODUCTION The vnode operation VOP_DUMP uses 32-bit values for block addressing. This prevents system crash dumps and cpr statefiles from being saved on very large devices via VOP_DUMP. PROPOSED CHANGES Change block offset and lengths to type offset_t for VOP_DUMP and VOP_DUMPCTL. Change corresponding functions in FEM, file event monitoring. Change file system implementations of VOP_DUMP and VOP_DUMPCTL to work with the new types. Change callers of the above VOP/FEM functions as needed. The VFSDEF_VERSION number in sys/vfs.h will be bumped from 4 to 5 in order to prevent unbundled file system kernel modules with the old signatures from loading. Once the unbundled file system modules are updated with the new signatures and recompiled, they will also pick up the new VFSDEF_VERSION number and be allowed to load. All of the ON file systems will be updated with these changes. Unbundled file system developers (internal and external) will be given a heads up about these changes. Rich Brown is coordinating a TOI on all file system changes made in Solaris Nevada. Note that Solaris Nevada now performs strong type-checking on vnode/FEM operations. This means that the compilers will inform unbundled file system developers of the signature discrepancy in their code. DEVICE DRIVER INTERFACE No changes are proposed to the device driver interface. File system specific dump functions typically call the DDI routine bdev_dump which has the following signature: int bdev_dump(dev_t dev, caddr_t addr, daddr_t blkno, int blkcnt) bdev_dump calls the underlying device dump(9e) function which has the same signature. On the 64-bit solaris kernel, daddr_t is 64-bits. However on the 32-bit solaris kernel, daddr_t is a 32-bit value. bdev_dump and device driver dump(9e) functions have the following characteristics: 64-bit device drivers have 64-bit block addressing and 32-bit block counts. 32-bit device drivers have 32-bit block addressing and 32-bit block counts. Current consumers of VOP_DUMP limit the transfer size to a few megabytes at a time. They do not overflow the 32-bit block count. 32-bit block addressing results in the following limitation. A file should not be used as the dump device or cpr statefile when all of the following conditions occur: a) the solaris kernel is compiled 32-bit b) the file system is UFS c) the file system is larger then 1 TB This limitation may also apply to unbundled file systems. ZFS does not have this limitation because it does not support files as dump devices or cpr statefiles. The fop_dump() function will be changed to perform safety checks to ensure the offset and length passed to VOP_DUMP can be passed onto bdev_dump safely. fop_dump will return EIO if the values cannot be passed safely. These safety checks may be removed in the future if the DDI dump(9e) signature is modified to support 64-bit addressing and 64-bit block counts on all architectures. ALTERNATIVES TO OFFSET_T The selection of "offset_t" for the type of the block address and block count seemed consistent with usage in other VOP functions and "struct uio". Also offset_t is a signed value, as are the types it is replacing. Alternatives considered include the following: typedef u_longlong_t diskaddr_t; typedef u_longlong_t len_t; typedef u_longlong_t u_offset_t; typedef uint64_t paddr_t; RELATED CASES PSARC/2001/679 Vnode Interfaces PSARC/2007/124 Strong Type-Checking for VFS Operations RELATED CONTRACTS PSARC 2001/599 (FS related interfaces for SAM-QFS) PSARC 2004/177 (FS related interfaces for Sun Cluster) RELATED CR 6214480 System crash dump fails when dump device is > 1 TB DELIVERY These modifications are intended to be part of Solaris Nevada. MODIFIED INTERFACES +---------------+------------------+----------------------------+ | Interface | Classification | Comments | +---------------+------------------+----------------------------+ | | Contracted | | | VOP_DUMP, | Consolidation | changed block addr and len | | fop_dump | Private | to offset_t | | | | | | VOP_DUMPCTL, | | | | fop_dumpctl | | | | | | | | vnext_dump, | | | | vnext_dumpctl | | | | | | | | | | | | | | | +---------------+------------------+----------------------------+ Following are the full definitions of the modified interfaces. int (*vop_dump)(vnode_t *, caddr_t, offset_t, offset_t, caller_context_t *); int (*vop_dumpctl)(vnode_t *, int, offset_t *, caller_context_t *); extern int fop_dump(vnode_t *, caddr_t, offset_t, offset_t, caller_context_t *); extern int fop_dumpctl(vnode_t *, int, offset_t *, caller_context_t *); int vnext_dump(femarg_t *vf, caddr_t addr, offset_t lbdn, offset_t dblks, caller_context_t *ct) int vnext_dumpctl(femarg_t *vf, int action, offset_t *blkp, caller_context_t *ct) 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 Rich.Brown@sun.com Wed Jan 30 10:20:02 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0UIK21s028913 for ; Wed, 30 Jan 2008 10:20:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0UIJv4m013386 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 30 Jan 2008 10:20:01 -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 <0JVG00F1JYXBTV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jan 2008 10:19:59 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG00193YX34NB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jan 2008 10:19:52 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0UIJpBP016278 for ; Wed, 30 Jan 2008 18:19:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVG00C01YTLR400@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jan 2008 11:19:51 -0700 (MST) Received: from [129.147.9.132] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVG00ICLYX10Z60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 30 Jan 2008 11:19:50 -0700 (MST) Date: Wed, 30 Jan 2008 12:19:49 -0600 From: Rich Brown Subject: Re: 64 bit offsets for VOP_DUMP [PSARC/2008/053 FastTrack timeout 02/01/2008] In-reply-to: <200801252040.m0PKeMpj019672@sac.sfbay.sun.com> Sender: Rich.Brown@sun.com To: PSARC-ext@sun.com Cc: Rich.Brown@sun.com, Robert.Mastors@sun.com Message-id: <47A0BFC5.6010003@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: <200801252040.m0PKeMpj019672@sac.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 90 This was approved at today's PSARC meeting. I've marked this as closed approved. Rich