I have more questions about MDS caps. The File (F*) caps in cephfs are very granular, such that it's not clear what extra ability each one grants with respect to the others. Here's the list: #define CEPH_CAP_FILE_SHARED (CEPH_CAP_GSHARED << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_EXCL (CEPH_CAP_GEXCL << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_CACHE (CEPH_CAP_GCACHE << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_RD (CEPH_CAP_GRD << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_WR (CEPH_CAP_GWR << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_BUFFER (CEPH_CAP_GBUFFER << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_WREXTEND (CEPH_CAP_GWREXTEND << CEPH_CAP_SFILE) #define CEPH_CAP_FILE_LAZYIO (CEPH_CAP_GLAZYIO << CEPH_CAP_SFILE) My questions: 1) Why do we have SHARED and CACHE (and similarly EXCL and BUFFER)? Shouldn't one imply the other? Under what circumstances would you issue them independently of one another? 2) My understanding (quite possibly wrong) is that RD and WR are really there cover the validity of the file layout. Should SHARED/EXCL imply those as well? 3) Is WREXTEND deprecated? The client seems to ignore it. 4) LAZYIO is there, but its semantics are not documented at all, AFAICT. I get that it's supposed to relax ceph's caching semantics. Under what circumstances _should_ the client invalidate cached dentries and inodes when this is set? IOW, what are the lazyio "rules" ? Thanks again! -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
