From: Noveck, Dave (dave.noveck@netapp.com)
Date: 03/16/99-11:01:39 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA033034D8@TAHOE.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Volatile file handles Date: Tue, 16 Mar 1999 09:01:39 -0800 Brent Callaghan wrote: > Dave Noveck writes: > > The reason that a server might not want to simply put the > uniquifier > > into the filehandle and dispense with MAP_UNIQUIFIER_TO_FH > has to do with > > a couple of situations mentioned in the document, filesystem re- > > organization and HSM. In these cases, the preferred filehandle for > > an object is going to change. If the server is obliged to honor the > > old filehandle forever, the reorganization may not be > effective since > > you can never reclaim the old inode number, for example. > If you allow > > the server to declare the old handles expired and give the clients a > > guaranteed way to get new handles for a significant time, > you can make > > the filesystem re-organization effective immediately in a > way that is > > guaranteed to not to cause confusion for clients. The > worst that can > > happen is that a very old filehandle that is not used in > time will cause > > an error and there is no problem of file corruption. > > But user-level servers (that do not have uniquifiers or cannot > map them to file descriptors) cannot implement a MAP_UNIQUIFIER_TO_FH > procedure. Any server that can implement this procedure (like a UNIX > kernel server) could extract the uniquifier from the "old" filehandle > anyway. It could extract it from the file handle but it might not be the best way to do things. Certainly it is a possible implementation strategy to tag every object with a unique id which will never change and then incorporate this in the handle and then have the handle designate that object for all time. This the typical persistent file handle implementation. The problem is that you also typically include some index (e.g. an inode number) that enables you to find the disk representation of the file easily. File system re-organization can invalidate these indices and make it more difficult to map handles to the files they designate. One response to that situation is to allow file handles to change to incorporate a new index to find the file more easily in a reorganized file system. Having a file handle change is exactly what volatile file handles enable so I'm thinking of ways that this might be used. Given that we are going to some lengths to allow diffrently abled file systems to re-establish file handles from names (and that seems problematic), it seems to make sense to allow servers which can, to reliably map a unique id to a handle to do that to establish a new handle for an object. It's not a requirement. > > > > A similar situation arises when trying to move a tree of > files to another > > server (like an AFS volume). The handles on the new server > are going to > > be different. If you just use remapping via names then you > get corruption. > > If you verify the uniquifier then you avoid corruption but > may have to > > give back errors on files renamed from another client. The server > > implementation should have the option of mapping uniquifiers to new > > handles to avoid rename causing handles which are volatile > and cannot be > > restored (condensed?). > > The smart way to do this would be to have a portable filehandle > with a unique volume id in it, so that the filehandles wouldn't > have to change when the volume moved. > > However, if you're relocating data at less-than-volume granularity, > perhaps via a zipfile or tarball, then there's not many unique > attributes that you can rely on - especially uniquifiers. The problem is that you might want to allow an administrator to turn a tree into a logical volume without disruption to existing users. Allowing him to force file handles to change to have a new volume id would allow this to be done smoothgly.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:50 AM Z CST