On Mon, Oct 19, 2015 at 12:52 PM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: >> 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. John _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |