On Thu, Nov 09, 2023 at 02:48:19PM +0100, Christian Brauner wrote: > On Thu, Nov 09, 2023 at 06:20:38AM +0000, Al Viro wrote: > > Saves a pointer per struct dentry and actually makes the things less > > Which you're giving back to DNAME_INLINE_LEN. Have to - we want the size to stay a multiple of 64. So DNAME_INLINE_LEN serves as a sump - any space savings we get go in there, just as any additional fields have to pull the space out of there. FWIW, from distribution of name lengths on 3 local boxen, with reasonably diverse contents of filesystems: < 24: 90.6877% 89.8033% 89.3202% < 25: 92.2120% 90.4324% 90.4652% < 26: 93.5858% 95.0555% 92.3849% < 27: 94.6277% 95.4424% 93.1948% < 28: 95.4827% 95.7796% 93.9134% < 29: 96.1926% 96.0851% 94.5449% < 30: 96.7963% 96.3503% 95.1006% < 32: 97.6930% 96.5792% 95.5681% < 33: 98.0392% 96.7943% 95.9879% < 34: 98.3134% 96.9829% 96.3353% < 35: 98.5493% 97.1352% 96.6313% < 36: 98.7468% 97.2757% 96.8890% < 37: 98.9134% 97.4192% 97.1199% < 38: 99.0515% 97.5506% 97.3372% < 39: 99.3650% 97.6394% 97.4857% < 40: 99.4606% 98.8016% 97.7237% So 32 is tolerable, but going down would rapidly become unpleasant. This series does not introduce any new fields, but it's nice to be able to do so without causing PITA for long names.
