On Sun, 2021-12-12 at 22:32 +0100, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "Trond Myklebust" <trondmy@xxxxxxxxxxxxxxx> > > On Sun, 2021-12-12 at 22:00 +0100, Richard Weinberger wrote: > > > When re-exporting, the whole struct nfs_fh is embedded in the new > > > fhandle. > > > But we need only nfs_fh->data[], nfs_fh->size is not needed. > > > So skip fs_fh->size and save a full word (4 bytes). > > > The downside is the extra memcpy() in nfs_fh_to_dentry(). > > > > > > Signed-off-by: Richard Weinberger <richard@xxxxxx> > > > --- > > > While investigating into improving NFS re-export I noticed that > > > we can already save 4 bytes of overhead. > > > I don't think we need to embedd the full struct nfs_fh and > > > can skip ->size. > > > > > > > NACK. This will break existing running clients. Any code to change > > the > > filehandle format must be accompanied with code to detect and > > service > > filehandles that are presented in the old format. > > One possible way to distinguish between old and new formats > is looking at the length of the data. > 2 * XDR_UNIT = new format (without ->size). > 3 * XDR_UNIT = old format. > > What do you think? > You don't a priori know the length of the underlying filehandle or its structure. All you know is that you have n bytes of data, and it is possible that the first 2 bytes represent the size 'n-2'. However it is also possible that those 2 bytes are something else that just happens to match the value 'n-2'. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
