Greyhole problem, slow network transfer

1. offizieller Beitrag

    I have Greyhole setup on OMV 0.5.35 in an HP N40L with 2 SATA drives in the storage pool.
    I am suffering from terrible network transfer speeds on the pooled drives. I have several SMB shares setup which all appear on a windows machine on the local (Gb) network but when transferring to the shares the speeds do not exceed 6MB/s and are more normally below 3MB/s. However I also have another drive on the server that is not in the Greyhole pool and can transfer the same file to it over the same network, from the same Windows machine at 110MB/s


    From my searching the forum this is most likely something I have done wrong in the setup of Greyhole. Can anyone point me in a direction to start diagnosing.?
    Please be gentle as I am not overly familiar with Greyhole or OMV (or Linux for that matter!!) :)

    I am transferring files from a Windows 8 PC to the server using a confirmed wired Gb network. As I said in my original post I can transfer the same file from the same Windows 8 PC to the share on the server that is not in the Greyhole pool and it transfers at a steady 110MB/s
    When transferring that file to one of the shares in the Greyhole pool however, speeds never exceed 6MB/s

    Ok, thanks. I appreciate the help.


    Not sure if this is relevant but I ran the Greyhole support script and the only thing that jumped out at me from the log URL it generated was this..


    ## Disks information
    WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
    WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
    WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.


    I can't find a definitive answer as to whether the fsck job that greyhole runs has a problem with GPT disks.!?!?

    Ok, after a long and helpful conversation with Guillaume Boudreau at his own support forum, he is at a loss for an explanation. It appears that the greyhole spool folder is getting slammed with writes, transferring the spool folder to a ramdisk solved the problem but is obviously not a permanent solution, Mr Boudreau is going to attempt to replicate the issue himself and potentially issue a fix.
    I have to say that I am very impressed with his commitment to his product and willingness to walk me through tracking the problems source.


    If anyone wants to track the conversation it is at.. https://getsatisfaction.com/gr…network_transfer_problems

    • Offizieller Beitrag

    I agree that his support is excellent. He has been very helpful to me when porting and enhancing the plugin. If he finds a solution and it requires a change to the plugin, please let me know.

    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!

    I did some testing last night and had same issue on a vm. Read/writes were slow even to samba share that were not being used by greyhole. The share was on one of the pool disks though. There was an upgrade to greyhole recently. Did you upgrade to that version or did you have this with the version that was installed with the plugin????

    • Offizieller Beitrag

    The plugin installs the latest version right from the greyhole repo. It will also show up as an update whenever Guillaume updates his repo.

    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!

    If anyone wants to try, I built a 0.9.45 version that I didn't push into my repos yet, in an attempt to fix this.


    The issue is that in my attempt to resolve an issue with Windows clients, I started logging file writes in the Samba VFS module. And apparently, my new code is getting called for just about every packet received by Samba! That is a lot of writes to the Greyhole spool folder (/var/spool/greyhole), for nothing (because all those writes always overwrite the last write!)


    Like H1land3r said, I 'fixed' by using a tmpfs (RAM disk) spool folder. A better version of that fix is now in 0.9.45, if anyone wants to try it.
    Will push to the official repos as soon as this gets a little more testing.

    Just to keep everyone up to date, I installed Mr Boudreau's fix this morning and, after limited testing it appears to have solved the problem. File transfers are now up around 100MB/s where I would expect them to be. I have let him know that I am happy to run through whatever testing regime he would like done in order to prove the integrity of his fix so that it can be rolled out to the official repo.
    Got to say I am impressed with the level of support here.. I have gone from a previously unreported and unidentified problem, through confirming and narrowing down the problem with a developer and having a fix rolled out within 24 hours.!! Kudos to all involved...


    Oh and if I understand the way the plugin works correctly from what ryecoaaron said earlier in this thread, once the fix is rolled out to the official repo the update should appear as an update to the plugin automatically within OMV.?! Please correct me if that assumption is wrong.

    • Offizieller Beitrag

    As soon as it is in the repo, it should show up as an update (might have to click Check) in the web interface. If you want to try it ahead of time, you can manually upload it using the Updates page as well.


    Glad to hear it is fixed :)

    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!

    He and I are still working through some other issues that have shown up as a result of the testing. I will let you know when he feels happy to upload to the official repo so that you can possibly make some sort of announcement to have folks update their servers. One of the other issues that showed up was resulting in file duplication not taking place so there may well be an issue there for people.

    Sorry for lack of updates, had to step out for the afternoon.


    Looks like he's got it nailed. Still need to run some more tests to be sure it's robust but file transfer is back to what it should be and the file replication error has been corrected. I am currently running 0.9.45-3 that I was asked to test this afternoon (UK time). I am basically just going to throw a bunch of files at it later tonight to ensure that both transfer and replication are robust. I am sure that Mr Boudreau is running a much more thorough battery of tests so hopefully the fix will appear in the repo soon enough.


    If anyone else wants to try some tests on this version, the link to it is on the bottom of the thread over at the Greyhole forum I linked to earlier.

    Just want to say that I recently set up the plugin, and experience the same issue copying from a 64 bit Win7 to OMV with Greyhole over a gigabit network. Both machines use wired connections. Writing to a Greyhole share is ~3.5Mb/sec, writing to a standard Samba share ( which resides on the same disk as the Greyhole pool, but not managed by Greyhole ) is around 80Mb/sec.


    Glad to see that I'm not alone with the problem, and that it's being addressed. ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden