Mergerfs and moving files

1. offizieller Beitrag

    Hi,


    I just started using mergerfs, and I was wondering what happens if I move a file from one directory in the pool to another one: Can I be sure that the file will not be moved to another disk? I found the following info:


    https://github.com/trapexit/mergerfs


    https://github.com/trapexit/mergerfs/issues/248


    So apparently, if I use any "existing path" policy, I can't be sure it won't be moved. :( I kind of like the "existing path" idea, but since I often move large files, this is is no option for me.


    Is there any way to configure mergerfs so that it


    - duplicates the directory if required for a move
    - uses "existing path" otherwise?

    The problem is if the 'rename' syscall (which is what is called first when the 'mv' command is used, if the rename fails because it can't be done (on different drives) then 'mv' will copy and remove the original) is changed to not enforce path preserving (which would actually be far easier for me) then every move would result in new directories. Over time you'd end up duplicating paths around which would undermine the path preserving by other functions.


    I could add an optional flag to force renames to always respond in a non-path preserving way if, with the above understanding, you think you'd still want that behavior.

    Wow, I get to make a wish! And from the software developer himself!


    Yes, I would like that behavior. maybe my scenario is unusual, but I have one directory for all downloads, which I move to the proper place once the download is finished. If the file is large, I'd rather duplicate the directory than move it to another disk.


    And then I also have directories for personal files, which are prone to complex subdirectory structures, but there I dont move files around much, so there I'd like the existing path strategy.


    Maybe an option would be to have different strategies for creating (existing path, most space) and moving (same disk)?


    Anyway, thanks very much for your great user support!

    Rename does have it's own policy. The problem is that rename (and link) are different from other calls. 'creat' takes a single path. 'rename' takes two. A source and destination. The way it is now the policy for 'rename' applies to the source. What files to rename. Since create and rename are tightly coupled in practice (if a rename fails you use create) then I decided to use the create policy to indicate behavior in regards to path preservation.


    I don't see another way to use policies as they exist today with rename and link besides what I have done. I'm open to suggestions but rename and link are complicated.


    Adding the "ignore path preserving when renaming" is probably the easiest thing to implement and get near what you want.

    I didn't expect the update to come so fast; thank you!


    I'm currently struggling with Snapraid, so I cannot test it immediately, but as soon as this is over I will test it and let you know if it worked.

    I booted with the new option now (updated to the new version, of course), and the system booted into emergency mode, because it couldn't mount the merged filesystem.


    This is the error message:




    Do I have to recreate the merged fs? If yes, how can I do it because right now I can't boot into normal mode and use the web interface...


    Edit: I already booted once without problems after the module update, and the only thing I changed between that time and the error was adding the "ignorepponrename" (and changing the minimum free space from 4G to 100G).


    Edit2: OK, I found the fstab entry. will change it to the old versin next time I boot and see what happens.

    OK, I verified it: If I boot without the "ignorepp" option, everything is fine, but if it is present, I run into the error described above.


    Any ideas why?


    Edit: Did some more testing. When I used "mfs" as strategy, it worked even with "ignorepp", but when I tried to go back to "epmfs", after switching back to "epmfs" and clicking "apply", I got the error message:


    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v '/srv/64185790-ae6c-457a-a2df-5a15cca2c31c' 2>&1' with exit code '1': fuse: unknown option `ignorepponrename'


    Do I have to tell the "union filesystems" plugin somehow to use the updated version of mergerfs?

    • Offizieller Beitrag
    Zitat von Sean

    Do I have to tell the "union filesystems" plugin somehow to use the updated version of mergerfs?

    No. It uses whatever is installed. dpkg -l mergerfs will tell you the version.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    This is trivial to test. No need to restart the machine. The option is runtime changeable and you can try it on the command line.


    Did you set `ignorepponrename=true` or just add `ignorepponrename`? It's the former.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden