clarification on non path preserving policies

[TomW1605]

just looking for some clarification on non path preserving policies.

will they make any effort to preserve the path?

if not is there a way to have a weak path preserving policy that will preserve it if possible but flow over to another drive if not?

[trapexit]

will they make any effort to preserve the path?

They work exactly as described in the docs. https://github.com/trapexit/mergerfs#policy-descriptions

mspmfs (most shared path, most free space) | Search: Same as epmfs. Action: Same as epmfs. Create: like epmfs but walk back the path if it fails to find a branch at that level.

[TomW1605]

thanks. unfortunately saying it works as described in the docs dosnt help much. i have already read the docs and dont really understand.

what exactly does it mean by walk back the path if it fails to find a branch at that level?

[trapexit]

A filesystem is a tree. A hierarchy. The policy walks back path hierarchy if, due to the setup you've selected, it fails to find anything.

mkdir /a/b/c/d/e.txt

try to find a branch that fits requirements at /a/b/c/d/... if that fails try /a/b/c/... if that fails /a/b/... if that fails /a/

Walks back the path to find a branch that fits the requirements.

[TomW1605]

also if you put that mkdir /a/b/c/d/e.txt example in the headder text where you are explaining path preserving vs non path preserving that might help. and maybe add msp to the headding. it reads like PP and non PP are the only options till you get to the last lines about MSP and then those kind of dont make sense and feel kind of out of context and confusing

[TomW1605]

also i just noticed that the MSP options are not in the OMV extension. will see if i can get that updated (not sure if it is using an old vertion of mergerfs or just the ui needs updating)

[trapexit]

But they are the only options. Path preserving is rigid. msp is not path preserving. It's just path sticky. If you don't preserve paths it can't be path preserving.

[TomW1605]

i know it is not path preserving but it is also not non path preserving. the true non path preserving policies don't care about the path at all. msp does just not as much as ep. so just present it as 3 distinct options. now i know (thanks to your comment below) that msp is using ep on the back but it is still a distinct way of handling existing paths vs ep that is strict and non ep that ignores them. it might not be 100% technically correct but it will make the documentation easier to understand.

basically the line that you have in What policies should I use? under the FAQs explains it better than what you have in the actual description and would help a lot to be up the top with the policy descriptions

[trapexit]

i know it is not path preserving but it is also not non path preserving.

Yes, it is. Path preservation is a binary. It does or it does not. There is no degrees. The interaction with paths is not the deciding factor. It is that it does not allow cloning across branches. That's the point. To strictly enforce the manual layout. It's not "just not as much". Over time any path cloning will result in increased directory entropy. You don't have that with path preserving policies (ep*).

The FAQ section describes intent. Not behavior. I'm not going to rewrite technical docs to not describe their actual function. If people can't understand the possible usecases for a specific behavior then perhaps I can add a section for that.

[trapexit]

The "tries all drives" is implied by the fact all policies check all branches and that not looking over all branches would make no sense. It wouldn't change the behavior. You have to look at all branches to compare the relative path at each level. I think you are over thinking the behavior. It's just a filter and sort. If you filter all branches with /a/b/c/d and don't find anything then there isn't anything left to check at /a/b/c.

[TomW1605]

You have to look at all branches to compare the relative path at each level
i get that now but it was not clear (to me at least) from the original description. as i said below. just have something to explain what it does while "walking back the path"

[trapexit]

Create: like epmfs but if it fails to find a branch at that level it walk back the path searching each drive for the closest path, picking the drive with the most free space if there is a draw.

But that's not what it does. It literally walks back the path calling epmfs.

epmfs on /a/b/c/d returns nothing... do epmfs on /a/b/c... repeat

[TomW1605]

oh ok i didnt get that it was calling epmfs. in that case put that there instead. either way having something that explains what it is doing while walks back the path would help

[trapexit]

I'm really not understanding what you mean. It describes epmfs and then mspmfs says it's like epmfs but walks back. The only change I can see would be to embed the epmfs description in the mspmfs description so you don't have to read it first.

"Of all the branches on which the relative path exists choose the drive with the most free space. If that fails walk back the path and try again. Continue till root."

[trapexit]

I'm not really understanding. It says that already. "like epmfs but walk back the path if it fails to find a branch at that level." epmfs doesn't walk back. So it's like epmfs but walks back the tree.

[trapexit]

Roundabout how? It's very literal and concise description of the behavior. How would I simplify it but to not expect the reader to read epmfs' description first?

[trapexit]

It'd be a lot easier if you just wrote out what you mean rather than describing in vague terms what you think is wrong.

[TomW1605]

honestly im not really sure what i mean. im trying to think of a way to word it better without it being technically incorrect (but still getting the point across) or being really long.

i think it would be better to put something in the description before the table because then it can be a bit more wordy. give me a bit and i will try and work out how to say it.

also would you be open to spacing out the descriptions in the table like i motioned earlier. that would also help a lot just from a readability point of view (i am dyslexic so chunks of text like that that are split in odd ways (eg titles mid way through the text) make things hard)

[trapexit]

Not sure what you mean by "spacing out the descriptions".

[TomW1605]

simply add a line break between the search, action and create sections of the descriptions.

eg
Search: Same as epmfs. Action: Same as epmfs. Create: like epmfs but walk back the path if it fails to find a branch at that level.

becomes
Search: Same as epmfs.
Action: Same as epmfs.
Create: like epmfs but walk back the path if it fails to find a branch at that level.

it wont change the content of the description but will make it easier to read and comprehend.

im happy to go through and do this and submit a PR if you want