My company uses a central file server for building its software products. There's a CIFS share where all the header files and compilers are stored (to avoid version mismatches on different developer machines). While building the project it will handle lots of #include directives. Every time the whole header file is sucked over the network, maintaining a 6-8Mb/s (on a 100MBit network) constant network stream. Things become even worse when several developers build the project at the same time. If all files are stored locally, the build times becomes a lot faster (by a factor of 4-6, if not more). The bottleneck here is the network, which is used very ineffective because same data is sent thousands of times over and over to the same client. From what I have read from the manual page, cifs.ko will cache file data while it's opened. However, the cache is thrown out as soon as the file is closed. Since most C compilers will repeatedly open/close the same file, it won't gather almost anything from this kind of caching. It would be very nice if cifs.ko would keep the cache after the file is closed. At the time of open it could ask the server if the file has changed in meantime, if not - the old cache can be reused. If asking the server is not possible, this could be implemented, for example, by checking if the file time/size has changed. Of course, these cached data would be pushed out of memory as soon as memory manager asks to free some more memory.
> > From what I have read from the manual page, cifs.ko will cache file data while > it's opened. However, the cache is thrown out as soon as the file is closed. > Since most C compilers will repeatedly open/close the same file, it won't > gather almost anything from this kind of caching. > > It would be very nice if cifs.ko would keep the cache after the file is closed. > At the time of open it could ask the server if the file has changed in > meantime, if not - the old cache can be reused. If asking the server is not > possible, this could be implemented, for example, by checking if the file > time/size has changed. Of course, these cached data would be pushed out of > memory as soon as memory manager asks to free some more memory. If the manpage says this, then it's wrong. By default it does cache data after a close and check for changes on reopen, but this is actually a violation of the protocol. The CIFS protocol mandates that you discard any cached data after a close (and also read and write around the cache if you don't have an oplock). I'm currently making a case that we should have stricter adherence to the protocol by default, but we'd continue to support the use-case you suggest via a mount option for the forseeable future. So, I'm not convinced you've correctly diagnosed the problem here. Also, cifs read and write performance was poor for many years, and only recently improved with the addition of async read/write support. Are you still seeing poor performance in more recent kernels?
It looks like things changed in the meantime, since 2008 :) I have inspected the network traffic now and I see only FIND_FIRST2 and QUERY_FS_INFO, SET_PATH_INFO operations during compilation. I remember I did the same back in 2008 and the traffic mainly consisted of header file pieces, thus I wrote this enhancement request. Also, I found the 'fsc' option, which will use the cachefilesd daemon for even bigger speed improvements, I'll try that too. But what I see is already much better than the situation in 2008. So, I think, this request can be closed. Thank you for your precious work!
Great, thanks for re-testing. Closing case with a resolution of INVALID since the original problem was never quite clear...