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
