Mergerfs wakes harddisc

    Hi there,


    I have a problem with mergerfs and my harddiscs.
    The pooled harddisc (the first one) I use in my server are frequently woken up by mergerfs.
    First I didn't know why the discs won't stay in sleep mode but then I found a way to check what the reason is.


    Heres how I did it:

    Code
    echo 1 | tee /proc/sys/vm/block_dump
tail -f /var/log/syslog | grep sdaXXX


    I saw that mergerfs is reading some blocks from the first drive of the pool (I think it's where the hidden data of mergefs are stored) every five minutes. So the status of the harddisc is never going (or stay) in sleep mode.


    Here are my mount options from "/etc/fstab"


    Code
    /srv/dev-disk-by-id-ata-ST8000AS0002-1NA17Z_Z8416PNB-part1:/srv/dev-disk-by-id-ata-ST8000AS0002-1NA17Z_Z8414FKG-part1 -->
/srv/ef606c9f-1589-49bb-91c9-617459d99458 fuse.mergerfs defaults,allow_other,dropcacheonclose=true,use_ino,category.create=epmfs,minfreespace=40G 0 0

    I use "dropcacheonclose=true" instead of "direct_io"due to some strange behaviour of my serviio DLNA server.


    Can someone point me in the right direction ?

    Meanwhile I Know that two docker Container seem to be the issue. As I need them I reread your Git page. Is it correct that mergerfs uses the first disc for a hidden file which Has Some Kind of cache/journal? I now put in a Ssd as first disc. At a first glance that solved My Problem.


    Gesendet von meinem LG-H870 mit Tapatalk

    I'm not entirely sure what you're asking. mergerfs doesn't store anything for itself on the drives and doesn't query the underlying drives on its own. The access pattern depends on something requesting it and the policy of the request.

    Sorry,


    my fault.
    I mixed up something in my mind with the pseudo file you mention on your github page.


    It seems that the serviio and roon container trigger the access to the file system and wake up the harddiscs.
    BTW: Can you show me how I get some information from mergerfs that shows exactly which process issues that ?


    Anyhow ... is there a way I could add some kind of caching to mergerfs to prevent these disks to spinup ?

    Really the only way would be to run it manually in debug mode. `-d`



    Ideally you'd disable whatever is querying the data. The OS caches some info but if the OS asks mergerfs for data it has no choice but to passthrough the request. IMO adding caching to mergerfs isn't the solution. There are already multiple caches in the stack. I've not yet tried it but one idea is to use lvm caching in front of your hard drives but that'd require using lvm on all target drives.


    If you don't need to point those services as the pool then don't. Use an ssd or something as a staging ground and transfer when you need/want.

    Well I'll try that. LVM is no solution for me. I used IT but after one disc died I had to rebuilt the whole data. That took ages. If I find a way a round I'll report here


    Gesendet von meinem LG-H870 mit Tapatalk

    You wouldn't concat the drives together. You'd create for each drive their own physical and logical volume and put the filesystem on top of that. Then partition the ssd N ways and give one cache and metadata partition to each.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden