Retaining undelete data on ext3

[Bodo Thiesen]

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