Blocker Description
When running mkfs.lustre on a new file, mkfs.lustre can't create the file automatically, but reports error 2 "No such file or directory".
This bug is introduced by LU-3682. I will fix it.
Attachments
Issue Links
- is related to
-
LU-3682 "tunefs.lustre --erase_params" corrupts running MGS when run against device node symlink
-
- Reopened
-
Activity
I don't think that creating loopback files automatically is a good idea. In the normal use case (instead if during testing) any typo or error in the device name will result in a loopback file being created instead if returning a useful error to the user. For example, if someone accidentally runs "mkfs.lustre /dev/sfa" instead of "sda" this will result in a loopback file being created in /dev that will initially work, but will be very slow and will later fail when the root Filesystem runs pit of space.
I would rather that testers/scripts make sure that the loopback file it created first, and allow mkfs.lustre to return an error if this us not done correctly.
Please resubmit the patch with just the other bug fixes.
I find a real issue introduced by my patch for LU-3682, which is blocking zfs testing.
That patch removed the following code from mkfs_lustre.c:parse_opts().
/* The device or pool/filesystem name */
strscpy(mop->mo_device, argv[optind], sizeof(mop->mo_device));
This is necessary for zfs to copy pool/filesystem name. I have already merged this fix into http://review.whamcloud.com/7722 .
Hmm, it will block llmount.sh and other lustre scripts if the given tmp file doesn't exist. And I'm afraid this problem will be complained in the future without a fix. At least, we should give a console error message about "No such file or directory".
Should no longer exist now LU-3682 has been reverted