From sacadmin Mon Jul 7 04:04:53 2008 Received: from sunraf.sfbay.sun.com (sunraf.SFBay.Sun.COM [129.146.177.11]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m67B4rAe008446; Mon, 7 Jul 2008 04:04:53 -0700 (PDT) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m67B4quT101677; Mon, 7 Jul 2008 04:04:52 -0700 (PDT) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m67B4qDi101673; Mon, 7 Jul 2008 04:04:52 -0700 (PDT) Date: Mon, 7 Jul 2008 04:04:52 -0700 (PDT) From: "Roger A. Faulkner" Message-Id: <200807071104.m67B4qDi101673@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: _POSIX_ADVISORY_INFO [PSARC/2008/421 FastTrack timeout 07/11/2008] Status: RO Content-Length: 555 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: _POSIX_ADVISORY_INFO 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 07 July, 2008 4. Technical Description See the case directory for more detail 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 Roger.Faulkner@sun.com Mon Jul 7 07:25:55 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m67EPthB013617 for ; Mon, 7 Jul 2008 07:25:55 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id m67EPtu1607189; Mon, 7 Jul 2008 07:25:55 -0700 (PDT) Message-Id: <200807071425.m67EPtu1607189@jurassic-x4600.sfbay.sun.com> Date: Mon, 7 Jul 2008 07:25:55 -0700 (PDT) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2008/421 - _POSIX_ADVISORY_INFO To: psarc-ext@sac.sfbay.sun.com Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UrnH+Jpew7GQAIqTsyy8kQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_90 SunOS 5.11 i86pc i386 Status: RO Content-Length: 5301 I am sponsoring this fast-track case for myself. This proposal will time out 07/11/2008 All of the proposed interfaces are specified by Posix (SUSv3), so the stability level is 'Standard' in all cases. The proposed release binding is "minor release" since no one wants this to be back-ported to Solaris 10. The change being proposed here is to implement the interfaces, specified by the Posix SUSv3 standard, necessary to support the _POSIX_ADVISORY_INFO option group in Solaris. This includes implementing the libc functions: posix_fadvise() posix_fallocate() posix_madvise() posix_memalign() and activating the [f]pathconf() variables: _____________________________________________________ | {POSIX_ALLOC_SIZE_MIN} | _PC_ALLOC_SIZE_MIN | |___________________________|________________________| | {POSIX_REC_INCR_XFER_SIZE}| _PC_REC_INCR_XFER_SIZE| |___________________________|________________________| | {POSIX_REC_MAX_XFER_SIZE} | _PC_REC_MAX_XFER_SIZE | |___________________________|________________________| | {POSIX_REC_MIN_XFER_SIZE} | _PC_REC_MIN_XFER_SIZE | |___________________________|________________________| | {POSIX_REC_XFER_ALIGN} | _PC_REC_XFER_ALIGN | |___________________________|________________________| These [f]pathconf() interfaces already exist, but they all return -1 and set errno to EINVAL. The posix_fallocate() interface was implemented in solaris_nevada for the UFS file system as part of the PSARC case: PSARC 2004/422 posix_fallocate Unfortunately, it was not implemented with proper Posix-specified error return values, so it has to be fixed up a bit. Also, unfortunately, the interface was implemented only for the UFS file system. Further work is needed to implement this interface for other file systems, notably ZFS and NFS. The NFS file system needs to be taught to send the new request over the wire, as it already does for ftruncate(). These are future projects. There is no requirement to implement posix_fallocate() for all file systems. The posix_fallocate() specification allows for this error: EINVAL The underlying file system does not support this operation. The posix_fadvise(), posix_madvise(), and posix_memalign() interfaces do not yet exist. The initial implementation of posix_fadvise() will do nothing other than return proper error values. This is OK because the SUSv3 specification doesn't require it to do anything. This just provides the infrastructure for some future project to use to optimize I/O performance. The posix_madvise() function will just call the existing madvise() function. The posix_memalign() function will just call the existing memalign() function. These header files require additions: add declarations for posix_fadvise() and posix_fadvise64() add declaration for posix_memalign() add definition of _POSIX_ADVISORY_INFO (200112L) add definitions of advice values for posix_fadvise() add declaration for posix_madvise() add definitions of advice values for posix_madvise() The values returned for the [f]pathconf() variables are both system- and filesystem-dependent. The proposed values are best described by these comments from usr/src/uts/common/syscall/pathconf.c : case _PC_ALLOC_SIZE_MIN: case _PC_REC_INCR_XFER_SIZE: case _PC_REC_MAX_XFER_SIZE: case _PC_REC_MIN_XFER_SIZE: case _PC_REC_XFER_ALIGN: /* * There is generally no harm in doing larger transfers, but * there's a point of diminishing returns. With 1MB transfers, * even if they're random, you get very close to platter speed. * Se we return 1MB as the maximum transfer size. */ if (cmd == _PC_REC_MAX_XFER_SIZE) return ((long)MAX(sb.f_bsize, 1UL << 20)); /* * By definition, f_frsize is the smallest filesystem block. * However, _PC_ALLOC_SIZE_MIN is intended to define the * threshold for direct I/O. This implies two requirements: * the VM and I/O subsystems must be able to create mappings * for DMA, which requires at least page alignment; and the * filesystem must avoid read/modify/write, which generally * requires multiples of its 'preferred' blocksize, f_bsize. * * PAGESIZE alignment is sufficient for DMA and block copy. * Rounding up to the filesystem 'preferred' blocksize * works just as well. * * All together, this means that the remaining parameters * map into the same value. */ return ((long)MAX(sb.f_bsize, PAGESIZE)); See the materials directory for the manual pages: posix_fadvise.3c posix_fallocate.3c posix_madvise.3c posix_memalign.3c These are copies of the Posix SUSv3 specification pages, with minor changes such as changing 'shall' to 'will' and specifying what the 'implementation-defined' behaviors are for Solaris. For reference, the Posix SUSv3 specification pages are included as: posix_fadvise.susv3 posix_fallocate.susv3 posix_madvise.susv3 posix_memalign.susv3 Roger Faulkner From glenn.skinner@sun.com Wed Jul 9 09:33:38 2008 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m69GXclF012080 for ; Wed, 9 Jul 2008 09:33:38 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m69GXcRm029077; Wed, 9 Jul 2008 09:33:38 -0700 (PDT) Message-Id: <200807091633.m69GXcRm029077@ivrel.sfbay.sun.com> Date: Wed, 9 Jul 2008 09:33:38 -0700 (PDT) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Uwd1NYhpG9QJSX9Up1a3nA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 647 Date: Mon, 07 Jul 2008 07:25:55 -0700 (PDT) From: "Roger A. Faulkner" Subject: PSARC/2008/421 - _POSIX_ADVISORY_INFO To: psarc-ext@sac.sfbay.sun.com Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com I am sponsoring this fast-track case for myself. This proposal will time out 07/11/2008 All of the proposed interfaces are specified by Posix (SUSv3), so the stability level is 'Standard' in all cases. "Standard" is no longer an independent classification in the interface taxonomy. Am I correct in assuming that you really mean "Standard Committed"? -- Glenn From glenn.skinner@sun.com Wed Jul 9 09:40:03 2008 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m69Ge3h0012665 for ; Wed, 9 Jul 2008 09:40:03 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m69Ge33u029085; Wed, 9 Jul 2008 09:40:03 -0700 (PDT) Message-Id: <200807091640.m69Ge33u029085@ivrel.sfbay.sun.com> Date: Wed, 9 Jul 2008 09:40:03 -0700 (PDT) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XtkSf86qRbh1AgVKneV1Zw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 819 Date: Wed, 09 Jul 2008 09:33:38 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] Date: Mon, 07 Jul 2008 07:25:55 -0700 (PDT) From: "Roger A. Faulkner" Subject: PSARC/2008/421 - _POSIX_ADVISORY_INFO I am sponsoring this fast-track case for myself. This proposal will time out 07/11/2008 All of the proposed interfaces are specified by Posix (SUSv3), so the stability level is 'Standard' in all cases. "Standard" is no longer an independent classification in the interface taxonomy. Am I correct in assuming that you really mean "Standard Committed"? Brain lapse: I really meant plain old "Committed" (even this nit picker can't get it right). -- Glenn From Roger.Faulkner@sun.com Wed Jul 9 09:53:45 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m69Grjxh014662 for ; Wed, 9 Jul 2008 09:53:45 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id m69Grixc138543; Wed, 9 Jul 2008 09:53:44 -0700 (PDT) Message-Id: <200807091653.m69Grixc138543@jurassic-x4600.sfbay.sun.com> Date: Wed, 9 Jul 2008 09:53:44 -0700 (PDT) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] To: psarc-ext@sac.sfbay.sun.com, glenn.skinner@sun.com Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sLHWCJMLqUrn9ZIlWr1zGA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_90 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1973 > Date: Wed, 09 Jul 2008 09:40:03 -0700 (PDT) > From: Glenn Skinner > Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] > To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com > Cc: darrin.johnson@sun.com, don.cragun@sun.com, jeff.bonwick@sun.com > > Date: Wed, 09 Jul 2008 09:33:38 -0700 (PDT) > From: Glenn Skinner > Subject: Re: 2008/421 [_POSIX_ADVISORY_INFO] > > Date: Mon, 07 Jul 2008 07:25:55 -0700 (PDT) > From: "Roger A. Faulkner" > Subject: PSARC/2008/421 - _POSIX_ADVISORY_INFO > > I am sponsoring this fast-track case for myself. > This proposal will time out 07/11/2008 > > All of the proposed interfaces are specified by Posix (SUSv3), > so the stability level is 'Standard' in all cases. > > "Standard" is no longer an independent classification in the > interface taxonomy. Am I correct in assuming that you really mean > "Standard Committed"? > > Brain lapse: I really meant plain old "Committed" (even this nit > picker can't get it right). > > -- Glenn Yes, Standard == Committed Does this mean that all of the man pages have to be fixed up? I see that the official solaris_nevada man page for, say, pthread_mutex_init(3C) has this section: ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Standard | |_____________________________|_____________________________| | MT-Level | MT-Safe | |_____________________________|_____________________________| That's what I have in the new man pages for this case (see the 'materials' directory). Roger