Wanted to update this. It appears omv-mkconf backup backup had made a backup underneath the mount point. Not sure how and and why it did that or was allowed to write to the root area instead of the mount point of sde1. Anyway, it is solved now. Will keep a eye on it. Perhaps sde1 got unmounted at some point and when omv-mkconf backup backup ran it wrote to the root disk. Bazaar!
Code/dev/sda2 on /media/27b type ext4 (rw,noexec,relatime,discard,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group,_netdev)/dev/sda2 on /var/lib/docker/openmediavault type ext4 (rw,relatime,discard,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)/dev/sda2 on /var/lib/docker/openmediavault/aufs type ext4 (rw,relatime,discard,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)none on /var/lib/docker/openmediavault/aufs/mnt/f98d67526affaafc8e87a976b82df05e91ee66bb141ba552fb487528f66eaec2 type aufs (rw,relatime,si=5f27b6765f88ba2b,dio,dirperm1)shm on /var/lib/docker/openmediavault/containers/17f62ae078464f393d52d2025f67a0648af12e75032b9e54c165fb8915e8f24f/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)none on /var/lib/docker/openmediavault/aufs/mnt/4ae357b7268758f7003fa1e6390127e0117a99b5786b83c85847d1c0c181fa6f type aufs (rw,relatime,si=5f27b674932e7a2b,dio,dirperm1)shm on /var/lib/docker/openmediavault/containers/398b22367a53b17ae16da2780dac331077681616afe82337e10d2a257322e540/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)none on /var/lib/docker/openmediavault/aufs/mnt/0cce45bd495e2ef1108dbb3492b95d70f8a107c27fa6a53a8ad16b60d10ef60b type aufs (rw,relatime,si=5f27b67493f9ea2b,dio,dirperm1)shm on /var/lib/docker/openmediavault/containers/052fe1351199977189a20d5ba5baa8489aa34614e25b882a6d02b36ebe552f7c/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)192.168.90.9:/ on /media/27b/omv-1 type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.90.10,local_lock=none,addr=192.168.90.9)/dev/disk/by-uuid/bcb on /var/folder2ram/var/log type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)/dev/disk/by-uuid/bcb on /var/folder2ram/var/tmp type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)/dev/disk/by-uuid/bcb on /var/folder2ram/var/lib/openmediavault/rrd type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)/dev/disk/by-uuid/bcb on /var/folder2ram/var/spool type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)/dev/disk/by-uuid/bcb on /var/folder2ram/var/lib/rrdcached type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)/dev/disk/by-uuid/bcb on /var/folder2ram/var/lib/monit type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,data=ordered)
I did the one for Docker and it didn't show anything different after unmounting that filesystem. I too am beginning to suspect something is up with the flash memory plug in (those that show with folder2ram).
Could be that the docker is filling it up?
The location for Docker is on:
Only 6% used. /dev/sda1 is the area of concern.
Login via console or ssh and cd /
Then as root run: du -sh *
Examine the directory sizes to see which one got filled up.
This is what I am getting. It doesn't really help me pinpoint the problematic files:Code
I am on Stoneburner for my main media system. Long story of why I cannot yet upgrade this one including need for TFTP server, iSCSI targets etc.
Anyway, this system has been going great and has been rock solid for quite a number of years. However, within the last few months the root filesystem has become 100% filled and I cannot seem be able to locate what is causing it.
I run Docker with three containers including MythTV and Emby and false media plugin. It has NFS exports also.
Anyway, as mentioned earlier, it has been running all this great for quite some time but it appears something (perhaps a package update) may have caused this.
If you can help suggest what I can try next, please let me know.
I have seen very little difference using anything bigger than bs=1M. So, I use it for everything.
Give this a try (it's dependent on hardware whether 1M will be the max or you can get to 8M etc.):
The long answer here with dd_obs_test.sh:
Scripts here for better copy:
It was straight dd with source, and destination only.
OK, cool. There is a great script out there that allows you to calculate the optimal blocksize (bs=). I find it makes a big difference on speed of copy.
BTW - doesn't OMV have issues with this method since it depends a lot on disk-id? Did you have to change it anywhere?
So, before I attempt an upgrade from one version of OMV to the next, I make an exact copy of my current disk, and I do the upgrade on the copy. Also, make sure you (on the copy) uninstall any plugins that do not have a corresponding plugin on the later version version of OMV. Then perform the upgrade on the stripped down copy. If something goes wrong, you can try again on by making another copy of your current install, then attempt the upgrade again on the copy.
I assume you use 'dd' for this (or clonezilla)? If so, can you provide your command just so I'm not overlooking any extra attributes/properties for it. Thanks.
Any good docker version alternative that can be used instead? What about something like this guy has done, is it sufficient?
EDIT: Actually, wouldn't this suffice in OMV 4.x until a plugin is ready?
I'm happy to stay on Stoneburner as mentioned before, but now that my other OMVs are on 4.x and working well, I would consider upgrading if LIO would be as simple as shown in the last link above.
I am seeing these:Code
pid 1272 is: /usr/bin/monit -c /etc/monit/monitrc
which seems to point to this monit file:
Any ideas why this is happening and how to resolve?
There will probably never be an iscsitarget plugin on OMV 4.x. Volker mentioned re-writing it for OMV 5.x.
Yes, indeed he did state that. Oh well....hopefully I can stay on SB until then.
omv-mkconf backup backup
iscsi works on OMV 3.x if you use the 3.16 kernel.
Great on the backup, that works.
Since I am moving to OMV 4.x, I'll wait for support there. Is there any real advantage to moving to 3.x at this time if the system (main Media Server) is working perfectly?
Yes, ran into the same problem. OMV should really try to work around having fsname included as it really helps 'df' output.
Actually, do you also know what this is for Stoneburner? The above doesn't seem to do anything. I still have to keep this one server on Stoneburner as it has iscsi targets.