Hi Julian, cc'ed dev list.
> Sort of. I already achieved to move one datafile to another server and update > the dfile array afterwards. The idea is to pasive update the location on the > clients due to failures on I/O requests. The new locations are not given back > from the dataserver to the clients instead the ENOENT signals to reget the > dfile array. The alternative of passing back the new locations requires to > store the information about the migration on the dataserver for a while which > I don't want to do. Hmm.. problem with ENOENT is how would you differentiate between migration and lost dfiles? What if you keep getting dfile array and retries with ENOENTS from the same server again and again? Will you conclude after the second retry that it is a corrupted FS? Perhaps, you could have an entry in the old server's dfile handle that explicitly says that this handle has been migrated? > > The other alternative as you suggest is let the server return ENOENT, and > > have the client talk to the MDS and do a getattr again to get the dfile > > handles and their locations (the assumption here being that the migration > > tool (server migration tool that is) does the right thing in updating the > > dspace of the meta file) > It does right now :) ok.. > The problem is the client handling... > > Given that a few client-side caches (ncache, acache) etc are now in the > > tree, we also need to think about adding some new error codes for stale > > handles, stale servers etc if we go about adding server migration? > I think the an invalidation of the acache entry and the reget would be > sufficient for my scenarios. ok. Murali _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
