At least there is a Path too Large error returned.
Do you feel more depth is needed? 99 Deep seems reasonable to document?
If the file system can support nested directories beyond a depth of 99, then it is reasonable to expect the tools to keep up. It is something of an edge case, I agree, but it is also not the expected behaviour.
should be = POSIX PATH MAX ?
The limits.h definition describes the number of characters in the file path, not the number of directories. The limit you are hitting is the tree depth, not the number of chars. PATH_MAX is 4K (but there are other choices 
). I agree that the limit should correspond to some recognisable constant such as PATH_MAX.
Just put out a patch for this... Note this is a server patch, not a client one - The limitation is not in LFS, it's actually in some code on the MDS.
As I wrote in the patch description:
LU-4239 mdt: Increase MAX_PATH_DEPTH to PATH_MAX/2
Currently, MAX_PATH_DEPTH is limited to 100.
This is an arbitrary limit, and prevents using lfs fid2path
on very deep directory trees.
More seriously, this same limit prevents HSM from archiving
these files.
Change MAX_PATH_DEPTH to PATH_MAX/2 because the highest
FID/character density is in paths like:
/a/b
which has 4 characters and 2 FIDs.
—
The obvious downside to this patch is it increases the size of path_lookup_info by about 31k.
(Each FID is 16 bytes, 100*16 bytes = 1600 bytes, 2048*16 bytes = 32k bytes)
Here's a quick test showing a file system with this patch on the MDS - Previously, this would give the -75 error mentioned:
[root@centclient01 centss01]# lfs path2fid 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100/
[0x200000400:0x65:0x0]
[root@centclient01 centss01]# lfs fid2path /mnt/centss01 [0x200000400:0x65:0x0]
/mnt/centss01/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100
A quick observation...
In order to test the patch, I'm exploring creating extremely deep directory trees... (Roughly PATH_MAX/2, so 2048 or so.)
As I get to very long path lengths, mkdir is getting extremely slow. I don't think this is related to the patch, but I could be wrong.
Expanding a little on the possible concern about memory usage.
If this is a commonly used piece of code, we've gone from a struct that probably fits in one page to one that doesn't fit in 8. That's potentially quite bad, if it's in a fairly hot path on the MDS. I'm hoping some Intel engineers can comment on that as a possible problem, and if it is one, suggest other solutions.
For example - Do we need to record FIDs in this manner when looking up paths? I see it being done, but I don't actually see the data stored in pli_fids being used. The array is accessed, but only the most recent values in it. It looks like it would be simple enough to rewrite the loop in mdt_path_current to not use the array.
Patch is here:
http://review.whamcloud.com/#/c/10717/
PS1 increases the array size, PS2 is a rewrite to no longer use the array.
Testing here:
centclient01 is running a recent version of master,
centss10 is also running a recent version of master.
LU-4239 is present, as seen in the "Value too large" error.
centss09 is running a recent version of master+my patch set 2.
[root@centclient01 centss09]# cd /mnt/centss10
[root@centclient01 centss10]# lfs path2fid 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100/101/102/103/104/105/106/107/108/109/110/
[0x200000400:0x6f:0x0]
[root@centclient01 centss10]# lfs fid2path /mnt/centss10/ [0x200000400:0x6f:0x0]
ioctl err -75: Value too large for defined data type (75)
fid2path: error on FID [0x200000400:0x6f:0x0]: Value too large for defined data type
[root@centclient01 centss10]# cd ../centss09
[root@centclient01 centss09]# lfs path2fid 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100/101/102/103/104/105/106/107/108/109/110/
[0x200000400:0x74:0x0]
[root@centclient01 centss09]# lfs fid2path /mnt/centss09 [0x200000400:0x74:0x0]
/mnt/centss09/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100/101/102/103/104/105/106/107/108/109/110
[root@centclient01 centss09]#
Can you add a test so Maloo can verify this patch.
Tests for this patch: http://review.whamcloud.com/12545
Patrick Farrell (paf@cray.com) uploaded a new patch: http://review.whamcloud.com/10717
Subject: LU-4239 mdt: Optimize fid2path
Project: fs/lustre-release
Branch: master
Current Patch Set: 15
Commit: 78034fb07174a1fe9e22fa5ea54a58d6007af0b3
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/10717/
Subject: LU-4239 mdt: Optimize fid2path
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 825570b0b03e0fd70aba5400dedca4e6d94d5141
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/12545/
Subject: LU-4239 tests: test FID related APIs
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 2b10c0bde269e1d45ae9483a492ce171f05831a1
Landed for 2.8