Bryan Henderson wrote: >>So, semantics of ->sync_page() are roughly "kick underlying storage >>driver to actually perform all IO queued for this page, and, maybe, for >>other pages on this device too". > > > I prefer to think of it in a more modular sense. To preserve modularity, > the caller of sync_page() can't know anything about I/O scheduling. So I > think the semantics of ->sync_page() are "Someone is about to wait for the > results of the previously requested write_page on this page." It's > completely up to the owner of the address space to figure out what would > be appropriate to do given that information.
Though I agree with your desire for a "modular" interpretation, I'm going disagree your description of the information sync_page() provides. Nikita's vague description is closer to the truth because sync_page() is vague. If you follow the callers of sync_page() you quickly find that what it *really* means to be called in sync_page() is that you're being told that some process is about to block on that page. For what reason, you can't know from the call alone. Waiting for read to complete and unlock? Waiting for writeback to clear the writeback bit? Some processes just happened to race to lock_page() on the same page for reasons that have nothing to do with IO? And the not-so-initiated might think that sync_page() is called with the page lock just like the other ops. That's obviously not the case, as it is called when the page lock can't be acquired, but it makes actually *doing* something with that page argument perilous. Synchronization is left to the sync_page() callee. For example, cachefs seems to be among the very few who don't provide block_sync_page() directly. All it does is printk() and then call block_sync_page(). In that single line of code it derefs page->mapping without checking and so can probably fatally race with truncation and the nulling of page->mapping. - z - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
