sous-chefs / filesystem

Development repository for the filesystem cookbook
https://supermarket.chef.io/cookbooks/filesystem
Apache License 2.0
24 stars 7 forks source link

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

Open dtseiler opened 7 months ago

dtseiler commented 7 months ago

:speaking_head: Foreword

Good morning.

:ghost: 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?

:pancakes: Cookbook version

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

:woman_cook: Chef-Infra Version

Chef Infra Client: 18.3.0

:tophat: 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.

:police_car: Expected behavior

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

:heavy_plus_sign: 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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.