[LU-14061] LU-12514 (lustre_tgt mount type) breaks scripts that used 'mount -t lustre' and expected targets Created: 21/Oct/20 Updated: 19/Nov/20 Resolved: 19/Nov/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.13.0 |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | John Hammond | Assignee: | Andreas Dilger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
LU-12514 (utils: add "lustre_tgt" filesystem type) breaks scripts that used 'mount -t lustre' and expected to see targets. In 2.12.*: # mount -t lustre /dev/mapper/mds1_flakey on /mnt/lustre-mds1 type lustre (ro,svname=lustre-MDT0000,mgs,osd=osd-ldiskfs,user_xattr,errors=remount-ro) /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost2_flakey on /mnt/lustre-ost2 type lustre (ro,svname=lustre-OST0001,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost3_flakey on /mnt/lustre-ost3 type lustre (ro,svname=lustre-OST0002,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost4_flakey on /mnt/lustre-ost4 type lustre (ro,svname=lustre-OST0003,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs) # mount -t lustre_tgt # In 2.13 and on: # mount -t lustre 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt) # mount -t lustre_tgt /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost2_flakey on /mnt/lustre-ost2 type lustre_tgt (ro,svname=lustre-OST0001,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost3_flakey on /mnt/lustre-ost3 type lustre_tgt (ro,svname=lustre-OST0002,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/ost4_flakey on /mnt/lustre-ost4 type lustre_tgt (ro,svname=lustre-OST0003,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) /dev/mapper/mds1_flakey on /mnt/lustre-mds1 type lustre_tgt (ro,svname=lustre-MDT0000,mgs,osd=osd-ldiskfs,user_xattr,errors=remount-ro) |
| Comments |
| Comment by James A Simmons [ 23/Oct/20 ] |
|
The solution is to update to 'mount -t lustre,lustre_tgt'. NFS did the same thing for NFSv4 support. The idea of a 'lustre' file system type for both servers and clients works well since the normal setup is separate nodes for clients and servers. If mounting a light weight client will be the norm in the future on server nodes I can see a 'lustre' for all leading to problems. |
| Comment by John Hammond [ 23/Oct/20 ] |
|
This is not a solution for existing scripts. |
| Comment by Andreas Dilger [ 29/Oct/20 ] |
|
John, how were the server filesystems mounted originally? Did they get mounted with "mount -t lustre" or "mount -t lustre_tgt" initially? Since 2.13, "mount -t lustre" will internally call "mount.lustre" and "mount -t lustre_tgt" will internally call "mount.lustre_tgt", but both are the same binary and will try "lustre_tgt" first for server mountpoints (block devices) and then fall back to using "lustre" if that doesn't work. I tested a trivial change to "mount_lustre.c" that only uses "lustre", and "mount -t lustre" now works fine. It would probably be trivial to distinguish via "argv[0]" which binary is being called and use that preferentially so that the mounted type matches what is requested. Since commit v2_12_58-71-g510aea4a37, the use of lustre_tgt is optional so it is still possible to mount a server as type lustre to give some time to migrate system configurations. We definitely want to keep this compatibility until at least the next LTS, so that there is at least one commonly-used release where it is possible to use either type so upgrade/downgrade is possible without a flag day for changing the configuration at the same time. Possibly for 2.14 or 2.15 it seems reasonable to add a message to mount.lustre and/or the kernel to warn if lustre is used for a server mountpoint, but that wouldn't cause any errors for users. John also pointed out that "stat -f" should handle this as well. This will currently report "UNKNOWN (0xbd00bd1)" as the filesystem magic (LUSTRE_SUPER_MAGIC), regardless of what type it was mounted as. This is also true on my 2.10.8 server, so it is not a regression introduced by LU-12514. It makes sense to submit an upstream patch to fix this to return "lustre_tgt" so that it is correct by the time it makes its way into the vendor distros. If anyone is using bleeding-edge coreutils it is likely that they are also using a newer Lustre release, or this is on the client where it doesn't matter since it returns magic "LL_SUPER_MAGIC = 0x0bd00bd0" which is mapped to "lustre" in userspace. |
| Comment by John Hammond [ 29/Oct/20 ] |
|
> how were the server filesystems mounted originally? Did they get mounted with "mount -t lustre" or "mount -t lustre_tgt" initially? Using mount -t lustre. k:~# mount -t lustre 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt) k:~# mount -t lustre_tgt ... /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) k:~# umount /mnt/lustre-ost1/ k:~# mount /dev/mapper/ost1_flakey /mnt/lustre-ost1 -t lustre k:~# mount -t lustre 192.168.122.75@tcp:/lustre on /mnt/lustre type lustre (rw,flock,user_xattr,lazystatfs,noencrypt) k:~# mount -t lustre_tgt ... /dev/mapper/ost1_flakey on /mnt/lustre-ost1 type lustre_tgt (ro,svname=lustre-OST0000,mgsnode=192.168.122.75@tcp,osd=osd-ldiskfs,errors=remount-ro) |
| Comment by Andreas Dilger [ 29/Oct/20 ] |
|
So this appears to be a bug in mount_lustre.c that it is always using "lustre_tgt" for server targets instead of what was requested:
if (!mop.mo_fake) {
char *fstype = client ? "lustre" : "lustre_tgt";
/*
* flags and target get to lustre_get_sb(), but not
* lustre_fill_super(). Lustre ignores the flags, but mount
* does not.
*/
for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) {
rc = mount(mop.mo_source, mop.mo_target, fstype,
flags, (void *)options);
if (rc != 0) {
/* Older Lustre without 'lustre_tgt'.
* Try 'lustre' instead
*/
if (rc == -ENODEV) {
fstype = "lustre";
i--;
continue;
}
This should check basename(argv[0]) to see if it is called as "mount.lustre" and preferably use "lustre" in that case, and "mount.lustre_tgt" should preferably use "lustre_tgt" then. For server mountpoints it could also try "lustre_tgt" if the first mount fails with -ENODEV.
if (!mop.mo_fake) {
char *fstype = "lustre";
if (strstr(argv[0], "mount.lustre_tgt"))
fstype = "lustre_tgt";
/*
* flags and target get to lustre_get_sb(), but not
* lustre_fill_super(). Lustre ignores the flags, but mount
* does not.
*/
for (i = 0, rc = -EAGAIN; i <= mop.mo_retry && rc != 0; i++) {
rc = mount(mop.mo_source, mop.mo_target, fstype,
flags, (void *)options);
if (rc != 0) {
/* Older Lustre without 'lustre_tgt'.
* Try 'lustre' instead
*/
if (rc == -ENODEV && strcmp(fstype, "lustre_tgt")) {
fstype = "lustre";
i--;
continue;
}
|
| Comment by Gerrit Updater [ 29/Oct/20 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/40474 |
| Comment by Gerrit Updater [ 19/Nov/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40474/ |
| Comment by Peter Jones [ 19/Nov/20 ] |
|
Landed for 2.14 |