thank you, ted. I have understood the whole design and implementation of the ijournal paper. and i think the fast commit for ext4 may be designed and implemented according to idea of that ijournal paper, as that ijournal thought is the best way for resolve the problem of file's data has to been waited in jbd2 thread with order mode from my opinion. according to that paper, ijournal only record and commit the changes of the fsync'ed file to its own ijournal area, the changes of whole ext4 filesystem are left to normal journal to process. and ijournal only happen at the end of the thread which is doing fsync work. it need not be embedded to jbd2 thread. and the changes of the fsync'ed file which have been committed by ijournal will also be committed to normal journal area subsequently. ijournal won't have side effect on normal journal , these two journal runs independently. all of these above designments of ijournal from my viewpoint will simply the fast commit function developed recently, meanwhile it can help fast commit function to achieve its goals. one of its most important goals which i have to highlight should be fix ext4 fsync time cost problems because of file's data has to been waited in jbd2 thread(same as CTX problems pointed in ijournal paper). what do you think of it ? I like this ijournal thought. may be i want to do some work on coding of this fast commit function in my free time. On Mon, Nov 4, 2019 at 11:22 AM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Mon, Nov 04, 2019 at 09:01:28AM +0800, xiaohui li wrote: > > > > when in writeback mode, inode' data has not to be waited in jbd2 > > thread, so the fsync time cost is also reduced. > > meawhile, writeback mode also can guarantee filesystem consistency in > > os crash-reboot conditions, > > with only one drawback is that it will cause security problems such as > > stale data will be seen. > > It's not just stale data; in data=writeback, today if a file gets > deleted, its blocks are immediately eligible to be reused. If there > is a crash before the transaction is committed, there could be a file > that would have deleted (and perhaps replaced) that doesn't in fact > get deleted, but its data blocks will have been corrupted. > > I'm not fond of that particular behavior, and I may look to fix it, > but in general, data=writeback means that data blocks may be corrupted > or contain stale data after a crash --- for blocks that were freshly > created, or for a file that might have been deleted, but except for > the crash which means that the file deletion doesn't actually get > corrupted. > > > but in android system with file encryption enabled, there is no > > security problem as files are all encryped. > > but user will see wrong file data in system crash-reboot conditions > > with writeback mode enabled. > > If all files are encrypted, then yes, the chances of stale data > causing security issues is significantly reduced. > > But see also the case of a file which is deleted immediately before a > crash. Things are more complex in terms of the data gauarantees after > a crash, which is why data=ordered is the default. > > Regards, > > - Ted
