Beiträge von rbnet

    I mean... for me problem solved, but below I report my test.


    The test environment is OMV3 installed under Virtualbox.


    OMV3 is updated to the latest version 3.0.81. There are 3x1GB Virtual HD formatted in EXT4 and correctly mounted, labeled one, two, three.


    Active services: NFS, SAMBA, SSH and FTP with default parameters.


    MergerFS V. 2.22.1 is the only installed & activated plugin.


    Through mergerfs plugin I created a pool called myufs with the following options:


    Code
    Name: myufs
    HDs: one + two + three
    Create Policy: LFS
    Minimum Free Space: 50M
    Options: defaults,allow_other,direct_io,use_ino,moveonenospc=true



    Within myufs pool I created a shared folder called myshare:


    The only user in OMV (myusr) has all the privileges on the share.


    I finally added the shared folder as share to NFS, SAMBA, and FTP services.


    To test the environment I created three files of 450MB (dd if = / dev / zero of = testfilex.dat bs = 1M count = 450) on my local machine, which I then copied using the various protocols / services in the shared folder on pool created by MergerFS.



    Code
    -rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile1.dat
    -rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile2.dat
    -rw-r--r-- 1 rbnet rbnet 471859200 juin 28 10:26 testfile3.dat


    Through samba, nfs and scp I then copied one file at a time into the share using the various services.


    The first file (testfile1.dat) goes always on the HD labeled, three, second file (testfile2.dat) goes on the same HD, as previous settings (policy LFS).


    With the second file copied on HD, the free space in the HD is 70MB.


    When I start copying the third file (testfile3.dat), initially it is copied in the HD three because of free space 70MB > minfreespace 50MB. When the HD is filled the file is moved to a HD (labeled one in this case) with enough space to hold it. This is when moveonenospc is triggered, right?


    For simplicity I have captured the intial copy on the HD three and the next "move" of the file on HD one using the Filesystem Status of OMV AdminCP:


    The initial state (before copying the 3rd file):


    During the copy of 3rd file:


    after the copy of 3rd file:


    This is exactly the behaviour for all file transfer with SAMBA, NFS, SCP and (locally) for the cp/mv commands. And it is correct.



    With FTP, instead, I have obtained errors about a broken PIPE, regardless the client used, when I copy the third file (same environment as above, obviously). This is a log of Filezilla when the error is triggered during the upload of testfile3.dat:



    Same things with FTP via Shell (or any other FTP client):



    Then I discovered that is necessary to enable the option "Resume - Allow clients to resume interrupted uploads and downloads" on the OMV FTP options to avoid the error with FTP and the moveonenospc=true option



    Now, If I repeat the same steps of uploading the three file, the error about the broken pipe on the third file is handled by the FTP client (if it can resume the interrupted uploads) that can automatically resume and finish the upload of the file in the new HD.


    Simply this.


    For me problem solved.


    Thank you.

    Simply enabling "Resume - Allow clients to resume interrupted uploads and downloads" in the OMV FTP options do the trick. The error during the copy is automatically handled by Filezilla now:


    The setup is the one published above. It is a fresh and updated test-installation of OMV3 in Virtualbox under Linux (4.10.0-24). In OMV3 I have activated only SSH and FTP (with default options) services and MergerFS (2.22.1) is the only plugin installed. There's only a shared folder created in the MergerFS pool device. I'm using the default options for mergerfs plus moveonenospc=true. That's all. Let me know if you need more infos.

    Problem seems solved with last version 2.22.1, thank you trapexit. Tested copying files via shell.


    Is it normal that, with moveonenospc=true, filezilla has a weird behavior and continues to show to "skip/rename/etc." the file untill the same file is written and left truncated in the (filled) HD (see img)?



    Policy are not path preserving.
    Is this a case similar to that reported in the readme on github (rename & link paragraph)?

    I'm having the same problem in a fresh installation of OMV3 in a VirtualBox VM.


    The system is updated to the latest version, including mergerfs (v 2.22.0).


    I'm getting Transport endpoint is not connected every time a disk is filled by a file and moveonenospc is set to true: the file filling the disk is left truncated.





    Code
    # mergerfs -v
    mergerfs version: 2.22.0
    FUSE library version: 2.9.7
    fusermount version: 2.9.3
    using FUSE kernel interface version 7.19



    Found this in /var/log/kern.log



    Code
    Jun 23 15:33:10 omv3 kernel: [   98.853829] mergerfs[506]: segfault at 0 ip 00007fee3d7d0c3a sp 00007fee3cf441d8 error 4 in libc-2.19.so[7fee3d74f000+1a1000]

    When I try to change a configuration option from the GUI pressing the last "apply" button, then "An error has occurred" popup and an email containing "monit alert - Does not exist Service nginx" message is sent. Then, after few seconds, another email is sent with the "monit alert - Exists nginx" message. The GUI remains accessible, but it is almost impossible to use.


    I've tried to use omv-firstaid with the 2nd options, but the error persists. Before that I've had some errors with collectd service that I've fixed with the same omv-firstaid command with "Fix RRD database" option.


    Anything I can try?


    OMV 2.2.4.

    Hi,
    I'm using mergerfs on OMV 2.2.4 for a few days and everything works well. I'd like to use the eplfs policy that is not present in the plugin interface for OMV 2.


    I'm using a VM for all the tests.


    I've edited /etc/default/openmediavault with this:


    Code
    OMV_FSTAB_MNTOPS_MERGERFS="category.create=eplfs,category.search=newest,defaults,allow_other,moveonenospc=true,minfreespace=10G,fsname=mergerfs"


    Then:


    Code
    omv-mkconf fstab


    and rebooted.


    The new values were not applied at all and only moveonenospc=true is present (@default moveonenospc is set to false).



    Then I 've noticed that the /etc/fstab reports both the values, those set as default in /etc/default/openmediavault and those set from the plugin interface, and I think that the latest are taking precedence.


    Code
    /media/80526d75-18b1-4897-93f4-d3efadc72afb:/media/5613597f-7839-4a90-b682-693fdcc4b3dd:/media/6dd23c37-48d5-44f3-9aed-0419615e9310 /media/ba052b85-76d6-4d0d-bb41-d7ef2f50cb51 fuse.mergerfs category.create=eplfs,category.search=newest,defaults,allow_other,moveonenospc=true,minfreespace=10G,fsname=mergerfs,category.create=epmfs,minfreespace=4G 0 0


    What am I doing wrong?


    OMV Version: 2.2.4
    mergerfs version: 2.13.1
    fusermount version: 2.9.4
    FUSE library version: 2.9.4
    using FUSE kernel interface version 7.19

    Not an elegant solution, but as a temporary workaround you can use the Autoshutdown plugin using the LOADPROCNAMES options with the "snapraid" process name. You have to remember to launch the Sync from the GUI and then you can exit. When finished the autoshutdown plugin will shutdown OMV for you. I'm testing this method in a VM and it works well, for now.

    Thanks for your response trapexit.


    English is not my native language so maybe I did not understand exactly what you have written or the doc of mergerfs.
    I have limited myself to install the Unionfilesystem plugin and set the options for mergerfs with the parameters already mentioned (epmfs & 20M for minfreespace option) and recompiled the .deb for FUSE 2.9.4.
    The value shown in the .mergerfs pseudfile for moveonenospc parameter is set to false (user.mergerfs.moveonenospc="false").
    If all the drives have the available space < minfreespace, the "chain" of the epmfs fallback for the create category (with a minfreespace parameter defined) is: epmfs->mfs->ff (is this right?).
    At the ff "level", what's the expected behaviour for the new added files?


    I'm sorry to ask a probable very obvious question...

    I'm trying to use mergerfs from Unionfilesystem plugin in a VM to test if it is suitable for my real OMV installation.
    My VM has 3 HDs of different sizes (2x200MB and 1x 400MB) and mergerfs is set to use epmfs with a minfreespace of 20M. I have tried to fill the HDs expecting an error when the free space on every HDs reached the 20M limit, but I have been able to fill the Virtual HDs, regardless the minfreespace option. Is there a method to force mergerfs to honor the minfreespace in OMV?


    OMV 2.2.4

    I'm sorry for the stupid question, but how is supposed to be used the SnapRAID's read-only pool? The name that I put in the field "Pool Share Name" in the SnapRAID configuration page (eg: "MyReadOnlyPool") isn't referenced anywhere in the OMV interface. The only change that I've noticed when I've created the pool is the creation of a "pool" directory (and not "MyReadOnlyPool") in the /media dir of the root disk. I dont' see any method to share this dir with the OMV GUI, only by hand. I'm testing the last version of SnapRAID in a VM installation of OMV 2.1.18