On Tue, Dec 18, 2018 at 07:16:03PM -0500, Theodore Y. Ts'o wrote: > Sure, but what would be the benefit of doing different things on the > back end? I think this is a really more of a philophical objection > than anything else. With both fsverity and fscrypt, well over 95% of > the implementation is shared between ext4 and f2fs. And from a > cryptographic design, that's something I consider a feature, not a > bug. Cryptographic code is subtle in very different ways compared to > file system code. So it's a good thing to having it done once and > audited by crypto specialists, as opposed to having each file system > doing it differently / independently. Where the data is located on disk should not matter for the crypto details. If it does you have severe implementation issues. > Right, the current interface makes it somewhat more awkward to do > these other things --- but the question is *why* would you want to in > the first place? Why add the extra complexity? I'm a big believer of > the KISS principle, and if there was a reason why a file system would > want to store the Merkle tree somewhere else, we could talk about it, > but I see only downside, and no upside. Filesystems already use blocks beyond EOF for preallocation, either speculative by the file system itself, or explicitly by the user with fallocate. I bet you will run into bugs with your creative abuse sooner or later. Indepnd of that the interface simply is gross, which is enough of a reason not to merge it.
