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-7884 Lustre <p>When using the llmount.sh script with TMP=/dev/shm it failed with:</p> <ol> <li>Formatting mgs, mds, osts</li> <li>Format mds1: /dev/shm/lustre-mdt1</li> <li>mkfs.lustre: /dev/shm/lustre-mdt1 apparently does not exist<br/> #</li> <li>mkfs.lustre FATAL: unable to prepare backend (2)</li> <li>mkfs.lustre: exiting with 2 (No such file or directory)</li> </ol> <p>This is certainly related to <a href="https://jira.whamcloud.com/browse/LU-1047" title="Fix some error messages in mkfs.lustre to use strerror" class="issue-link" data-issue-key="LU-1047"><del>LU-1047</del></a> ("utils: mkfs shouldn't create loopback files in /dev")<br/> This makes sense but it would be nice to declare /dev/shm as an exception.</p> LU-7884

utils: mkfs prevents the creation of loopback files in /dev/shm

Bug Minor Resolved Fixed Henri Doreau CEA patch Thu, 17 Mar 2016 13:33:07 +0000 Wed, 5 Aug 2020 13:50:24 +0000 Wed, 7 Jun 2017 23:29:44 +0000 Lustre 2.10.0 0 6 <p>Quentin Bouget (quentin.bouget@gmail.com) uploaded a new patch: <a href="http://review.whamcloud.com/18984" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/18984</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7884" title="utils: mkfs prevents the creation of loopback files in /dev/shm" class="issue-link" data-issue-key="LU-7884"><del>LU-7884</del></a> utils: allow mkfs to create loopback files in /dev/shm<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1212f31385bb6b5335d8ca760d2185def92ee1ca</p> <p>But why? /dev/shm is for shm_open, not temporary files.</p> <p>It is commonly used as such though. In this case, it is convenient to use it to setup fast and short-lived devices.<br/> Additionally, we know that /dev/shm will always be mounted and always be tmpfs, unlike /tmp or custom tmpfs mounts.</p> <p>That makes sense, but that feels like a bandaid on top of another bandaid.</p> <p>Are there modern systems where /tmp is not tmpfs? Alternately, it would be possible to just <tt>touch /dev/shm/lustre-mdt1</tt> before calling mkfs.lustre so that the access() check succeeds.</p> <p>Out of curiosity, is the filesystem in /dev/shm for doing regression testing, or is this for a "fast scratch" workload? For the latter, I've sometimes wondered whether it would make sense to have a special "osd-tmpfs" that was much more efficient than storing an ldiskfs image inside tmpfs or ramdisk, since it could ignore all of the journaling, recovery, etc. overhead since the filesystem would disappear anyway if the node rebooted.</p> <p>Yes Andreas. My Ubuntu 16 system at home doesn't use tmpfs for /tmp. Now /dev/shm is a tmpfs.</p> <p>Indeed we can touch the devices before running the tests, but the purpose of the patch is to simplify the procedure so that we don't have to do it.<br/> We use it for regression testing.</p> <p>If this is used for regression testing only, then it is fine to add something to test-framework.sh or other testing scripts to touch the file in /dev/shm before trying to use it so that mkfs.lustre is happy. I don't like mkfs.lustre to automatically create files that do not already exist, since this can be confusing to users that don't know what they are doing.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/18984/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/18984/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7884" title="utils: mkfs prevents the creation of loopback files in /dev/shm" class="issue-link" data-issue-key="LU-7884"><del>LU-7884</del></a> utils: mkfs prevents the creation of files in /dev/shm<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: d9c146f670ab433632d6d7536592a4240de616a4</p> <p>Landed for 2.10</p> Related LU-9792 Development End date Fri, 29 Apr 2016 13:33:07 +0000 Rank 1|hzy4q7: Rank (Obsolete) 9223372036854775807 Severity Start date Thu, 17 Mar 2016 13:33:07 +0000