Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: > One interesting use case that I didn't see David mention is for cluster > boot up. In a lot of the HPC clustered set-ups there tend be a number of > 'hot' files that all clients need to access at roughly the same time in > the boot cycle. Pre-loading these files into the persistent cache before > booting the cluster is one way to solve this problem. Server replication > and/or copying the files to local storage on the clients are other > solutions. I've come across something similar, where a large company was distributing /usr to its UNIX/Linux workstations by AFS without persistent local caching. Cue a powercut, that took away the power from a large quantity of machines and then brought it back again, at which point all the machines tried to boot... > The disadvantage is that cachefs doesn't yet appear to have a tool to select > those files that are hot and are therefore best suited to cache (please > correct me if I'm wrong, David). The fact that a file is 'hot' on some given > client is not necessarily equivalent to saying that it is hot on the server > and vice versa. Are there any plans to at some point introduce a tool to > manage the persistent cache? Yes. I have plans for tools to pin and unpin files, introduce culling priorities, make space reservations in the cache, and cache readahead. These aren't, however, immediately necessary to make local caching useful. To do this, ideally I want a set of ioctl, fcntl or fadvise commands that are common to all filesystems that will just be ignored if the filesystem isn't currently doing caching. Our customers also want to be able to configure this statically, perhaps in some /etc file. Something like, on NFS mount X from server Y, fully readahead all files in or under directory Z. I have an idea on how to do this, but I need to thrash it out with Al. David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
