From Tim.Haley@sun.com Wed Aug 26 09:02:55 2009 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 n7QG2tNM013795 for ; Wed, 26 Aug 2009 09:02:55 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7QG2m15016755; Wed, 26 Aug 2009 17:02:54 +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 <0KOZ00D05R8S3S00@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Aug 2009 09:02:52 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOZ000DDR8RXLF0@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Aug 2009 09:02:51 -0700 (PDT) Received: from spidey.local (spidey.Central.Sun.COM [172.20.25.27]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7QG2psw019843; Wed, 26 Aug 2009 10:02:51 -0600 (MDT) Received: from spidey.local (localhost [127.0.0.1]) by spidey.local (8.14.3+Sun/8.14.3) with ESMTP id n7QFtKcn028473; Wed, 26 Aug 2009 09:55:20 -0600 (MDT) Received: (from timh@localhost) by spidey.local (8.14.3+Sun/8.14.3/Submit) id n7QFtKc8028472; Wed, 26 Aug 2009 09:55:20 -0600 (MDT) Date: Wed, 26 Aug 2009 09:55:20 -0600 (MDT) From: Tim Haley Subject: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] To: PSARC-ext@sun.com Cc: cifs-eng@sun.com Message-id: <200908261555.n7QFtKc8028472@spidey.local> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3487 I am sponsoring the following fasttrack for Alan Wright. Requested binding is minor. Timeout is 9/2/2009. 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: Offline attribute 1.2. Name of Document Author/Supplier: Author: Alan Wright 1.3 Date of This Document: 26 August, 2009 4. Technical Description 4.1. Details: This case proposes a new system attribute to support offline files as a generic solution to the proposal in PSARC/2009/381 Support off-line files on SAM-QFS for Samba in Solaris. PSARC/2009/381 provides a specific solution for the use of Samba with SAM-FS that depends on libsamfs, which is delivered by the SUNWsamfsr and SUNWsamfsu packages. The system attribute interface is described in: PSARC/2007/315 Extensible Attribute Interfaces. Associated changes to chmod(1) and ls(1) are described in: PSARC/2007410 Add system attribute to chmod PSARC/2007394 ls(1) '-/' and '-%' options for system attributes The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes view defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. 4.6. Doc Impact: Modifications to the chmod(1) man page: Table 1: Attribute Names and Abbreviation Characters Attribute Name Attribute Abbreviation Character -------------- -------------------------------- + offline O Modifications to the ls(1) man page: -/ c | v + offline - Attribute to indicate that a file is offline. The display characters used in compact mode (-/ c) are as follows: Attribute Name Display + offline O The display positions are as follows: ! {|||||||||||} + ||||||||||+- O (offline) ! |||||||||+-- u (nounlink) ! ||||||||+--- q (av_quarantined) ! |||||||+---- m (av_modified) ! ||||||+----- i (immutable) ! |||||+------ d (nodump) ! ||||+------- a (appendonly) ! |||+-------- S (system) ! ||+--------- R (readonly) ! |+---------- H (hidden) ! +----------- A (archive) Modifications to the fgetattr(3C) man page: View Attribute Data type _______________________________________________________________ XATTR_VIEW_READWRITE ... + A_OFFLINE boolean_value 5. Exported Interface Table |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Consolidation |This | |Private |Document | | | | A_OFFLINE | | | Added to read-write | | | view of extended | | | attribute namespace | | | | | | XAT_OFFLINE | | | Value for offline | | | system attribute 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 Darren.Moffat@sun.com Wed Aug 26 10:06:53 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 n7QH6rPw016055 for ; Wed, 26 Aug 2009 10:06:53 -0700 (PDT) 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 n7QH6qga023904; Wed, 26 Aug 2009 10:06:52 -0700 (PDT) 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 <0KOZ0060DU7FY700@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Aug 2009 10:06:51 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOZ00ERDU7EHM80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Aug 2009 10:06:51 -0700 (PDT) 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-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7QH6oHT018470; Wed, 26 Aug 2009 17:06:50 +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 <0KOZ00B00TTXO800@fe-emea-09.sun.com>; Wed, 26 Aug 2009 18:06:33 +0100 (BST) 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 <0KOZ005J7U6WHB50@fe-emea-09.sun.com>; Wed, 26 Aug 2009 18:06:32 +0100 (BST) Date: Wed, 26 Aug 2009 18:06:31 +0100 From: Darren J Moffat Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <200908261555.n7QFtKc8028472@spidey.local> Sender: Darren.Moffat@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A956B97.3070505@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: <200908261555.n7QFtKc8028472@spidey.local> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 909 I'm fine with the attribute part of this case, the ls output and the VOP interfaces. However I might be missing part of a bigger picture here. Who is expected to set this - I assume SAM-FS or similar ? How is a consumer encountering such an attribute supposed to do something about it when they find such a file and were do they find the info to do something about it. For example the CIFS server is servicing a request from a CIFS client. The attribute is set of a file in the ZFS filesystem that is shared over CIFS. Is it the client or server that needs to look at the offline attribute ? Is one of them supposed to know to bring the file online ? If so how do they do that ? Maybe what I'm missing is knowing how SAM-FS (or something similar) fits into the picture with ZFS being used for storage and the CIFS client and server. A picture (ASCII is fine) might help. -- Darren J Moffat From roehrich@kickball-mn.Central.Sun.COM Wed Aug 26 14:40:51 2009 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 n7QLeo4q001919 for ; Wed, 26 Aug 2009 14:40:50 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7QLeiF4023976; Wed, 26 Aug 2009 22:40:49 +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 <0KP000C096W06I00@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Aug 2009 14:40:48 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP0003H86VZ8160@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Aug 2009 14:40:47 -0700 (PDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7QLekSx062500; Wed, 26 Aug 2009 15:40:47 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id n7QLXFq8004722; Wed, 26 Aug 2009 16:33:15 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id n7QLXFek004721; Wed, 26 Aug 2009 16:33:15 -0500 (CDT) Date: Wed, 26 Aug 2009 16:33:15 -0500 From: Dean Roehrich Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <200908261555.n7QFtKc8028472@spidey.local> To: Tim Haley Cc: PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <20090826213315.GA4704@kickball-mn.central.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 1108 On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: > The offline attribute (XAT_OFFLINE) will be added to the read- > write system attributes view defined in PSARC/2007/315 and will be > generally available to file systems and applications to indicate > the offline/online status of objects: boolean value of true > indicates the object is offline. In order to set or clear the > offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES > permission or the PRIV_FILE_OWNER privilege. In the kernel, it > will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user > space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). > No changes are required to the VOP or fgetattr(3C) function > prototypes. An HSM does not want the file's owner to twiddle this status. That status should be controlled by the HSM. I agree that anyone ought to be able to query the status. Joe User's file browser should be able to see it and make smart decisions, such as not trying to read a known-offline file as part of its effort to determine what kind of icon to display. Dean From amw@sun.com Wed Aug 26 16:33: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 n7QNXQVD016573 for ; Wed, 26 Aug 2009 16:33:26 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7QNXP6g018583; Wed, 26 Aug 2009 16:33:26 -0700 (PDT) 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 <0KP000209C3PJF00@brm-avmta-1.central.sun.com>; Wed, 26 Aug 2009 17:33:25 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP000KMDC3P5Y20@brm-avmta-1.central.sun.com>; Wed, 26 Aug 2009 17:33:25 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7QNXP9L000107; Wed, 26 Aug 2009 23:33:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP000D00BVPEP00@mail-amer.sun.com>; Wed, 26 Aug 2009 17:33:25 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP000C2DC3OQ9B0@mail-amer.sun.com>; Wed, 26 Aug 2009 17:33:25 -0600 (MDT) Date: Wed, 26 Aug 2009 16:33:24 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A956B97.3070505@Sun.COM> Sender: Alan.M.Wright@sun.com To: Darren J Moffat Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A95C644.8060909@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: <200908261555.n7QFtKc8028472@spidey.local> <4A956B97.3070505@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3018 On 08/26/09 10:06, Darren J Moffat wrote: > I'm fine with the attribute part of this case, the ls output and the VOP > interfaces. > > However I might be missing part of a bigger picture here. > > Who is expected to set this - I assume SAM-FS or similar ? A hierarchical storage file system might set it when the file content is not available on primary storage. A migration tool (one that intercepts FS requests to migrate files on demand) could set it. It also occurred to me that vscan could set it (when a scan-on-open delays the open response) while the file is being scanned. End-users could set this bit (via chmod) on their files if they have an extremely slow file system to stop Windows clients timing out. I didn't go into that because this was a follow-up to PSARC/2009/381 and assumed that case had established the background and basis for such an attribute. > How is a consumer encountering such an attribute supposed to do > something about it when they find such a file and were do they find the > info to do something about it. Similar to the hidden and system attributes, there's no defined or required behavior when the attribute is set. The expectation might be that applications (or people) will wait longer than they normally would to obtain the file content but that's not required. For the purpose described in PSARC/2009/381, I believe that returning this attribute to Windows clients stops them timing out while files are retrieved from secondary or tertiary storage. > For example the CIFS server is servicing a request from a CIFS client. > The attribute is set of a file in the ZFS filesystem that is shared over > CIFS. Is it the client or server that needs to look at the offline > attribute ? The CIFS server simply passes the attribute over-the-wire along with the other file attributes (hidden, system, readonly, archive etc). The CIFS server does not interpret this attribute nor does it make any assumptions about what the client may do when it is set. If the client is aware of this attribute (defined as FILE_ATTRIBUTE_OFFLINE on Windows) it may decide to change it's behavior but that's opaque to the server. > Is one of them supposed to know to bring the file online ? > If so how do they do that ? Maybe what I'm missing is knowing how > SAM-FS (or something similar) fits into the picture with ZFS being used > for storage and the CIFS client and server. A picture (ASCII is fine) > might help. If the file system is managing this bit, it would also know how to bring files online. Currently, there's no ZFS behavior associated with this attribute, it will just store it and return it. This may change with the ADM or file migration work. SAMFS already has something like this but it is a private interface. This case is intended to make an offline bit available as a generic, public interface. Alan > -- > Darren J Moffat > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From amw@sun.com Wed Aug 26 16:40:46 2009 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 n7QNej5S016702 for ; Wed, 26 Aug 2009 16:40:45 -0700 (PDT) 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 n7QNegcQ000289; Thu, 27 Aug 2009 00:40:44 +0100 (BST) 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 <0KP000D09CFU9F00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Aug 2009 16:40:42 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP0004A9CFUFS50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Aug 2009 16:40:42 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7QNeghn001652; Wed, 26 Aug 2009 23:40:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP000I00C5UOW00@mail-amer.sun.com>; Wed, 26 Aug 2009 17:40:42 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP000C7FCFTQ9B0@mail-amer.sun.com>; Wed, 26 Aug 2009 17:40:41 -0600 (MDT) Date: Wed, 26 Aug 2009 16:40:41 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <20090826213315.GA4704@kickball-mn.central.sun.com> Sender: Alan.M.Wright@sun.com To: Dean Roehrich Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A95C7F9.4000304@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: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1543 On 08/26/09 14:33, Dean Roehrich wrote: > On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: >> The offline attribute (XAT_OFFLINE) will be added to the read- >> write system attributes view defined in PSARC/2007/315 and will be >> generally available to file systems and applications to indicate >> the offline/online status of objects: boolean value of true >> indicates the object is offline. In order to set or clear the >> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES >> permission or the PRIV_FILE_OWNER privilege. In the kernel, it >> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user >> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). >> No changes are required to the VOP or fgetattr(3C) function >> prototypes. > > An HSM does not want the file's owner to twiddle this status. That status > should be controlled by the HSM. The file system can return EACCES or EPERM if it doesn't want the attribute changed via fsetattr(3C). I didn't want to preclude user space applications from being able to manipulate this attribute on regular (non-HSM) file systems. As I mentioned, a virus scanner could be configured to mark the file as offline while it is performing a scan-on- open. Alan > I agree that anyone ought to be able to query the status. Joe User's file > browser should be able to see it and make smart decisions, such as not trying > to read a known-offline file as part of its effort to determine what kind of > icon to display. > > > Dean From Darren.Moffat@Sun.COM Thu Aug 27 01:42:51 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 n7R8gp5s011701 for ; Thu, 27 Aug 2009 01:42:51 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7R8gjJB005286; Thu, 27 Aug 2009 01:42:51 -0700 (PDT) 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 <0KP100G0P1JDLM00@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 02:42:49 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP1009FP1JCQ070@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 02:42:49 -0600 (MDT) 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-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7R8gloq002503; Thu, 27 Aug 2009 08:42: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 <0KP000L00ZPVL900@fe-emea-09.sun.com>; Thu, 27 Aug 2009 09:42:39 +0100 (BST) 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 <0KP100H3H1IFE510@fe-emea-09.sun.com>; Thu, 27 Aug 2009 09:42:15 +0100 (BST) Date: Thu, 27 Aug 2009 09:42:15 +0100 From: Darren J Moffat Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A95C644.8060909@sun.com> Sender: Darren.Moffat@Sun.COM To: Alan M Wright Cc: Tim Haley , PSARC-ext@Sun.COM, cifs-eng@Sun.COM Message-id: <4A9646E7.10701@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: <200908261555.n7QFtKc8028472@spidey.local> <4A956B97.3070505@Sun.COM> <4A95C644.8060909@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 301 Thanks Alan for the context. I'm happy that this is sufficiently standalone and useful as is to give my +1 on the case. I can see that to take full advantage of this other things need to be built on it but for the VOP layer CIFS and ZFS layers this case seems complete to me. -- Darren J Moffat From jub@sun.com Thu Aug 27 03:50:57 2009 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 n7RAou5E013773 for ; Thu, 27 Aug 2009 03:50:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7RAontm022974; Thu, 27 Aug 2009 18:50:55 +0800 (SGT) 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 <0KP100M077GUBR00@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Aug 2009 03:50:54 -0700 (PDT) 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 <0KP100LH27GTOW00@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Aug 2009 03:50:53 -0700 (PDT) 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 n7RAoqKk017765; Thu, 27 Aug 2009 10:50:52 +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 <0KP10000073AO200@fe-emea-09.sun.com>; Thu, 27 Aug 2009 11:50:39 +0100 (BST) Received: from [10.16.46.61] ([unknown] [10.16.46.61]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP100M667GF9AG0@fe-emea-09.sun.com>; Thu, 27 Aug 2009 11:50:39 +0100 (BST) Date: Thu, 27 Aug 2009 12:50:38 +0200 From: Joerg Barfurth Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A95C644.8060909@sun.com> Sender: joerg.barfurth@sun.com To: Alan M Wright Cc: Darren J Moffat , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A9664FE.1000304@sun.com> Organization: Sun Microsystems 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: <200908261555.n7QFtKc8028472@spidey.local> <4A956B97.3070505@Sun.COM> <4A95C644.8060909@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 345 Alan M Wright schrieb: > [...] SAMFS already has > something like this but it is a private interface. This case is > intended to make an offline bit available as a generic, public > interface. > This is at odds with your Exported Interfaces table, which indicates that all new interfaces are introduced as 'Consolidation Private'. - Jörg From roehrich@kickball-mn.Central.Sun.COM Thu Aug 27 13:24:41 2009 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 n7RKOfvE021145 for ; Thu, 27 Aug 2009 13:24:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7RKOcIT023041; Thu, 27 Aug 2009 21:24:38 +0100 (BST) 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 <0KP100I07Y12S700@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 14:24:38 -0600 (MDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP100MMXY12OAE0@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 14:24:38 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7RKOaC9026297; Thu, 27 Aug 2009 14:24:37 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id n7RKH62g008774; Thu, 27 Aug 2009 15:17:06 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id n7RKH6CT008773; Thu, 27 Aug 2009 15:17:06 -0500 (CDT) Date: Thu, 27 Aug 2009 15:17:06 -0500 From: Dean Roehrich Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A95C7F9.4000304@sun.com> To: Alan M Wright Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <20090827201706.GA8760@kickball-mn.central.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 1542 On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: > On 08/26/09 14:33, Dean Roehrich wrote: > >On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: > >> The offline attribute (XAT_OFFLINE) will be added to the read- > >> write system attributes view defined in PSARC/2007/315 and will be > >> generally available to file systems and applications to indicate > >> the offline/online status of objects: boolean value of true > >> indicates the object is offline. In order to set or clear the > >> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES > >> permission or the PRIV_FILE_OWNER privilege. In the kernel, it > >> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user > >> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). > >> No changes are required to the VOP or fgetattr(3C) function > >> prototypes. > > > >An HSM does not want the file's owner to twiddle this status. That status > >should be controlled by the HSM. > > The file system can return EACCES or EPERM if it doesn't want > the attribute changed via fsetattr(3C). > > I didn't want to preclude user space applications from being > able to manipulate this attribute on regular (non-HSM) file > systems. As I mentioned, a virus scanner could be configured > to mark the file as offline while it is performing a scan-on- > open. In that case, how would the virus scanner and the HSM interoperate on the same filesystem? Given your use-case, how would an HSM know when it can trust or use this bit? Dean From amw@sun.com Fri Aug 28 01:31:12 2009 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 n7S8VBaa029263 for ; Fri, 28 Aug 2009 01:31:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7S8V8JS029761; Fri, 28 Aug 2009 16:31:10 +0800 (SGT) 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 <0KP20040FVNWXH00@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 02:31:08 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP20065EVNV6NC0@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 02:31:08 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7S8V7Ix024467; Fri, 28 Aug 2009 08:31:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP200800V7DAO00@mail-amer.sun.com>; Fri, 28 Aug 2009 02:31:07 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP2006I5VNU4470@mail-amer.sun.com>; Fri, 28 Aug 2009 02:31:07 -0600 (MDT) Date: Fri, 28 Aug 2009 01:31:06 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A9664FE.1000304@sun.com> Sender: Alan.M.Wright@sun.com To: Joerg Barfurth Cc: Darren J Moffat , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A9795CA.7040804@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: <200908261555.n7QFtKc8028472@spidey.local> <4A956B97.3070505@Sun.COM> <4A95C644.8060909@sun.com> <4A9664FE.1000304@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 513 On 08/27/09 03:50, Joerg Barfurth wrote: > Alan M Wright schrieb: > >> [...] SAMFS already has >> something like this but it is a private interface. This case is >> intended to make an offline bit available as a generic, public >> interface. >> > > This is at odds with your Exported Interfaces table, which indicates > that all new interfaces are introduced as 'Consolidation Private'. I was referring to ls(1), chmod(1) and fgetattr(3C). A_OFFLINE and XAT_OFFLINE attributes consolidation private. Alan From amw@sun.com Fri Aug 28 01:42:42 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 n7S8ggIN029581 for ; Fri, 28 Aug 2009 01:42:42 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7S8gfFF005748; Fri, 28 Aug 2009 01:42:41 -0700 (PDT) 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 <0KP20030RW75D300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 28 Aug 2009 01:42:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200LHXW746L20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 28 Aug 2009 01:42:41 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7S8ge9T022570; Fri, 28 Aug 2009 08:42:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP200F00W6D6O00@mail-amer.sun.com>; Fri, 28 Aug 2009 02:42:40 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP2006J1W734470@mail-amer.sun.com>; Fri, 28 Aug 2009 02:42:40 -0600 (MDT) Date: Fri, 28 Aug 2009 01:42:39 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <20090827201706.GA8760@kickball-mn.central.sun.com> Sender: Alan.M.Wright@sun.com To: Dean Roehrich Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A97987F.2060300@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: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2465 On 08/27/09 13:17, Dean Roehrich wrote: > On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: >> On 08/26/09 14:33, Dean Roehrich wrote: >>> On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: >>>> The offline attribute (XAT_OFFLINE) will be added to the read- >>>> write system attributes view defined in PSARC/2007/315 and will be >>>> generally available to file systems and applications to indicate >>>> the offline/online status of objects: boolean value of true >>>> indicates the object is offline. In order to set or clear the >>>> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES >>>> permission or the PRIV_FILE_OWNER privilege. In the kernel, it >>>> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user >>>> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). >>>> No changes are required to the VOP or fgetattr(3C) function >>>> prototypes. >>> An HSM does not want the file's owner to twiddle this status. That status >>> should be controlled by the HSM. >> The file system can return EACCES or EPERM if it doesn't want >> the attribute changed via fsetattr(3C). >> >> I didn't want to preclude user space applications from being >> able to manipulate this attribute on regular (non-HSM) file >> systems. As I mentioned, a virus scanner could be configured >> to mark the file as offline while it is performing a scan-on- >> open. > > In that case, how would the virus scanner and the HSM interoperate on the same > filesystem? I think that's outside the scope of this case - that would be a design consideration for those components. And there's already a potential interaction problem between virus scanning and HSM: virus scanners may keep pulling files onto primary storage if poorly configured. Perhaps a well-designed virus scanner would recognize when the offline bit is already set and not attempt to scan files during background/scheduled scanning, and perhaps it's a bad idea for a virus scanner to manipulate the offline bit. Hopefully, these are application specific design problems that we have to solve here. > Given your use-case, how would an HSM know when it can trust or use this bit? If an HSM is managing the offline bit it can simply return EPERM if anything external to the HSM tries to change the state of that attribute. Nothing here requires that a file system or HSM allow the offline attribute to be changed outside of its control. Alan From amw@sun.com Fri Aug 28 01:45:15 2009 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 n7S8jElf029641 for ; Fri, 28 Aug 2009 01:45:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7S8jDnw006199; Fri, 28 Aug 2009 16:45:13 +0800 (SGT) 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 <0KP200J0LWBBPE00@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 01:45:11 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200FEJWBB2C60@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 01:45:11 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7S8jBux023401; Fri, 28 Aug 2009 08:45:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP200000W2DI400@mail-amer.sun.com>; Fri, 28 Aug 2009 02:45:11 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP2002UWWBA2480@mail-amer.sun.com>; Fri, 28 Aug 2009 02:45:11 -0600 (MDT) Date: Fri, 28 Aug 2009 01:45:10 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A97987F.2060300@sun.com> Sender: Alan.M.Wright@sun.com To: Dean Roehrich Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A979916.5050704@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: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2733 On 08/28/09 01:42, Alan M Wright wrote: > On 08/27/09 13:17, Dean Roehrich wrote: >> On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: >>> On 08/26/09 14:33, Dean Roehrich wrote: >>>> On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: >>>>> The offline attribute (XAT_OFFLINE) will be added to the read- >>>>> write system attributes view defined in PSARC/2007/315 and will be >>>>> generally available to file systems and applications to indicate >>>>> the offline/online status of objects: boolean value of true >>>>> indicates the object is offline. In order to set or clear the >>>>> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES >>>>> permission or the PRIV_FILE_OWNER privilege. In the kernel, it >>>>> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user >>>>> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). >>>>> No changes are required to the VOP or fgetattr(3C) function >>>>> prototypes. >>>> An HSM does not want the file's owner to twiddle this status. That >>>> status >>>> should be controlled by the HSM. >>> The file system can return EACCES or EPERM if it doesn't want >>> the attribute changed via fsetattr(3C). >>> >>> I didn't want to preclude user space applications from being >>> able to manipulate this attribute on regular (non-HSM) file >>> systems. As I mentioned, a virus scanner could be configured >>> to mark the file as offline while it is performing a scan-on- >>> open. >> >> In that case, how would the virus scanner and the HSM interoperate on >> the same >> filesystem? > > I think that's outside the scope of this case - that would be a > design consideration for those components. And there's already > a potential interaction problem between virus scanning and HSM: > virus scanners may keep pulling files onto primary storage if > poorly configured. > > Perhaps a well-designed virus scanner would recognize when the > offline bit is already set and not attempt to scan files during > background/scheduled scanning, and perhaps it's a bad idea for > a virus scanner to manipulate the offline bit. Hopefully, these > are application specific design problems that we have to solve > here. Sorry, Hopefully, these are application specific design problems that we _don't_ have to solve here. Alan >> Given your use-case, how would an HSM know when it can trust or use >> this bit? > > If an HSM is managing the offline bit it can simply return EPERM > if anything external to the HSM tries to change the state of that > attribute. Nothing here requires that a file system or HSM allow > the offline attribute to be changed outside of its control. > > Alan > From roehrich@kickball-mn.Central.Sun.COM Fri Aug 28 07:31:40 2009 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 n7SEVdAi013469 for ; Fri, 28 Aug 2009 07:31:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7SEVZIJ024591; Fri, 28 Aug 2009 15:31:37 +0100 (BST) 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 <0KP300J1JCCNEE00@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 08:31:35 -0600 (MDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP300FRUCCNMP20@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 08:31:35 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7SEVYYm003066; Fri, 28 Aug 2009 08:31:34 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id n7SEO56W011403; Fri, 28 Aug 2009 09:24:05 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id n7SEO5QE011402; Fri, 28 Aug 2009 09:24:05 -0500 (CDT) Date: Fri, 28 Aug 2009 09:24:05 -0500 From: Dean Roehrich Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A97987F.2060300@sun.com> To: Alan M Wright Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <20090828142404.GA11323@kickball-mn.central.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 3341 On Fri, Aug 28, 2009 at 01:42:39AM -0700, Alan M Wright wrote: > On 08/27/09 13:17, Dean Roehrich wrote: > >On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: > >>On 08/26/09 14:33, Dean Roehrich wrote: > >>>On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: > >>>> The offline attribute (XAT_OFFLINE) will be added to the read- > >>>> write system attributes view defined in PSARC/2007/315 and will be > >>>> generally available to file systems and applications to indicate > >>>> the offline/online status of objects: boolean value of true > >>>> indicates the object is offline. In order to set or clear the > >>>> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES > >>>> permission or the PRIV_FILE_OWNER privilege. In the kernel, it > >>>> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user > >>>> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). > >>>> No changes are required to the VOP or fgetattr(3C) function > >>>> prototypes. > >>>An HSM does not want the file's owner to twiddle this status. That > >>>status > >>>should be controlled by the HSM. > >>The file system can return EACCES or EPERM if it doesn't want > >>the attribute changed via fsetattr(3C). > >> > >>I didn't want to preclude user space applications from being > >>able to manipulate this attribute on regular (non-HSM) file > >>systems. As I mentioned, a virus scanner could be configured > >>to mark the file as offline while it is performing a scan-on- > >>open. > > > >In that case, how would the virus scanner and the HSM interoperate on the > >same > >filesystem? > > I think that's outside the scope of this case - that would be a > design consideration for those components. And there's already > a potential interaction problem between virus scanning and HSM: > virus scanners may keep pulling files onto primary storage if > poorly configured. > > Perhaps a well-designed virus scanner would recognize when the > offline bit is already set and not attempt to scan files during > background/scheduled scanning, and perhaps it's a bad idea for > a virus scanner to manipulate the offline bit. Hopefully, these > are application specific design problems that we have to solve > here. > > >Given your use-case, how would an HSM know when it can trust or use this > >bit? > > If an HSM is managing the offline bit it can simply return EPERM > if anything external to the HSM tries to change the state of that > attribute. Nothing here requires that a file system or HSM allow > the offline attribute to be changed outside of its control. Customers will write applications (maybe a file browser) which query this bit, and they'll file bugs against the HSM products for not setting it. The HSM products will then be in a bind because they know they can't use it as specified (at a minimum, they would have to modify fsetattr to no longer allow the setting of that bit, which would break some other customer's home-grown application...and so it goes). So here's how this case _could_ have been presented, given that it's supposed to displace PSARC/2009/381: You introduce XAT_OFFLINE, which is owned by the HSM. The virus scanner must honor this bit and avoid scanning offline files (there, now your virus scanner won't screw up the HSM resource management policy). Dean From amw@sun.com Fri Aug 28 12:44:46 2009 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 n7SJijoO004870 for ; Fri, 28 Aug 2009 12:44:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7SJiXU9008138; Fri, 28 Aug 2009 20:44:44 +0100 (BST) 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 <0KP300503QUHKL00@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 13:44:41 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP300DOGQUHJA90@brm-avmta-1.central.sun.com>; Fri, 28 Aug 2009 13:44:41 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7SJif1R022513; Fri, 28 Aug 2009 19:44:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP300M00QLN2Y00@mail-amer.sun.com>; Fri, 28 Aug 2009 13:44:40 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP3002XGQUGZ800@mail-amer.sun.com>; Fri, 28 Aug 2009 13:44:40 -0600 (MDT) Date: Fri, 28 Aug 2009 12:44:39 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <20090828142404.GA11323@kickball-mn.central.sun.com> Sender: Alan.M.Wright@sun.com To: Dean Roehrich Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <4A9833A7.3040005@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: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> <20090828142404.GA11323@kickball-mn.central.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 4045 On 08/28/09 07:24, Dean Roehrich wrote: > On Fri, Aug 28, 2009 at 01:42:39AM -0700, Alan M Wright wrote: >> On 08/27/09 13:17, Dean Roehrich wrote: >>> On Wed, Aug 26, 2009 at 04:40:41PM -0700, Alan M Wright wrote: >>>> On 08/26/09 14:33, Dean Roehrich wrote: >>>>> On Wed, Aug 26, 2009 at 09:55:20AM -0600, Tim Haley wrote: >>>>>> The offline attribute (XAT_OFFLINE) will be added to the read- >>>>>> write system attributes view defined in PSARC/2007/315 and will be >>>>>> generally available to file systems and applications to indicate >>>>>> the offline/online status of objects: boolean value of true >>>>>> indicates the object is offline. In order to set or clear the >>>>>> offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES >>>>>> permission or the PRIV_FILE_OWNER privilege. In the kernel, it >>>>>> will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user >>>>>> space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). >>>>>> No changes are required to the VOP or fgetattr(3C) function >>>>>> prototypes. >>>>> An HSM does not want the file's owner to twiddle this status. That >>>>> status >>>>> should be controlled by the HSM. >>>> The file system can return EACCES or EPERM if it doesn't want >>>> the attribute changed via fsetattr(3C). >>>> >>>> I didn't want to preclude user space applications from being >>>> able to manipulate this attribute on regular (non-HSM) file >>>> systems. As I mentioned, a virus scanner could be configured >>>> to mark the file as offline while it is performing a scan-on- >>>> open. >>> In that case, how would the virus scanner and the HSM interoperate on the >>> same >>> filesystem? >> I think that's outside the scope of this case - that would be a >> design consideration for those components. And there's already >> a potential interaction problem between virus scanning and HSM: >> virus scanners may keep pulling files onto primary storage if >> poorly configured. >> >> Perhaps a well-designed virus scanner would recognize when the >> offline bit is already set and not attempt to scan files during >> background/scheduled scanning, and perhaps it's a bad idea for >> a virus scanner to manipulate the offline bit. Hopefully, these >> are application specific design problems that we have to solve >> here. >> >>> Given your use-case, how would an HSM know when it can trust or use this >>> bit? >> If an HSM is managing the offline bit it can simply return EPERM >> if anything external to the HSM tries to change the state of that >> attribute. Nothing here requires that a file system or HSM allow >> the offline attribute to be changed outside of its control. > > Customers will write applications (maybe a file browser) which query this bit, > and they'll file bugs against the HSM products for not setting it. And perhaps that's appropriate because this case is an action item from PSARC/2009/381 to introduce this attribute. > The HSM > products will then be in a bind because they know they can't use it as > specified (at a minimum, they would have to modify fsetattr to no longer allow > the setting of that bit, which would break some other customer's home-grown > application...and so it goes). There is absolutely no need to modify fsetattr() in this way, and it would be wrong to apply or enforce policy in fsetattr(). fsetattr() is just a conduit. As I said previously, the HSM or file system can return EPERM. > So here's how this case _could_ have been presented, given that it's supposed > to displace PSARC/2009/381: This case is not displacing PSARC/2009/381. > You introduce XAT_OFFLINE, which is owned by the > HSM. The virus scanner must honor this bit and avoid scanning offline files > (there, now your virus scanner won't screw up the HSM resource management > policy). I think you're distracted by this hypothetical HSM/virus scanning interaction but it's not relevant here. An HSM or file system can easily reject attempts to manipulate the offline attribute. This is a non-issue. Alan From amw@Sun.COM Fri Aug 28 13:05:35 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 n7SK5Z9H005436 for ; Fri, 28 Aug 2009 13:05:35 -0700 (PDT) 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.2) with ESMTP id n7SK5Xap001265; Fri, 28 Aug 2009 14:05:35 -0600 (MDT) 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 <0KP300J0LRTAVJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 13:05:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP300JF2RT9GE00@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Aug 2009 13:05:34 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7SK5X2D000709; Fri, 28 Aug 2009 20:05:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP300I00RA6B800@mail-amer.sun.com>; Fri, 28 Aug 2009 14:05:33 -0600 (MDT) Received: from [10.1.106.211] ([unknown] [10.1.106.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP3000EART1B130@mail-amer.sun.com>; Fri, 28 Aug 2009 14:05:26 -0600 (MDT) Date: Fri, 28 Aug 2009 13:05:25 -0700 From: Alan M Wright Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A9664FE.1000304@sun.com> Sender: Alan.M.Wright@Sun.COM To: Joerg Barfurth Cc: Darren J Moffat , PSARC-ext@Sun.COM, cifs-eng@Sun.COM Message-id: <4A983885.2060302@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_MP6MgStwT0JHbfb5XtNsDw)" X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <4A956B97.3070505@Sun.COM> <4A95C644.8060909@sun.com> <4A9664FE.1000304@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 6073 This is a multi-part message in MIME format. --Boundary_(ID_MP6MgStwT0JHbfb5XtNsDw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 08/27/09 03:50, Joerg Barfurth wrote: > Alan M Wright schrieb: > >> [...] SAMFS already has >> something like this but it is a private interface. This case is >> intended to make an offline bit available as a generic, public >> interface. >> > > This is at odds with your Exported Interfaces table, which indicates > that all new interfaces are introduced as 'Consolidation Private'. Proposed updates attached to change the A_OFFLINE to committed. Question for the PSARC committee: The fgetattr(3C) man page lists the interface as committed (which is fine) but PSARC/2007/315 lists the A_... attributes as consolidation private. Is any action required to update the classification for those attributes. Alan --Boundary_(ID_MP6MgStwT0JHbfb5XtNsDw) Content-type: text/plain; name=offline.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=offline.txt 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: Offline attribute 1.2. Name of Document Author/Supplier: Author: Alan Wright 1.3 Date of This Document: 28 August, 2009 4. Technical Description 4.1. Details: This case proposes a new system attribute to support offline files as a generic solution to the proposal in PSARC/2009/381 Support off-line files on SAM-QFS for Samba in Solaris. PSARC/2009/381 provides a specific solution for the use of Samba with SAM-FS that depends on libsamfs, which is delivered by the SUNWsamfsr and SUNWsamfsu packages. The system attribute interface is described in: PSARC/2007/315 Extensible Attribute Interfaces. Associated changes to chmod(1) and ls(1) are described in: PSARC/2007/410 Add system attribute to chmod PSARC/2007/394 ls(1) '-/' and '-%' options for system attributes The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes defined in PSARC/2007/315 and will be generally available to file systems and applications to indicate the offline/online status of objects: boolean value of true indicates the object is offline. In order to set or clear the offline attribute the consumer must have the ACE_WRITE_ATTRIBUTES permission or the PRIV_FILE_OWNER privilege. In the kernel, it will be accessible via VOP_GETATTR() and VOP_SETATTR(). In user space, it will be accessible via chmod(1), ls(1) and fgetattr(3C). No changes are required to the VOP or fgetattr(3C) function prototypes. 4.6. Doc Impact: Modifications to the chmod(1) man page: Table 1: Attribute Names and Abbreviation Characters Attribute Name Attribute Abbreviation Character -------------- -------------------------------- + offline O Modifications to the ls(1) man page: -/ c | v + offline - Attribute to indicate that a file is offline. The display characters used in compact mode (-/ c) are as follows: Attribute Name Display + offline O The display positions are as follows: ! {|||||||||||} + ||||||||||+- O (offline) ! |||||||||+-- u (nounlink) ! ||||||||+--- q (av_quarantined) ! |||||||+---- m (av_modified) ! ||||||+----- i (immutable) ! |||||+------ d (nodump) ! ||||+------- a (appendonly) ! |||+-------- S (system) ! ||+--------- R (readonly) ! |+---------- H (hidden) ! +----------- A (archive) Modifications to the fgetattr(3C) man page: View Attribute Data type _______________________________________________________________ XATTR_VIEW_READWRITE ... + A_OFFLINE boolean_value 5. Exported Interface Table |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== | |This | | |Document | | | | A_OFFLINE |Committed | | Added to read-write | | | view of extended | | | attribute namespace | | | | | | XAT_OFFLINE |Consolidation | | Value for offline |Private | | system attribute 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 --Boundary_(ID_MP6MgStwT0JHbfb5XtNsDw) Content-type: text/x-patch; name=offline.diff Content-transfer-encoding: 7BIT Content-disposition: inline; filename=offline.diff --- offline_v1.txt Fri Aug 28 12:56:19 2009 +++ offline.txt Fri Aug 28 13:01:09 2009 @@ -6,7 +6,7 @@ 1.2. Name of Document Author/Supplier: Author: Alan Wright 1.3 Date of This Document: - 11 August, 2009 + 28 August, 2009 4. Technical Description 4.1. Details: @@ -22,8 +22,8 @@ PSARC/2007/315 Extensible Attribute Interfaces. Associated changes to chmod(1) and ls(1) are described in: - PSARC/2007410 Add system attribute to chmod - PSARC/2007394 ls(1) '-/' and '-%' options for system attributes + PSARC/2007/410 Add system attribute to chmod + PSARC/2007/394 ls(1) '-/' and '-%' options for system attributes The offline attribute (XAT_OFFLINE) will be added to the read- write system attributes defined in PSARC/2007/315 and will be @@ -89,16 +89,16 @@ |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== - |Consolidation |This | - |Private |Document | + | |This | + | |Document | | | | -A_OFFLINE | | | Added to read-write +A_OFFLINE |Committed | | Added to read-write | | | view of extended | | | attribute namespace | | | | | | -XAT_OFFLINE | | | Value for offline - | | | system attribute +XAT_OFFLINE |Consolidation | | Value for offline + |Private | | system attribute 6. Resources and Schedule --Boundary_(ID_MP6MgStwT0JHbfb5XtNsDw)-- From roehrich@kickball-mn.Central.Sun.COM Mon Aug 31 07:21:55 2009 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 n7VELsF0010594 for ; Mon, 31 Aug 2009 07:21:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7VELnmm000482; Mon, 31 Aug 2009 22:21:51 +0800 (SGT) 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 <0KP800L0VVWD7H00@brm-avmta-1.central.sun.com>; Mon, 31 Aug 2009 08:21:49 -0600 (MDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP800BVPVWD9A80@brm-avmta-1.central.sun.com>; Mon, 31 Aug 2009 08:21:49 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7VELmt0049796; Mon, 31 Aug 2009 08:21:48 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id n7VEEJO8019013; Mon, 31 Aug 2009 09:14:19 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id n7VEEJK9019012; Mon, 31 Aug 2009 09:14:19 -0500 (CDT) Date: Mon, 31 Aug 2009 09:14:19 -0500 From: Dean Roehrich Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A9833A7.3040005@sun.com> To: Alan M Wright Cc: Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <20090831141419.GA18948@kickball-mn.central.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> <20090828142404.GA11323@kickball-mn.central.sun.com> <4A9833A7.3040005@sun.com> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 950 On Fri, Aug 28, 2009 at 12:44:39PM -0700, Alan M Wright wrote: > >Customers will write applications (maybe a file browser) which query this > >bit, > >and they'll file bugs against the HSM products for not setting it. > > And perhaps that's appropriate because this case is an action > item from PSARC/2009/381 to introduce this attribute. Okay, granted, this thing is just a conduit and fsetattr() can ask the HSM, at each call, what value should be used. I'm still not understanding why the file's owner should have the ability to set this bit. What would be the purpose of that? It makes me question whether this bit has any specific meaning. > I think you're distracted by this hypothetical HSM/virus scanning > interaction but it's not relevant here. An HSM or file system > can easily reject attempts to manipulate the offline attribute. > This is a non-issue. Yes, it was a surpise to me that a non-HSM use-case was presented. Dean From Richard.Matthews@sun.com Mon Aug 31 09:42:53 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 n7VGgrYB021167 for ; Mon, 31 Aug 2009 09:42:53 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7VGgrn6014589; Mon, 31 Aug 2009 09:42:53 -0700 (PDT) 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 <0KP9004032FGJI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 31 Aug 2009 09:42:52 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP90048M2FGCG00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 31 Aug 2009 09:42:52 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7VGgqJ6013711; Mon, 31 Aug 2009 16:42:52 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP900E002BHAX00@mail-amer.sun.com>; Mon, 31 Aug 2009 10:42:52 -0600 (MDT) Received: from [129.152.9.14] ([unknown] [129.152.9.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP9001UJ2EJRC30@mail-amer.sun.com>; Mon, 31 Aug 2009 10:42:34 -0600 (MDT) Date: Mon, 31 Aug 2009 11:42:19 -0500 From: Rick Matthews Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <20090831141419.GA18948@kickball-mn.central.sun.com> Sender: Richard.Matthews@sun.com To: Dean Roehrich Cc: Alan M Wright , Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <4A9BFD6B.4000201@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TUMSGlGvIbG3tljbFh51aw)" X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> <20090828142404.GA11323@kickball-mn.central.sun.com> <4A9833A7.3040005@sun.com> <20090831141419.GA18948@kickball-mn.central.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 7506 This is a multi-part message in MIME format. --Boundary_(ID_TUMSGlGvIbG3tljbFh51aw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 08/31/09 09:14 AM, Dean Roehrich wrote: > On Fri, Aug 28, 2009 at 12:44:39PM -0700, Alan M Wright wrote: > >>> Customers will write applications (maybe a file browser) which query this >>> bit, >>> and they'll file bugs against the HSM products for not setting it. >>> >> And perhaps that's appropriate because this case is an action >> item from PSARC/2009/381 to introduce this attribute. >> > > Okay, granted, this thing is just a conduit and fsetattr() can ask the HSM, at > each call, what value should be used. > > I'm still not understanding why the file's owner should have the ability to > set this bit. What would be the purpose of that? It makes me question > whether this bit has any specific meaning. > > > >> I think you're distracted by this hypothetical HSM/virus scanning >> interaction but it's not relevant here. An HSM or file system >> can easily reject attempts to manipulate the offline attribute. >> This is a non-issue. >> > > Yes, it was a surpise to me that a non-HSM use-case was presented. > > Dean > Dean and Alan, I've been following this case, and tend to agree with Alan. Here is why. The introduction of an externalized (user available) status to indicate that a file may not be accessible immediately is of value. I think we all agree here. Particularly since it fits into the existing framework. Where the issue under discussion is whether the architecture behind the flag is sufficient. Dean, from the HSM point of view, is viewing the flag as an HSM attribute. Alan is looking at the attribute as a generic mechanism to communicate the state to a user or users process. Dean correctly points out that the HSM needs an indisputable mechanism for tracking its state, that the user cannot muck with. Alan argues that this bit isn't for that purpose. I can rationalize how an HSM and a "file system state" process like virus scan could use the same flag. If either are indicating delayed availability is likely, return the flag as set. Where we could use the "user" process controlled visualization of the flag (some yet to be determined application), the fsetattr() can be used. I don't see (and I think this is where Dean sees incomplete architecture) how we can keep that flag persistent, if a kernel level consumer (HSM, virus scan, ...) is causing it to reflect internal (FS specific) state on each query. That is, if application X fsetattr() the state to off-line, and the file was also under HSM control, I think a query of the attribute will query the HSM portion and clear the attribute, if the file is on-line. This detail may be sketchy, but the persistence of a fsetattr() set flag may be questionable. I can live with this. -- Rick -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_TUMSGlGvIbG3tljbFh51aw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 08/31/09 09:14 AM, Dean Roehrich wrote: 
On Fri, Aug 28, 2009 at 12:44:39PM -0700, Alan M Wright wrote:
  
Customers will write applications (maybe a file browser) which query this 
bit,
and they'll file bugs against the HSM products for not setting it.
      
And perhaps that's appropriate because this case is an action
item from PSARC/2009/381 to introduce this attribute.
    

Okay, granted, this thing is just a conduit and fsetattr() can ask the HSM, at
each call, what value should be used.

I'm still not understanding why the file's owner should have the ability to
set this bit.  What would be the purpose of that?  It makes me question
whether this bit has any specific meaning.


  
I think you're distracted by this hypothetical HSM/virus scanning
interaction but it's not relevant here.  An HSM or file system
can easily reject attempts to manipulate the offline attribute.
This is a non-issue.
    

Yes, it was a surpise to me that a non-HSM use-case was presented.

Dean
Dean and Alan,
  I've been following this case, and tend to agree with Alan. Here is
why. The introduction of an externalized (user available) status to indicate
that a file may not be accessible immediately is of value. I think we all agree
here. Particularly since it fits into the existing framework.
  Where the issue under discussion is whether the architecture behind the flag is
sufficient. Dean, from the HSM point of view, is viewing the flag as an HSM
attribute. Alan is looking at the attribute as a generic mechanism to communicate
the state to a user or users process. Dean correctly points out that the HSM needs
an indisputable mechanism for tracking its state, that the user cannot muck with.
Alan argues that this bit isn't for that purpose.
  I can rationalize how an HSM and a "file system state" process like virus scan could
use the same flag. If either are indicating delayed availability is likely, return the
flag as set.
  Where we could use the "user" process controlled visualization of the flag (some yet
to be determined application), the fsetattr() can be used. I don't see (and I think this
is where Dean sees incomplete architecture) how we can keep that flag persistent, if a
kernel level consumer (HSM, virus scan, ...) is causing it to reflect internal (FS specific)
state on each query. That is, if application X fsetattr() the state to off-line, and the
file was also under HSM control, I think a query of the attribute will query the HSM portion
and clear the attribute, if the file is on-line. This detail may be sketchy, but the
persistence of a fsetattr() set flag may be questionable. I can live with this.
--
Rick
 
-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_TUMSGlGvIbG3tljbFh51aw)-- From roehrich@kickball-mn.Central.Sun.COM Tue Sep 1 13:04: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 n81K4JHR019279 for ; Tue, 1 Sep 2009 13:04:19 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81K4GFg008784; Tue, 1 Sep 2009 13:04:18 -0700 (PDT) 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 <0KPB00J2T6F4NX00@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 14:04:16 -0600 (MDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00B406F34J60@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 14:04:15 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81K4Fg2044807; Tue, 01 Sep 2009 14:04:15 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id n81JujCP024593; Tue, 01 Sep 2009 14:56:45 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id n81JujJm024592; Tue, 01 Sep 2009 14:56:45 -0500 (CDT) Date: Tue, 01 Sep 2009 14:56:45 -0500 From: Dean Roehrich Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <4A9BFD6B.4000201@Sun.COM> To: Rick Matthews Cc: Alan M Wright , Tim Haley , PSARC-ext@sun.com, cifs-eng@sun.com Message-id: <20090901195645.GA24565@kickball-mn.central.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908261555.n7QFtKc8028472@spidey.local> <20090826213315.GA4704@kickball-mn.central.sun.com> <4A95C7F9.4000304@sun.com> <20090827201706.GA8760@kickball-mn.central.sun.com> <4A97987F.2060300@sun.com> <20090828142404.GA11323@kickball-mn.central.sun.com> <4A9833A7.3040005@sun.com> <20090831141419.GA18948@kickball-mn.central.sun.com> <4A9BFD6B.4000201@Sun.COM> User-Agent: Mutt/1.5.9i Status: RO Content-Length: 1100 On Mon, Aug 31, 2009 at 11:42:19AM -0500, Rick Matthews wrote: > Dean and Alan, > I've been following this case, and tend to agree with Alan. Here is > why. The introduction of an externalized (user available) status to indicate > that a file may not be accessible immediately is of value. I think we > all agree > here. Particularly since it fits into the existing framework. > Where the issue under discussion is whether the architecture behind > the flag is > sufficient. Dean, from the HSM point of view, is viewing the flag as an HSM > attribute. In this note, including the bits I've not quoted, I believe Rick has accurately stated my concerns. I've had a few conversations with him since this case was submitted and I did promise him that if I couldn't present an argument that would persuade him to derail it, or Alan to modify it, that I'd take that as an indication that I'm on the wrong track. I have no further objections, and I seem to have run out of my magic Persuasion powder. I think this bit will be good for the HSM products, so we'll take the good and run with it. Dean From tim.haley@sun.com Wed Sep 2 10:15:49 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 n82HFnBj002021 for ; Wed, 2 Sep 2009 10:15:49 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82HFjd6020322; Wed, 2 Sep 2009 10:15:48 -0700 (PDT) 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 <0KPC00707TAB8K00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 10:15:47 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC0019BTAB4AB0@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 10:15:47 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82HFleL008794; Wed, 02 Sep 2009 17:15:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00100SS1BL00@mail-amer.sun.com>; Wed, 02 Sep 2009 11:15:47 -0600 (MDT) Received: from [172.20.25.27] ([unknown] [172.20.25.27]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC003T9T9WDX50@mail-amer.sun.com>; Wed, 02 Sep 2009 11:15:32 -0600 (MDT) Date: Wed, 02 Sep 2009 11:15:32 -0600 From: Tim Haley Subject: Re: Offline attribute [PSARC/2009/464 FastTrack timeout 09/02/2009] In-reply-to: <200908261555.n7QFtKc8028472@spidey.local> Sender: Timothy.Haley@sun.com To: PSARC-ext@sun.com Cc: cifs-eng@sun.com Message-id: <4A9EA834.8070608@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: <200908261555.n7QFtKc8028472@spidey.local> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 55 This case was approved in today's PSARC meeting. -tim