[LU-14366] "lfs mkdir" on existing directory returns "Operation not supported/already in progress"

Related — Wed, 23 Feb 2022 19:30:52 +0000

Running "[{lfs mkdir /path/to/existing/directory}}" prints an error message "Operation not permitted" (-EPERM) for a directory that already exists, rather than the more expected "File already exists" (-EEXIST).

It turns out that this is because "lfs mkdir" will now restriping a directory in the background, if it already exists, to match the new layout given by "lfs mkdir". This fails with "Operation not permitted" if mdt.*.enable_dir_restripe=0.

If "mdt.*.enable_dir_restripe=1" then the background restripe fails with "Operation already in progress" (-EALREADY).

I think it is confusing from a user perspective if "lfs mkdir" is trying to migrate the directory when it already exists. This is happening because "lfs mkdir" is internally just an alias for "lfs setdirstripe", but I still think it is confusing, and wonder if we need to treat these commands slightly differently in this case (e.g. add a flag to "lfs mkdir" to prevent it from doing the silent migration? It should return -EEXIST in that case.

My understanding is that the difference between "lfs setdirstripe" and "lfs migrate -m" is that setdirstripe will only move the entries to the new MDT(s), while "migrate -m" will also move the inodes to the new MDT(s)? I definitely like the idea of being able to restripe a directory and only move the entries, but I wonder if the entry-only restripe would be more clear if it was an option for "lfs migrate -m"?

Whamcloud Community JIRA

[LU-14366] "lfs mkdir" on existing directory returns "Operation not supported/already in progress"