Retaining undelete data on ext3
Bodo Thiesen
bothie at gmx.de
Sun Oct 8 21:38:22 UTC 2006
Theodore Tso <tytso at mit.edu> wrote:
> "In the next transaction" --- that's exactly the problem, as I said,
> in my earlier comment:
>
> You could if you forced transaction boundaries between every single
> indirect block, but that would seriously degrade ext3's unlink
> performance, and slow down any other filesystem activity that might be
> happenning at the same time.
>
> The way ext3 works is that we batch multiple operations into a single
> transaction. This is because commiting transactions is expensive, so
> we amortize the cost over potentially a large number of filesystem
> operations that might be happening very close together.
What does the journaling code, if a block x which was already written to in
a transaction get's written to again? What say we delete a small file from a
directory and immediately recreate it, so the same directory data block
needs to be updated again? Will this require a new transaction as well? If
not, my aproach doesn't either. BTW: When I talked about a transaction I
obviously meant something different than you, on the other hand that was my
fault. What I meant with transaction is something like an atom. Moving a
file from directory A to directory B needs (at least) four updates, the
inodes of the directories and the directory data blocks. I would say, that
this update is one transaction. But you would say, that is only a part of a
transaction, as you would put deletion of another file, writing some data
to an iso image and whatever else in the same transaction. So, just replace
my "transactions" by "transaction atoms", and then read again, what I
wrote, maybe that makes my idea more clearer.
As soon as I1 is completely zeroed, it will be unlinked in D1, and thus I1
doesn't need to be written as having zeros. So if no update to I1 was
already committed to disk, there is no need to do it at all (something like
forget should be available in the journaling code as well). If it was
already committed, it's original content needs to be committed in the next
transaction, but there is no need to force a commit at this place at all.
Regards, Bodo
More information about the Ext3-users
mailing list