Theodore Tso <tytso@xxxxxxx> 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 _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
