Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
3
-
9223372036854775807
Description
When using the llmount.sh script with TMP=/dev/shm it failed with:
- Formatting mgs, mds, osts
- Format mds1: /dev/shm/lustre-mdt1
- mkfs.lustre: /dev/shm/lustre-mdt1 apparently does not exist
# - mkfs.lustre FATAL: unable to prepare backend (2)
- mkfs.lustre: exiting with 2 (No such file or directory)
This is certainly related to LU-1047 ("utils: mkfs shouldn't create loopback files in /dev")
This makes sense but it would be nice to declare /dev/shm as an exception.
Attachments
Issue Links
- is related to
-
-
- Resolved
-
Activity
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/18984/
Subject: LU-7884 utils: mkfs prevents the creation of files in /dev/shm
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d9c146f670ab433632d6d7536592a4240de616a4
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.
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.
We use it for regression testing.
Yes Andreas. My Ubuntu 16 system at home doesn't use tmpfs for /tmp. Now /dev/shm is a tmpfs.
Are there modern systems where /tmp is not tmpfs? Alternately, it would be possible to just touch /dev/shm/lustre-mdt1 before calling mkfs.lustre so that the access() check succeeds.
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.
That makes sense, but that feels like a bandaid on top of another bandaid.
It is commonly used as such though. In this case, it is convenient to use it to setup fast and short-lived devices.
Additionally, we know that /dev/shm will always be mounted and always be tmpfs, unlike /tmp or custom tmpfs mounts.
Quentin Bouget (quentin.bouget@gmail.com) uploaded a new patch: http://review.whamcloud.com/18984
Subject: LU-7884 utils: allow mkfs to create loopback files in /dev/shm
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1212f31385bb6b5335d8ca760d2185def92ee1ca
Landed for 2.10