How can I avoid moving files across file systems (mechanical hard disks) caused by Path Preservation?

[Gloryandel]

OS：ArchLinux mergerfs：

df -Th

/dev/sde1                 btrfs           60G   16G   37G  30% /srv/ssd1
/dev/sde1                 btrfs           60G   16G   37G  30% /srv/container/docker
tmpfs                     tmpfs          169M  4.0K  169M   1% /run/user/1000
/dev/sda1                 btrfs          9.1T  4.1T  5.1T  45% /srv/data01
/dev/sdb1                 btrfs          3.7T  1.3T  2.4T  35% /srv/data02
/dev/sdc1                 btrfs          3.7T  1.6T  2.2T  42% /srv/data03
ssd1:data01:data02:data03 fuse.mergerfs   17T  6.9T  9.6T  42% /srv/pool/data

tree

data01
└── angel
    ├── cache
    ├── files
    ├── files_trashbin
    ├── files_versions
    └── uploads
data02
└── angel
    └── files
data03
└── angel
    ├── files
    └── files_trashbin

mergerfs -o ignorepponrename=true,dropcacheonclose=true,moveonenospc=true,minfreespace=1G /srv/ssd1:/srv/data01:/srv/data02:/srv/data03 /srv/pool/data

I need help, each of the following data are mergerfs branches, when I delete files in data03/angel/files, theoretically the files will be moved to data03/angel/files_trashbin/files. but since data01 has more space left than data03. As a result, moving files across file systems (mechanical hard disks) occurs and deleted files are moved to data01/angel/files_trashbin/files. Is there any way to resolve this similar behavior? According to the documentation you provided, there is no “move” action in Category, FUSE Functions, and there is no filesystem based policy in Policy, only path and free space based policy.

[Gloryandel]

ignorepponrename = true seems to be a way around this (if the translation and understanding is correct), so hopefully move will also implement locking files on the same filesystem.

[trapexit]

There is no "move" because there is no such thing as "move". There is rename and open/create. There is no such thing as "moving" a file the way most people think of it.

If you don't want strict path preservation then I have to ask why you've selected it. As I point out in the documentation it is a niche feature. You can use ignorepponrename but that will by definition mess up "ep" policies over time.

[Gloryandel]

Thank you very much. The "move" note can be left on your FAQ, as most people probably have a similar idea as me.

Initially, I was hoping to rely on "ep" to ensure that pool/Markdown, and pool/Download, are always on a single filesystem, with the former only having Markdown on the SSD branch so it always stays on the SSD, and the latter being used for downloads to prevent reaching a threshold that wakes up all the Mechanical Disks.

Initially I was hoping to control file allocation by manually creating directories under the pool. I seem to have found a solution by using the mspmfs (most shared path, most free space) policy, where "most shared path" means to utilize the paths that have the most public presence in the branch (the depth of the public paths), and then make a decision using the "mfs" to make decisions? Instead of using "ep" to consider only existing paths instead of falling back to public paths.

[trapexit]

I don't know what you mean by "public" but the policies work as they are described. The most shared path considers the branches with the most shared file path and then whatever the secondary function is.

[Gloryandel]

All right.Thanks for answering the questions!