![]() | |||||||||||||
Messages in this thread |
>>>>> Andrew Morton (AM) writes: AM> That worked fine on ext2. But on ext3 we have a transaction open in AM> prepare_write(), and the forced writeback will cause arbitrary amounts of AM> unexpected metadata to be pumped into the current transaction, causing the AM> fs to explode. why to open transaction for ->prepare_write()? as for me, it doesn't touch metadata to be stored on a disk. I've partial implemented following idea: ->prepare_write() recognizes are blocks being written holes or reserved. it they are holes and haven't reserved yet, then set a flag about this. note that ->prepare_write() doesn't look right place to put reservation in because copy_from_user() in generic_file_aio_write_nolock() may fail. ->commit_write() looks at that flag and if it's set tries to reserve blocks. if reservation fails then ->commit_write() returns -ENOSPC, ext3_file_write() recognizes this, requests flushing and wait for free space. ->invalidatepage() drops reservation if space for page still non-allocated ->writepages() and ->writepage() drop reservation upon real allocation I expect data=ordered mode to be very simple to implement: just put bio submited in ->writepages() on list for correspondend transaction and wait for completion of bio's in commit_transaction(). does this all make sense? thanks, Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | |||||||||||||