[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Retaining undelete data on ext3



Theodore Tso <tytso mit edu> wrote:

> Actually, you can't --- that's the problem.  Until the changes are
> committed, which means that the changes represented in the filesystem
> are self-consistent and in a transaction which has been committed to
> the journal, you can't start restoring the information in the indirect
> block.

I don't see the problem here. Ok, I must admit not to know the code very 
much, especially the journaling part, I only know the non journaling 
on-disk structures.

But just considering:

We are talking about commiting transactions or not committing transactions. 
Assume we have a big file, and ind block I1, dind block D1 and tind block T 
must be changed to be self-consistent. Ok, no problem, we store the original 
contents of this three blocks in memory, and then update (i.e. zero out) some 
parts. In the next transaction, we need to change I2, D2 and T. If I1 != I2, 
we restore I1 in this transaction - it's no longer needed, remember the old 
content of I2 and log the changes for I2 in the journal. Same applies to D2 
vs. D1. If I1 and I2 (or D1 and D2 resp.) are the same, they are just updated 
leaving the in memory copy of the original data alone. So, I don't see the 
point why we would need to force the data to disk. Is the system crashes, I1 
will just be written several times instead just one time. But after the whole 
log has been replayed, the file system is consistent again. The only 
missfeature is now, that the in memory copy of the original versions of the 
blocks will be lost, but my proposal from very long time fixes that as well by 
just storing the updates in other places then the original version which 
retain unmodified.

Regards, Bodo


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]