On Mon, Nov 18, 2024 at 12:53 PM Jan Kara <jack@xxxxxxx> wrote: > > On Mon 18-11-24 09:53:57, Mateusz Guzik wrote: > > This gives me about 1.5% speed up when issuing readlink on /initrd.img > > on ext4. > > > > Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx> > > --- > > > > I had this running with the following debug: > > > > if (strlen(link) != inode->i_size) > > printk(KERN_CRIT "mismatch [%s] %l %l\n", link, > > strlen(link), inode->i_size); > > > > nothing popped up > > Then you didn't run with UDF I guess ;). There inode->i_size is the length > of on-disk symlink encoding which is definitely different from the length > of the string we return to VFS (it uses weird standards-defined cross OS > compatible encoding of a path and I'm not even mentioning its own special > encoding of character sets somewhat resembling UCS-2). > Indeed I did not, thanks. :> > > I would leave something of that sort in if it was not defeating the > > point of the change. > > > > However, I'm a little worried some crap fs *does not* fill this in > > despite populating i_link. > > > > Perhaps it would make sense to keep the above with the patch hanging out > > in next and remove later? > > > > Anyhow, worst case, should it turn out i_size does not work there are at > > least two 4-byte holes which can be used to store the length (and > > chances are some existing field can be converted into a union instead). > > I'm not sure I completely follow your proposal here... > I am saying if the size has to be explicitly stored specifically for symlinks, 2 options are: - fill up one of the holes - find a field which is never looked at for symlink inodes and convert into a union I'm going to look into it. -- Mateusz Guzik <mjguzik gmail.com>
