https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4239 Lustre <p>I have created 100 nested directories. No problem until 99.</p> <p><span class="error">&#91;root@st01-cli2 ~&#93;</span># lfs fid2path /mnt/pippo <span class="error">&#91;0x200000400:0xcc:0x0&#93;</span><br/> /mnt/pippo/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</p> <p><span class="error">&#91;root@st01-cli2 ~&#93;</span># lfs fid2path /mnt/pippo <span class="error">&#91;0x200000400:0xcd:0x0&#93;</span><br/> ioctl err -75: Value too large for defined data type (75)<br/> fid2path error: Value too large for defined data type</p> lustre-client-2.4.0-2.6.32_358.11.1.el6.x86_64_ga049816.x86_64 LU-4239

lfs fid2path ioctl err -75: Value too large for defined data type (75)

Bug Minor Resolved Fixed Alex Zhuravlev Gabriele Paciucci cdwgbl patch Sat, 9 Nov 2013 04:47:18 +0000 Tue, 7 Jul 2015 00:17:29 +0000 Tue, 7 Jul 2015 00:17:29 +0000 Lustre 2.6.0 Lustre 2.8.0 0 10 <p>At least there is a Path too Large error returned. </p> <p>Do you feel more depth is needed? 99 Deep seems reasonable to document? </p> <p>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.</p> <p>should be = POSIX PATH MAX ?</p> <p>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 <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> ). I agree that the limit should correspond to some recognisable constant such as PATH_MAX.</p> <p>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.</p> <p>As I wrote in the patch description:<br/> <a href="https://jira.whamcloud.com/browse/LU-4239" title="lfs fid2path ioctl err -75: Value too large for defined data type (75)" class="issue-link" data-issue-key="LU-4239"><del>LU-4239</del></a> mdt: Increase MAX_PATH_DEPTH to PATH_MAX/2</p> <p>Currently, MAX_PATH_DEPTH is limited to 100.<br/> This is an arbitrary limit, and prevents using lfs fid2path<br/> on very deep directory trees.</p> <p>More seriously, this same limit prevents HSM from archiving<br/> these files.</p> <p>Change MAX_PATH_DEPTH to PATH_MAX/2 because the highest<br/> FID/character density is in paths like:<br/> /a/b<br/> which has 4 characters and 2 FIDs.<br/> &#8212;<br/> The obvious downside to this patch is it increases the size of path_lookup_info by about 31k.<br/> (Each FID is 16 bytes, 100*16 bytes = 1600 bytes, 2048*16 bytes = 32k bytes)</p> <p>Here's a quick test showing a file system with this patch on the MDS - Previously, this would give the -75 error mentioned:</p> <p><span class="error">&#91;root@centclient01 centss01&#93;</span># 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/<br/> <span class="error">&#91;0x200000400:0x65:0x0&#93;</span><br/> <span class="error">&#91;root@centclient01 centss01&#93;</span># lfs fid2path /mnt/centss01 <span class="error">&#91;0x200000400:0x65:0x0&#93;</span><br/> /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</p> <p>A quick observation...<br/> In order to test the patch, I'm exploring creating extremely deep directory trees... (Roughly PATH_MAX/2, so 2048 or so.)</p> <p>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.</p> <p>Expanding a little on the possible concern about memory usage.</p> <p>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.</p> <p>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.</p> <p>Patch is here:<br/> <a href="http://review.whamcloud.com/#/c/10717/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10717/</a></p> <p>PS1 increases the array size, PS2 is a rewrite to no longer use the array.</p> <p>Testing here:<br/> centclient01 is running a recent version of master, <br/> centss10 is also running a recent version of master.<br/> <a href="https://jira.whamcloud.com/browse/LU-4239" title="lfs fid2path ioctl err -75: Value too large for defined data type (75)" class="issue-link" data-issue-key="LU-4239"><del>LU-4239</del></a> is present, as seen in the "Value too large" error.</p> <p>centss09 is running a recent version of master+my patch set 2.</p> <p><span class="error">&#91;root@centclient01 centss09&#93;</span># cd /mnt/centss10<br/> <span class="error">&#91;root@centclient01 centss10&#93;</span># 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/<br/> <span class="error">&#91;0x200000400:0x6f:0x0&#93;</span><br/> <span class="error">&#91;root@centclient01 centss10&#93;</span># lfs fid2path /mnt/centss10/ <span class="error">&#91;0x200000400:0x6f:0x0&#93;</span><br/> ioctl err -75: Value too large for defined data type (75)<br/> fid2path: error on FID <span class="error">&#91;0x200000400:0x6f:0x0&#93;</span>: Value too large for defined data type<br/> <span class="error">&#91;root@centclient01 centss10&#93;</span># cd ../centss09<br/> <span class="error">&#91;root@centclient01 centss09&#93;</span># 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/<br/> <span class="error">&#91;0x200000400:0x74:0x0&#93;</span><br/> <span class="error">&#91;root@centclient01 centss09&#93;</span># lfs fid2path /mnt/centss09 <span class="error">&#91;0x200000400:0x74:0x0&#93;</span><br/> /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<br/> <span class="error">&#91;root@centclient01 centss09&#93;</span># </p> <p>Can you add a test so Maloo can verify this patch.</p> <p>Tests for this patch: <a href="http://review.whamcloud.com/12545" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12545</a></p> <p>Patrick Farrell (paf@cray.com) uploaded a new patch: <a href="http://review.whamcloud.com/10717" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10717</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-4239" title="lfs fid2path ioctl err -75: Value too large for defined data type (75)" class="issue-link" data-issue-key="LU-4239"><del>LU-4239</del></a> mdt: Optimize fid2path<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 15<br/> Commit: 78034fb07174a1fe9e22fa5ea54a58d6007af0b3</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/10717/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10717/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-4239" title="lfs fid2path ioctl err -75: Value too large for defined data type (75)" class="issue-link" data-issue-key="LU-4239"><del>LU-4239</del></a> mdt: Optimize fid2path<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 825570b0b03e0fd70aba5400dedca4e6d94d5141</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/12545/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12545/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-4239" title="lfs fid2path ioctl err -75: Value too large for defined data type (75)" class="issue-link" data-issue-key="LU-4239"><del>LU-4239</del></a> tests: test FID related APIs<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 2b10c0bde269e1d45ae9483a492ce171f05831a1</p> <p>Landed for 2.8</p> Related LU-6384 LU-6194 Development Rank 1|hzw8jr: Rank (Obsolete) 11537 Severity