On Fri, May 31, 2019 at 12:45 AM Yurii Zubrytskyi <zyy@xxxxxxxxxx> wrote: > We'd need to give the location of the hash tree instead of the > individual hash here though - verification has to go all the way to > the top and even check the signature there. And the same 5 GB file > would have over 40 MB of hashes (32 bytes of SHA2 for each 4K block), > so those have to be read from disk as well. As I think Eugene mentioned, dealing with the hash tree should be done by the verity subsystem anyway. > Overall, let's just imagine a phone with 100 apps, 100MB each, > installed this way. That ends up being ~10GB of data, so we'd need _at > least_ 40 MB for the index and 80 MB for hashes *in kernel*. Seriously? Are those 100 apps accessing that 10G simultaneously? I really don't know the usage pattern of those apps, but I can imagine that some games do quite a lot of paging data in and out. And my guess is that most of those page-ins will still be sequential, and so getting a pageful of index from userspace will allow the kernel to serve quite a few reads without having to go back to userspace. My guess is that even really tiny amount of caching (e.g. one page of index per open file) will get 90% or more of the possible performance improvement. But those are all just guesses. If you say this is not the right direction for your project, fine. Thanks, Miklos
