Minor Description
There are many places in the Lustre client/server code that depend on the hard-coded Linux kernel NAME_MAX=255 limit for the maximum length of a filename component.
In recent ZFS versions it is possible to have filenames up to 1024 characters, and even older ZFS versions allow filenames up to 256 characters.
Firstly, it would be useful to add a "llite.*.namelen_max" tunable to show the sbi->ll_namelen limit, and would initially be read-only. This would match the other statfs llite.*.kbytes* and llite.*.files* parameters and could be used by scripts. This namelen limit is also available via "stat -f -c %l DIR", but it would be convenient/consistent to expose this via get_param as well.
A client-side patch could fix llite/lmv/utils to use the MDT-supplied limit in os_namelen and make llite.*.namelen_max a writable parameter that allows setting sbi->ll_namelen) up to the limit of os_namelen returned by the MDTs. It would default to NAME_MAX for strict POSIX compatibility, but would allow the server os_namelen to be changed independently.
A separate server-side patch would fix lod/lfsck/mdd/target/ldiskfs to remove hard-coded NAME_MAX usage, and depend only on the namelen returned from the OSD. It would be up to the client to impose the NAME_MAX limit itself, as needed. A separate server tunable should be added (e.g. osd-*.*.namelen_max) to allow limiting os_namelen returned from the OSD, with a default of NAME_MAX for compatibility with older clients that do not impose this limit themselves.
Attachments
Issue Links
- is related to
-
LU-18783 pjdfstest test chmod 2 fails with ZFS 2.3.0
-
- Open
-
Activity
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58432
Subject: LU-18803 lmv: add statfs stats to LMV device
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 078bb7bf2f6eb1a706930dfc91e51b2945949acb
There is a decent amount of work remaining to remove the hard-coded NAME_MAX from the Lustre util, client, and server code. I'm not planning to working on that, but I've outlined above what needs to be done, in bite-sized chunks. I would suggest utils and clients first, then servers, on the assumption that patch https://review.whamcloud.com/58336 ("LU-18783 llite: ensure dentry name is not longer than NAME_MAX") is landing first. The client should always impose its own limit, if necessary, regardless of what the server advertises.
Once the client has removed the hard-coded NAME_MAX usage, will probably still be necessary to limit llite.*.namelen_max=255 when running pjdfstest, at least until a patch is submitted to that test suite to allow a larger namelen to be used.
This ticket should not be closed after patch 58397 is landed. That was just a warm-up so that tests could check what the actual namelen value is, instead of hard-coding it, and not break during interop testing if namelen changes in the future.
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58397
Subject: LU-18803 class: add namelen_max and maxbytes params
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2bbc2774e1d454e971a8e467ef6804217bcf46f4
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/58397/
Subject: LU-18803 class: add namelen_max and maxbytes params
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: dbaccf19f4bc496b90a8a93db76d32cbe889db46