How to avoid crossing different file systems when moving files?

[Gloryandel]

For general questions and support please use GitHub Discussions or Discord.

How to keep the files in their original file system when moving files on the merge fs mount point? Moving files does not involve an increase in space usage, but the allocation strategy of merges will still be executed. I use merges as the primary file system for NAS, and performance is not very important to me.

[trapexit]

You need to provide actual details to your question. There is no such thing as "move".

[Gloryandel]

In other words, can't the underlying layer distinguish between “create” and “move”? When nextcloud puts a file into the recycle bin and version control, a new path will be created, resulting in an unexpected cross-file system, which takes a long time to process. It seems that this situation may also occur when samba puts a file into the recycle bin.

[trapexit]

There is no such thing as "move". There is rename and create/open. These are separate things that the client software chooses to call. mergerfs does whatever you ask it to do in these situations based on the policy you choose and other configuration.

As requested in the ticket template and support section of the docs you really really need to provide some details so I can respond to your question.

https://github.com/trapexit/mergerfs#information-to-include-in-bug-reports

[Gloryandel]

I'm sorry for not being able to provide more useful information.
Install mergerfs on the PVE ArchLinux virtual machine.application is deployed by podman.
OS: Linux Arch Linux 6.11.9-arch1-1
version: mergerfs 2.40.2-1
automount: systemd

mount command info:

1:2:3:4 on /srv/pool/data type fuse.mergerfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
1:2:3:4 on /srv/pool/appdata type fuse.mergerfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

mount options

mergerfs /srv/branches/appdata/appdata01:/srv/branches/appdata/appdata02:/srv/branches/appdata/appdata03:/srv/branches/appdata/appdata04 lazy-umount-mountpoint=true,ignorepponrename=true,dropcacheonclose=true,moveonenospc=true,minfreespace=512M,category.create=epff,posix_acl=true /srv/pool/appdata

mergerfs /srv/branches/data/data01:/srv/branches/data/data02:/srv/branches/data/data03:/srv/branches/data/data04 lazy-umount-mountpoint=true,ignorepponrename=true,dropcacheonclose=true,moveonenospc=true,minfreespace=1G,posix_acl=true   /srv/pool/data

branchs is Btrfs

[trapexit]

• https://github.com/trapexit/mergerfs?tab=readme-ov-file#policy-descriptions
• https://github.com/trapexit/mergerfs?tab=readme-ov-file#rename--link

You have set the create policy to epff. Existing Path First Found. It is doing exactly what you've told it to do... only consider paths which already exist. If you don't want mergerfs to preserve existing paths don't configure it as such.

[Gloryandel]

• https://github.com/trapexit/mergerfs?tab=readme-ov-file#policy-descriptions
• https://github.com/trapexit/mergerfs?tab=readme-ov-file#rename--link

You have set the create policy to epff. Existing Path First Found. It is doing exactly what you've told it to do... only consider paths which already exist. If you don't want mergerfs to preserve existing paths don't configure it as such.

This is intentional, first find ensures that data is created on SSD devices. Especially databases.
The following is used to store data.

mergerfs /srv/branches/data/data01:/srv/branches/data/data02:/srv/branches/data/data03:/srv/branches/data/data04 lazy-umount-mountpoint=true,ignorepponrename=true,dropcacheonclose=true,moveonenospc=true,minfreespace=1G,posix_acl=true   /srv/pool/data

I'm sorry for the confusion in my statement. I used 'cross file system' to refer to crossing different merges branches. Each branch corresponds to a different device.
In fact, as a NAS, files are rarely operated. It only happens occasionally. I learned a lot from your answer.
Provide a hypothesis. If you don't mind the performance loss, can FUSE intervene and try to query the branches where the source file is located, for "move", forward the creatio request to the same file system? "The basis for distinguishing between creation and movement/copy is whether the file exists at the time of query. If the file exists, it should not be created, and it will be forwarded to the file system where the file is located; if it does not exist, the file is created, and the policy is used for evaluation and selection." I think it can solve the accidental cross-file system while “moving" files to avoid cross-file system?

[trapexit]

I don't know what you're trying to get across. There is no such thing as "move" or "copy". There is only rename(from,to) and open/create(target). That's it. There is no such thing as "move(from,to)" or "copy(from,to)". You've set a path preserving policy so on rename it won't create paths and when it chooses to copy the file I have no way to know what is going on. There is just an "open(from)" that might not even come from mergerfs and a "open(to)" that is entirely and totally separate. There is no real way to correlate them. Even if I scanned every file opened by the client program (which would be extremely expensive) and tried to compare it to what is being is being created ... what is it supposed to do? There could be 1 or 10 thousand open files. Scan over every one and see if the file is in a path mergerfs also happens to be configured with and then select one for the branch of the create and instead rename? I can't do that. The app could do literally anything. It isn't expecting a rename. It's doing "read(Xbytes,A); write(Xbytes,B); loop". That's a very different behavior.

[Gloryandel]

Thank you for your answer.
Just describing my previous thoughts:

I simply understand it as mv/cp=open read write.The above idea is to attempt to hijack the write behavior in merges. When calling write (pool/path/file),Try to first obtain 'branch/path/file' from the device where the 'pool/path/file' in the open (pool/path/file) of the same file is located. If the 'pool/path/file' can be obtained, the file should exist on a branch. Then modify the original parameters of write (branch/path/file) to directly point to the device where the open file/path is located, thereby enabling device A to open and write (including mv, cp) to device A,This way, moving/copying large files can be done instantly.

[trapexit]

I don't think you are understanding what I'm saying. Writes are not to file paths. They are explicitly connected to an opened file. An opened file must have already been created in a known path. And as I said before... there is no such thing as "mv" or "cp" where you have all the details of the source and destination. I have no way to know what the software is doing. There is no way to do what you think can be done.