Posts by Adoby

    And I can confirm that OMV 5 works perfectly fine on a 8GB RPi4.


    I just moved the card and everything else from my old 4GB RPi4 to the new 8GB RPi4, also in a FLIRC case. And it just works, as it should do.


    I don't expect to see any great benefits apart from a little better disk performance, especially when dealing with many small files, due to the significantly bigger disk caches.


    I don't notice any real problem with a full swap file that stays full. It is an indication that something is not right. But I can live with it...


    Possibly add a cron job to turn swap on and off to clear it?

    Now there is a 8GB Raspberry Pi 4 available.


    https://www.raspberrypi.org/bl…y-pi-4-on-sale-now-at-75/


    The extra memory should improve disk access, since all free RAM is used for disk caches. You are not likely to notice any improvements when copying very large files, reading or writing. But possibly when copying many small files and during normal use. Also it may make running several large docker images easier.


    I suspect that the biggest benefit from the extra RAM is when the RPi4 is used as a desktop computer for light office use and surfing. Possibly together with a SSD.


    I bought two, together with a FLIRC case. I will use one for OMV and one for testing as a desktop. I may be able to free up an old HP Elitedesk g3 800 i5 mini. Might be nice to run OMV on, as well. Plenty of USB3. Previous tests with the 4GB model as a desktop was a fail. But a close one.

    Default settings for tmpfs is to use up to half of RAM. So I think it will be detected OK.


    It is certainly possible to use some disk partition for tmp. However it will be slower.


    You may want to figure out what it is that is using up /tmp. Simply having a look inside /tmp, possibly as root, might give some clues. Sometimes software that crash can use up /tmp without ever freeing it. Updating or fixing the software so it doesn't crash can help. Or simply reboot to clear tmpfs.

    Get a mirror?


    Most likely you installed software in a way that means that flash is being used for storage. For instance docker app data with metadata databases for media servers.


    You should create a share on the hard drive and use that instead.


    There should be no need to resize partitions on the SD card. If you feel a need, then you are doing something very wrong. However the worst(?) that can happen, I assume, is only that the card fail prematurely and you may lose all data on the card. You can buy a new card, right?


    Even if you only have a 8 GB partition on a 64-128GB card, that is perfectly fine. Leave the unpartitioned parts unpartitioned. Wear leveling will make use of the whole card.

    24 means only allow clients matching the first 24 bits of the ip. That is 192.168.1. The last 8 bits can be anything. 72 or 14, 1-255


    32 means all bits must match. So only 192.168.1.72 is allowed.


    It is easy to spoof IP numbers. So using just IPs like this to secure a network is not enough.


    Either used a centralized login system.


    Or...


    Use switches/routers/IPs to setup a network that only allows nfs traffic between specific clients and servers, for instance between servers inside a server room. Or in a trusted home network.

    I noticed the same. Swap file. RPi4. Plenty of RAM available but swap file increase slowly until full. 100MB in tempfs, I think. At the moment I was doing intense sustained disk operations. Read, write, hardlink. Mergerfs. EXT4. I also tried turning off swap. Nothing bad happened. It just seems very strange. Why would swap grow? And it stayed full.

    I suggest you start testing to find out what the problem is.


    Try to isolate various possible problem causes. Test only that. Try to swap hardware.


    For instance there is no point in looking for problems in OMV or the RPI4 if other computers, using the exact same network ports and cables, also have low performance.


    Try to be systematic and eliminate causes until you find out exactly what the problem is. Think of it as a form of detective work. Look for clues. Good luck!

    No, I am pretty sure it is not the default. But DHCP leases are often kept for a while. A few hours or a few days. Most likely you can specify how long the lease will be remembered. Then, if unused, the lease is "recycled" and used for some other device. Some routers "forget" this type of temporary lease if rebooted.

    No idea about windows... Boot Linux from a thumbdrive?


    Why do you want to increase the partition size? I can't think of any good reasons, but plenty bad...


    You do have a problem with the rootfs about to be full. You could fix that instead? Figure out why and move or delete whatever it is.

    You can remove the card and put it in a sd card reader and use a partition editor in a PC to edit the partitions. I use a Linux computer and the partition editor gparted.


    But if you need to increase the partition you are doing something wrong. You shouldn't use the SD card for anything but the default root filesystem. Especially not use it for docker app data like Plex databases and so on.

    To clearify. I don't use the wifi on the RPi4. But I use it on most of my clients. Laptops and tablets. If I stream very high bitrate video and I am not in direct line of sight of one of my wifi mesh nodes, then the wifi used by the client can become the bottleneck.


    I live far out in the woods. No wifi congestion...

    In many routers it is possible to set static leases. This means that whenever the NAS use DHCP to ask for a IP to use, it always gets the same IP. And this even if you reinstall. All you have to do is to set a static lease in the router and set the NAS/armbian to use DHCP.


    I do this for several OMV NAS. And it works perfectly, even if I upgrade.


    Another nice thing about this is that there is no danger of assigning the same IP to more than one computer. I never set a static IP on a server. Instead I set a static lease for every server in the router.


    It is possible that the router also supports DNS-masquerading. Then you never have to write a IP again. Just use the host name directly.


    My OMV server nas5 has the ip 192.168.1.105, but instead of using the ip I use the name "nas5.local". Works great.

    Take a moment to configure your DHCP server (typically your router) to assign a static lease

    for your NAS. This is based on the MAC address of the network interface card.


    If you do this the network card in the NAS will always get the same IP, even after a reinstall, as long as it is configured to use DHCP.

    What do you think so far? I take it that you've tested a couple of simultaneous streams?

    It works surprisingly well. If backups are running the USB is sometimes a noticeable bottleneck. Also if I try to stream several high bitrate streams at the same time. But otherwise Emby feels very responsive and I can play any media without any problems, as long as the wifi is not the bottleneck.


    There was something strange going on with a hardlinking utility, mergerfs and the swap file. During multiple internal file transfers with a lot of hardlinking between drives, swap slowly filled, despite plenty of free RAM. And when swap was full the mergerfs processes spiked and performance went down a lot. And swap stayed full, never freed up. I changed swappiness from 1 to 0, and the problem went away... Perhaps general performance improved as well, I never measured performance precisely. The swap file is only 100MB and I haven't noticed any problems with swap all but turned off.


    The little monster is not a permanent solution. I am about to build a server from a real server case (Inter-tech 4416) and old PC parts. But the little monster means that I am not in a hurry. I have plenty of storage. A version of the little monster will most likely be used for backups once the "real" server is up.

    Scripts are run in a shell environment.


    It is possible that, unless you specified in the shebang what shell to use, the script is using another shell than the one you are using when you run the script from the cli. I am not sure what script scheduled tasks use by defalut? Possibly the default for the user that the script runs as? I have never tried to use scheduled tasks, so I don't know. I use crontab from the cli.


    For example, this shebang as the first line in the script make sure it runs in bash:


    #!/usr/bin/env bash


    ...and this in sh:


    #!/usr/bin/env sh


    And the syntax can vary a little between different shells. That might be why the script riuns OK from the cli but not as a scheduled job?


    In my experience some shells are not correctly setup in OMV. At least that was the case in OMV4. But it seems that bash was correctly setup. Try to set bash as the shell to use both for the user and in the script, unless you have good reasons to use some other shell and verify that it is correctly setup.