On Fri, Nov 15, 2019 at 01:13:15AM +0200, Amir Goldstein wrote: > See attached. > IMHO it looks much easier to verify that these changes are correct > compared to your open coded offset shifting all over the place. > > It even passed the exportfs tests first try. > Only some index tests are failing. > > If you like this version, I can fix up the failures and add Al's > suggestions to simplify code with OVL_FH_MAX_SIZE > memory allocations. Huh? Correct me if I'm wrong, but doesn't that patch make it reject all old fhandles just on the type check? That includes anything sent over the wire, or stored in xattrs, or represented as names in indexdir... _If_ we can change the fhandle layout at will, everything's easy - you can add padding in any way you like. But fhandles are a lot more permanent than this approach would require - mere rebooting the server into a new kernel must not make the clients see -ESTALE on everything they'd imported from it! And then there's implied "you can throw indexdir contents at any time", which is also not a good thing to do. Sure, introducing a variant with better layout would be nice, and using a new type for it is pretty much required, but you can't just discard old-layout fhandles you'd ever issued. I'm afraid it's a lot stickier than you think; decisions on fhandle layout are nearly as permanent as those on the storage layouts for a filesystem. Especially in case of overlayfs, where they are literally a part of the storage layout - the names in indexdir and the contents of trusted.overlay.upper xattr on subdirectories in there...
