>>> So: the key thing to realise is that caching behaviour is full of >>> tradeoffs, and this is really something that needs to be tunable, so >>> that it can be adapted to the differing needs of different workloads. >>> Having an optional "hold onto caps for N seconds after file close" >>> sounds like it would be the right tunable for your use case, right? >>> >> >> I think that would help. Caching is pretty essential so we'd buy more >> MDS's and loads of RAM if CephFS became a central part of our >> infrastructure. >> >> But looking forward, if CephFS could support the immutable bit -- >> chattr +i <file> -- then maybe the MDS wouldn't need to track clients >> who have such files cached. (Immutable files would be useful for other >> reasons too, like archiving!) > > Hmm, if we didn't know which clients were accessing a +i file, then we > would have to do a global broadcast when we removed the attribute > (typically to delete the file), to tell all the clients to drop the > file from cache, and wait for a message from every client indicating > that they had dropped it. > > For example, if you had an immutable /usr/bin/foo, and someone had it > in their cache but the MDS didn't know they had it in their cache, > then when you upgraded that package (replaced the binary file with > another), the MDS wouldn't know who to tell that they should no longer > use the old instance of the file. > > More generally though, there probably are good cases where we should > do different caching behaviour on +i files, I hadn't really thought > about it before. if we are making wishlist, how about read cache support for cephfs snapshots? stijn > > John > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |