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