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 at opensolaris.org
