Hi, > Could you rephrase the above? I dont think I understand what it means.. Sorry for the weird phrases. I give it a new shot from the clients point of view. At the beginning of an I/O request the client already requests the files array of datafiles from the metadata server. Now the I/O starts in parallel to all participating dataservers. If one dataserver returns the error ENOENT during the first acknowlege or during the flow this could be marked in the context struct of this I/O operation. Also the client could starts from init again, now it knows that either the I/O has to be retried or that at least one dataserver reports ENOENT. If one reported ENOENT then the client invalidates the acache entry. In addition the server could copy the old dfile array into a new one or just create a new one for the next steps. Now the client getattr sm fetches the datafile array again from the metaserver. For each I/O operation which reports ENOENT the client compares old datafile with the new datafile, if they match we know ENOENT is not caused by a migration, because in this case they have to be different.
(I know it is not completely guaranteed that the metadata server has rewritten the datafile location in the current implementation (it is very unlikely that it happen), but I will do so in the final implementation by adding another message exchange between metadata server and old dataserver) Enjoy the day, Julian _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
