My experience so far

1. offizieller Beitrag

    So i have migrated from years of FreeNAS to OMV5.

    My setup is a HP Microserver 2.5Ghz CPU, 16GB RAM.

    I used to run two 4TB HD's using ZFS mirror, which worked flawlessly.


    My setup now is

    • OMV5,
    • Luks Encryption enabled,
    • ext4 file system,
    • SnapRaid enabled (1TB data, 4TB data, 4TB parity)
    • unionfs.
    • docker containers
    • Boot drive is a 30GB flash
    • I also have a 120GB SSD which i am using for config. )(also encrypted)

    I am running emby server in a docker container with its own macvlan network.


    My network is Cat6 Ethernet. My chromecast that plays movies is also on Ethernet.


    When i was on FreeNAS my high definition movies played over my network flawlessly!

    Now they are pausing/buffering randomly which is most annoying given how long it took me to rebuild this server!


    My problem is, with this build the buffering problem could be so many reasons. My gut feel is the unionfs and snapraid.


    Could somebody provide advice at where/how i should investigate?

    SnapRAID has no effect on filesystem or system performance unless an actual SnapRAID job is running on otherwise inadequate hardware.


    You can rule out unionfs as a source of the problem if you temporarily create a new library in Plex that doesn't use the union as a media source. Just add individual drives instead. If the buffering remains, look somewhere else.


    I have 40TB in a mergerfs union spanning eight drives and Plex has no problems with it. The CPU is a four core Intel Atom 2550, rather meager by today's standards.


    Edit:


    I just now saw that you are on Emby, not Plex. But that doesn't alter my suggestion about using drives instead of the union as a test.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

    It seems to be when multiple application access the file system.


    I am going to add an extra 8TB drive (i was planning to anyway and add it to my OMV instance without encryption, snap raid or union fs and see how emby performs on that. Then encrypt and see how it performs etc..


    Isolating the issue. I'll keep this post informed.

    Zitat von gderf

    You can rule out unionfs as a source of the problem if you temporarily create a new library in Plex that doesn't use the union as a media source. J.

    Hi crashtest .


    Yes the Dockers are stored on the default location. The boot drive is a 30GB Flash drive.

    I forgot to mention I also have a 120GB SSD which I map the config files to.
    Eg my docker run file looks like this.


    docker run -d \

    --name emby \

    -v /srv/dev-disk-by-uuid-832de4f2-73ac-400a-b84b-f1abfa3e27ac/config/emby:/config \ #the 120GB SSD

    -v /srv/8dfcfa9c-f641-412b-843f-606afffd9344/media:/media \ # the unionfs data store

    --device /dev/dri:/dev/dri \

    --network mynet \

    --ip 10.10.10.130 \

    -p 8096:8096 \

    -p 8920:8920 \

    -e UID=1000 \

    -e GID=100 \

    --restart unless-stopped \

    emby/embyserver:latest


    Would changing my docker location to the 120GB SSD make a difference? I was considering doing this anyway.

    • Offizieller Beitrag
    Zitat von Omvben

    Yes the Dockers are stored on the default location. The boot drive is a 30GB Flash drive.

    I forgot to mention I also have a 120GB SSD which I map the config files to.
    Eg my docker run file looks like this.

    That was the main concern. Since Dockers use overlayfs and the UnionFS plugin (mergerfs) uses overlayfs as well, moving Dockers onto the mergerfs mount point can create problems. (Overlayfs on top of overlayfs doesn't work well.)

    Do you mind my asking why you're using LUKS?
    ___________________________________________________________________


    Zitat von Omvben

    Would changing my docker location to the 120GB SSD make a difference? I was considering doing this anyway.

    Since you have the SSD for utility purposes, I would move the Docker to the SSD. At a minimum, the Web interface should be more responsive and there won't be any worries about the growth of metadata.

    If you need a bit of guidance doing it here's an example -> Move Dockers You'll need to substitute the details for your install.

    Thanks crashtest

    I have moved my docker storage to the 120GB SSD (which is also encrypted). Initial tests playing multiple movies at once with different devices seems to be good. I'll do more testing.


    LUKS encryption is not critical. I wanted my server to be encrypted as I plan to store personal data on it. If the performance was affected from the encryption then I would be okay without it.


    Thank you for your support.

    • Offizieller Beitrag
    Zitat von Omvben

    I wanted my server to be encrypted as I plan to store personal data on it.

    LUKS only protects you from the physical theft of your drives. This means, if a theft breaks in and steals your server, he won't be able to get anything from your hard drives. LUKS does nothing to prevent "over the wire" hacks which represents the vast majority of compromises.

    Zitat von Omvben

    emby definitely doesn't like playing movies whilst my server is doing an rsync

    this should be solvable by adjusting process priorities.

    maybe this general or this specific IO blog posts helps

    omv 6.9.6-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 6.1.21-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 6.9.3-1 (Shaitan) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

    Zitat von crashtest

    LUKS only protects you from the physical theft of your drives. This means, if a theft breaks in and steals your server, he won't be able to get anything from your hard drives. LUKS does nothing to prevent "over the wire" hacks which represents the vast majority of compromises.

    How much performance would be affected by encryption? MY CPU has AES.

    • Offizieller Beitrag

    Wasn't there an issue lately on the forum related to LUKS and mergerfs? Something like LUKS needs to be set to auto unlock. Sorry, but I have a bad recollection of the details. Maybe someone will fill in the details.

    • Offizieller Beitrag
    Zitat von Omvben

    How much performance would be affected by encryption? MY CPU has AES.

    I honestly don't know. (This is the best -> analysis that I could find. It's a bit dated and the distro is Ubuntu, but Debian and Ubuntu are fairly close.)

    But I do know that LUKS is not worth the down side unless we're talking about business servers or forgotten/stolen laptops where physical theft is a real possibility. (With business servers and work stations, greedy or disgruntled employees are a factor.) Businesses and Laptops are two obvious use cases for LUKS. On the other hand, losing a "home server" to theft is unlikely.


    From work back in the day, dealing with encrypted drives was a real PITA. It added an "X" factor to anything drive related. Bootable drive utilities don't work like Gparted, clonezilla, etc. In essence, if there was any kind of drive issue, encryption meant starting over.


    The main point of the argument is, a compromise of your personal data is more likely to come in over the wire, potentially from a compromised Windows client on your LAN, versus the physical theft of the server or it's hard drives .

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden