On Thu, 2011-08-04 at 12:03 -0400, J. Bruce Fields wrote: > On Thu, Aug 04, 2011 at 04:27:33AM -0700, Venkateswararao Jujjuri wrote: > > One of the usecase is rsync between two physical filesystems; but in > > this particular use case the export > > is readonly (rootfs). As trond mentioned Volatile FHs are fine in > > the case of readonly exports. > > Is it something we can consider for upstream? VFH only for readonly > > exports.? > > The client has no way of knowing that an export is read only. (Or that > the server guarantees the safety of looking up names again in the more > general cases Neil describes.) Unless we decide that a server is making > an implicit guarantee of that just by exposing volatile filehandles at > all. Doesn't sound like the existing spec really says that, though. NFSv4.1 introduces the 'fs_status' recommended attribute (see section 11.11 in RFC5661), which does, in fact, allow the client to deduce that an export is read-only/won't ever change. > If an examination of existing implementations and/or some sort of new > spec language could reassure us that servers will only ever expose > volatile filehandles when it's safe to do so, then maybe it would make > sense for the client to implement volatile filehandle recovery? > > But if there's a chance of "unsafe" servers out there, then it would > seem like a trap for the unwary user.... > > Your rootfs's probably aren't terribly large--could you copy around > compressed block-level images instead of doing rsync? Agreed. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
