On Jan 31, 2008 12:10 PM, Jeff Blaine <[EMAIL PROTECTED]> wrote: > Yes, /cache is an ext3 filesystem. > > Going back over zephyr logs, I find what Kris was doing. He said:
In essence, it seems to be possible that as AFS is flushing data to the server, and deletes the content of cache blocks, it tries to write new data immediately after deleting old data, and that the delete has not yet been committed to disk. In that case, the data blocks taken up by the deleted data are not released for reallocation yet, and thus while AFS thinks there is enough room left in the cache, there actually isn't. Note that if e.g. jbd-debug is enabled (in my case, at a level of 2 or more), enough extra work is being done by the kernel that the kjournald processing actually manages to do the commits before AFS demands the space, and thus it won't trigger the ENOSPC condition. How is that for a nice issue :) [...] Good news on that one is that Chas believes that just setting S_SYNC on the inode before truncation is probably a good thing on *any* filesystem on Linux, not just ext3, making the patch trivial. Testing scheduled for that (and potential impact, if any) later today. February 2005 timeframe. I suppose I should go look in RT; A look at osi_file.c on Linux yields only + filp->f_mode = FMODE_READ|FMODE_WRITE; in rev 1.24, which is probably related.
