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 at 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 ---------------------------------------------------------------------
