On Tue, 2006-10-03 at 14:15 -0700, Zach Brown wrote: > Steve French wrote: > > Dave Kleikamp wrote: > >>> Someone had reported a problem with a writepages call coming in on > >>> with no open files (so presumably the file was closed, with dirty > >>> pages not written). > > So is the problem that you're getting a cifs_writepages() call after > cifs_close() returns? If I understand Steve, the problem may be that cifs_writepages() is called after cifs_flush(). cifs_flush() is called earlier than cifs_close(). > fwiw, 9 out of 10 brains would be less confused if cifs_close() was > called cifs_release(). That confused me a bit, but I still would have missed the cifs_flush bit. > > May be a case in which filemap_fdatawrite returns before the write(s) is > > sent to the vfs and write races with close (although cifs will defer a > > file close if a write is pending on that handle)? > > Are writes to mmap()ed regions involved at all? They lead to pages > being dirtied at unmapping and eventually hitting ->writepage, > potentially after ->flush and ->release have been called. ->flush does filemap_fdatawrite(), which should take care of any dirty pages (I believe). > I imagine you could force writeback of dirty pages in ->release so that > you don't wait for writeback to come around and hit them. Heck, it > might be doing this already. I didn't look very hard :). ->flush does. I'm not sure about ->release. I'm not sure if a write could squeeze in between ->flush and ->release. -- David Kleikamp IBM Linux Technology Center - 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
