> think > that for the most part, it so happens that the number of credits > reserved in > ext3_prepare_write is conservatively quite high and we can squeeze in > our > copy file without running out of credits, but sometimes we get unlucky > and > there aren't enough credits for copying. > As Erez said, we were nesting the copy operation between a prepare and > commit write. If instead, we do the copy before ext3_prepare_write and > not > bother ext3 between ext3_prepare_write and ext3_commit_write, we don't > run > into the --buffer_credit problem, since the copy operation will happen in > its > own transaction and will be allocated as many buffer credits as > required.
You might need to nest the transaction as well. What if power failure happen after backuping the file and before modify to original file? Dp you left the backup file around?
We do need to keep the backup file around since it is not really a backup file, but a version of the file
before it was changed. We do need to nest the transaction like you mentioned, but there does not seem
to be an easy way to do so without losing portability. Basically, we rely on the vfs ops to call the underlying
file system, so we cannot do explicit journal_start() since that would break the file system independence
property of our system.
We need to be careful to not perform file system operations that are specific to the semantics of one particular file
system. Is there any way that you suggest that can get us a nested transaction (through a VFS operation or an operation exposed by the file system to VFS) when there's a transaction already associated with the current process?
Chris
Cheers, Akshat Aranya SUNY, Stony Brook
_________________________________________________________________
Yearning for ol' pals? For ol' school days? http://www.batchmates.com/msn.asp Here's a surprise!
_______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
