[LU-18247] Nodemap does not initialize unused fields on disk

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.16.0
• Affects Version/s: Lustre 2.16.0
• Severity: 3
• Assignee: Sebastien Buisson
• Reporter: Andreas Dilger

Description

The nodemap code does not properly initialize any unused fields in the on-disk records used for configuring the nodemap properties. This means that if we want to use any of these fields in the future (as was the case for the read-only mount flag in LU-15451, for example), then they may contain random garbage from memory.

This makes it difficult to expand nodemap functionality within the constrained configuration record space that is available for use today, without requiring a significant change to the on-disk configuration records.

We need a patch at the soonest opportunity that starts zeroing these nodemap records so that they could be used productively in the future. The sooner this patch is landed, and the more widespread the deployment of this patch, the sooner we can start using this fields.

Issue Links

• is related to: LU-15451 read-only nodemap flag
• is related to: LU-17609 Enforce nodemap's readonly_mount in case of remount
• is related to: LU-18109 Nodemap UID/GID/PROJID idmap offsetting

Comments

[Peter Jones]

Merged for 2.16

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/56450/
Subject: LU-18247 nodemap: initialize unused fields on disk
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 2a5e8e355498d432d9c4bb5cd34c513b9f3a1752

[Andreas Dilger]

It might be possible to make this handling retroactive by storing a new nodemap cluster record that means "we are now storing zeroed records". That is tricky because the nodemap config is stored in an index and not a list, so there is no inherent ordering of records. The initial proposal of storing a magic in each record means we would be burning a few bytes in the config record to indicate the rest of the bits are usable. The drawback is that we are burning a few bytes in the config record that we might need in the future.

A second option could be setting a new NM_FL2_ZERO_RESERVED bit in the nodemap_cluster_rec.ncr_flags2 config record (which is at least zeroed since patch https://review.whamcloud.com/47817 "LU-15451 sec: retry ro mount if read-only flag set" landed), that is only set when this record is written for the first time (ie. we know all future records are also zeroed).

As an enhancement, if ZERO_RESERVED is unset, then the code could read/zero/delete/write every record in the nodemap config and then set ZERO_RESERVED in the config. We know that currently the records are (by definition) not using any of these unused fields, so it would be safe to zero them, and afterward they would be safe to use.

One further complication is it looks like the LU-15451 patch was landed 2 years ago, but only as 2.15.51, and was not backported to 2.15.x LTS branch (though it could still be backported along with the 56450 patch.

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/56450
Subject: LU-18247 nodemap: initialize unused fields on disk
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0c299a9975f0e4a5e3d69635a2766901277af72c