Jeff Layton wrote: > That's expected behavior. The kernel believes that the file is frozen in > length so it returns short read() calls until the size is updated. The "size is updated" means "stat() detects the growth of file size", doesn't it? Then, the former is expected behavior. > > cache=loose is very much not recommended for use when you have multiple > hosts accessing files on the server (or access by processes on the > server itself). It only gives you "loose" cache coherency. The whole > point of it is to allow the client to cache data even when the protocol > says that it shouldn't. But why is the latter ( "read() returns non-0 when stat() detects the growth of file size but the data actually read is '\0'" ) is expected behavior? It sounds like a bug that the client caches '\0' (data nobody has ever wrote) instead of '.' (data somebody wrote when the file size grew). > > cache=strict is what is recommended and that's the default these days. Yes, I suggested a customer using CIFS on RHEL6 to use cache=none or cache=strict , for that customer's system does not work as expected due to the latter behavior when using "tail -f" for checking for appended log. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
