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
