filesystem tries to run mkfs every time when /dev/disk/by-id device path is used

[dtseiler]

🗣️ Foreword

Good morning.

👻 Brief Description

Using GCP VM (GCE). We had been using /dev/sdX device settings but since those are not stable we are looking at changing to the recommended usage of /dev/disk/by-id/foo. However when we do this, the filesystem module appears to always kick off mkfs everytime, presumably because /proc/mounts and /etc/mtab etc. still refer to the /dev/sdX value, so the device names differ?

It doesn't appear to actually do anything, my data is intact and nothing was unmounted or remounted. Is this the expectation? Is there any way for filesystem to recognize the symlink for the /dev/sdX device and not try to reformat everytime?

🥞 Cookbook version

v1.0.0 (yes we have an old download apparently)

👩‍🍳 Chef-Infra Version

Chef Infra Client: 18.3.0

🎩 Platform details

Google Cloud GCE

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"

Steps To Reproduce

Steps to reproduce the behavior:

1. Have an existing volume (eg /dev/sdb) with a by-id symlink pointing to it (eg /dev/disk/by-id/foo-data)
2. Use filesystem with the by-id path for the device attribute
3. Run the cookbook
4. See mkfs attempts that seem to be a NOOP

Chef client.log messages:

[2024-03-01T16:34:22+00:00] INFO: filesystem data_directory creating ext4 on /dev/disk/by-id/foo-data

    * execute[mkfs -t ext4   -L data_directory /dev/disk/by-id/foo-data] action run[2024-03-01T16:34:22+00:00] INFO: Processing execute[mkfs -t ext4   -L data_directory /dev/disk/by-id/foo-data] action run (foo::default line 152)
[2024-03-01T16:34:22+00:00] INFO: Processing execute[Guard resource] action run (dynamically defined)
[2024-03-01T16:34:22+00:00] INFO: execute[Guard resource] ran successfully
[2024-03-01T16:34:22+00:00] INFO: Processing execute[Guard resource] action run (dynamically defined)
[2024-03-01T16:34:22+00:00] INFO: execute[Guard resource] ran successfully
 (skipped due to not_if)
     (up to date)
  * filesystem[data_directory] action mount[2024-03-01T16:34:22+00:00] INFO: Processing filesystem[data_directory] action mount (foo::default line 51)

Again, it doesn't appear to actually be doing anything, presumably it recognizes that the volume already has a filesystem and exits. But I'd rather not have the attempt at all.

🚓 Expected behavior

Ignore the existing filesystem if the device is a symlink to an already-established device

➕ Additional context

I know our version of filesystem is terribly old. Please let me know if this behavior is fixed in a newer version.

Not sure how easy it would be to upgrade it. Obviously we can't risk any destructive changes.

[dtseiler]

I just saw this note from v3.0.3:

fix the check for an existing mountable filesystem before running mkfs again

Would that fix this issue?

[dtseiler]

Actually I wonder if this line alone would do the short-circuiting I need here:

unless mounted?(device)

update, nevermind, we have that but it's in providers/default.rb. Perhaps I can copy the same fixes you had in that PR where I see they should go.

[dtseiler]

I wonder if we could update the mounted? function to traverse symlinks (eg if device is a symlink, check the target of that symlink). I think that would then see that, for example, /dev/disk/by-id/foo-data is already mounted, just at /dev/sdb, and would return rather than try to format and mount it again.

[SlashDashAndCash]

I have created a new pull request. Resolving the symlink of the device is not sufficient, because the canonical path is not comparable with the content of /proc/mounts then. For example, the paths of Device Mapper are also symlinks (/dev/mapper/system-root -> ../dm-1).
My proposal canonicalizes both the device path in /proc/mounts and the device in the Chef resource.

Can the maintainers evaluate and approve the pull request please? The mounted check is not reliable at the moment which can lead to data loss!

Since Linux kernel 5.3 in Sep. 2019 block device names are no longer predictable. Persistent names in /dev/disk/ are now essential for Linux operation.

My Change has been running on 400+ virtual machines since April. So far without problems but it should be tested in more environments as file system changes are dangerous.

[damacus]

Resolved by #132