On Thu, 2019-04-25 at 13:05 +0300, Janne Karhunen wrote: > Hi, > Finally. Now I think I'm almost happy with the overall construction > and my gut feeling is telling me I can make the hashes reflect the > filesystem state pretty well, maybe even over 99.9% of the time given > the workload stock android is generating. > > The pieces that we did: > - initialize hashes correctly on open() > - hook 'sync' > - hook 'msync' > - hook 'truncate' > - introduce a per-cpu workqueue that gets work items from write and > dirty page flush. Long-running write is allowed to go as is (no > performance penalty from re-measurements), but once the the write goes > silent workqueue item is flushed and the file is hashed. What type of workqueue (eg. fifo)? Are all of the writes needed, as they might be re-written later. > > Before I uplift this construction against the mainline, any thoughts > about this? All I can say so far is that it runs and it seems to keep > the system relatively crash tolerant. 'Don't let the perfect be the > enemy of the better' I guess... As long as the iint cache info isn't affected by these changes, the change is limited to writing out the xattr more frequently. If the iint cache info is affected, then you need to be careful that multiple readers/writers continue to work. Mimi
