[LU-7884] utils: mkfs prevents the creation of loopback files in /dev/shm Created: 17/Mar/16  Updated: 05/Aug/20  Resolved: 07/Jun/17

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.10.0

Type: Bug Priority: Minor
Reporter: CEA Assignee: Henri Doreau (Inactive)
Resolution: Fixed Votes: 0
Labels: patch

Issue Links:
Related
is related to LU-9792 "loop" devices testing with zfs is br... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

When using the llmount.sh script with TMP=/dev/shm it failed with:

  1. Formatting mgs, mds, osts
  2. Format mds1: /dev/shm/lustre-mdt1
  3. mkfs.lustre: /dev/shm/lustre-mdt1 apparently does not exist
    #
  4. mkfs.lustre FATAL: unable to prepare backend (2)
  5. 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.

 Comments   
Comment by Gerrit Updater [ 17/Mar/16 ]

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

Comment by Frank Zago (Inactive) [ 18/Mar/16 ]

But why? /dev/shm is for shm_open, not temporary files.

Comment by Henri Doreau (Inactive) [ 21/Mar/16 ]

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.

Comment by Frank Zago (Inactive) [ 30/Mar/16 ]

That makes sense, but that feels like a bandaid on top of another bandaid.

Comment by Andreas Dilger [ 28/Apr/16 ]

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.

Comment by James A Simmons [ 28/Apr/16 ]

Yes Andreas. My Ubuntu 16 system at home doesn't use tmpfs for /tmp. Now /dev/shm is a tmpfs.

Comment by Henri Doreau (Inactive) [ 29/Apr/16 ]

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.

Comment by Andreas Dilger [ 29/Apr/16 ]

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.

Comment by Gerrit Updater [ 07/Jun/17 ]

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

Comment by Peter Jones [ 07/Jun/17 ]

Landed for 2.10

Generated at Sat Feb 10 02:12:45 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.