Jeff Mahoney wrote:
After a superblock write failure, the buffer_head is marked !uptodate. Since the superblock is something of an exception -- read once and a reference kept for the duration of the mount -- it is by definition always uptodate.
Not if it has been modified and not yet written back to disk. Then it is dirty by definition.
This is somewhat academic for the most part until we encounter error conditions. For example, if a disk goes away in a SAN environment, the write failure will occur and it will be followed by others. ext3_error wants to mark the superblock dirty via ext3_commit_super, but once the first write fails, the subsequent mark_buffer_dirty calls will issue warnings because the buffer is not uptodate.
Why on earth is a warning issued for marking an already dirty buffer dirty again? Surly buffers can be modified again and thus, marked as dirty a second time before pdflush gets around to syncing them all the time.
+ set_buffer_uptodate(sbh); mark_buffer_dirty(sbh); if (sync) sync_dirty_buffer(sbh);
Are you sure this only matters when there is an IO error? It looks there like if !sync then the sb can continue to sit in memory marked as dirty for some time before someone tries to flush it to disk. Eventually can't we end up back through this code patch and calling mark_buffer_dirty again before it was ever flushed in the first place, even without an IO error?
-- 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
