MergerFS

  • 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:


  • Unfortunately that doesn't mean much to me. That's from the ftp server? Is it a new file? Overwriting an old one? A unique directory across the drives or on multiple?


    If it's a new file it shouldn't even be created on any drive with less than minfreespace so unless you're writing files larger than minfreespace (all things being equal, no new files on the drive while the transfer is happening) it won't even hit the drive limit and trigger moveonenospc.

  • 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.

  • Without knowing what the ftp server is doing (anyone know what project it is?) I can't comment fully but it sounds like they are doing something weird. All I can suggest is for the ftp server to be straced while the transfer happens and I could then see what it's really complaining about since their logs are lacking.

Jetzt mitmachen!

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