[LU-9767] FS name checking got removed Created: 12/Jul/17 Updated: 21/Sep/17 Resolved: 28/Aug/17 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.10.1, Lustre 2.11.0 |
| Fix Version/s: | Lustre 2.10.1, Lustre 2.11.0 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Ben Evans (Inactive) | Assignee: | James A Simmons |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
https://review.whamcloud.com/#/c/24325/ removed name length and content checking for the fsname. You can now format a FS with up to 16 characters, but can only reference 8 of them in various places, 16 in others. |
| Comments |
| Comment by James A Simmons [ 12/Jul/17 ] |
|
John Hammond asked for this. User land can scribble what ever it wants but kernel space should be rejecting the invalid file system name. The same goes for pool names. Is this not the case? |
| Comment by Ben Evans (Inactive) [ 12/Jul/17 ] |
|
Well, you get some weird looking bugs from it: tunefs.lustre: so the fsname got accepted, but is truncated, except where it's not. I haven't fully sorted out what tools would refer to it by its full name, rather than the truncated one. mkfs.lustre happily accepts it, throwing no errors (up to 16 chars). I'd be curious what happens if you give it a raft of control characters. Regardless, this is a UI error, as the user should be informed of the problem in some manner. |
| Comment by Andreas Dilger [ 15/Jul/17 ] |
|
For mkfs.lustre, the problem is that there is no way for the kernel to verify the fsname because the kernel isn't even involved until the filesystem is mounted. My recommendation would be make a quick patch to add checks into mount_utils_ldiskfs.c and mount_utils_zfs.c that the fsname is <= 8 characters, and do not include a '.' or other illegal character, and then separately we can examine whether it is safe to have a longer fsname where that works (e.g. ZFS where it isn't limited by the size of s_volume_name in the superblock) and make a patch to allow ZFS to have a longer fsname. This will need a code review of where fsname is used on disk and over the network, to verify there aren't explicit or implicit limitations based on the length. |
| Comment by Gerrit Updater [ 17/Jul/17 ] |
|
James Simmons (uja.ornl@yahoo.com) uploaded a new patch: https://review.whamcloud.com/28070 |
| Comment by Gerrit Updater [ 28/Aug/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/28070/ |
| Comment by Peter Jones [ 28/Aug/17 ] |
|
Landed for 2.11 |
| Comment by Gerrit Updater [ 14/Sep/17 ] |
|
James Simmons (uja.ornl@yahoo.com) uploaded a new patch: https://review.whamcloud.com/28996 |
| Comment by Gerrit Updater [ 14/Sep/17 ] |
|
John L. Hammond (john.hammond@intel.com) merged in patch https://review.whamcloud.com/28996/ |