monit alert -- Resource limit matched rootfs

  • I am directly rsync-ing some large files (30+gb) to the hard disk - but the system still keeps on caching the stream on the SD card

    No ideas why - this used to happen on a HP Unix system 25 years ago when the kernel used to get flooded by input.

    The emails I get are like

    Description: space usage 92.2% matches resource limit [space usage>85.0%]

    Why does the OVM system not simply follow the symlink directly and not appear to store the data on the SD card ($HOME) first - seems a bit strange.

    Does anyone have a better solution than increasing the Resource Limit to 90%

    Is this a 'bug' that needs to be fixed ?

    My old QNAP 219 never had this problem (!)



    • Official Post

    I use rsync all the time, it is how I backup my OMV servers to other OMV servers, and I don't see this problem.

    Perhaps you could describe the source and destination and the rsync command line used?

  • Certainly I can

    I still have the Qnap - I use this and the OMV/RockPro64 together (the RockPro64 has yet to convince me that it is a keeper ! )

    All my rsync jobs are controlled by a sync script that is called with the desired params, see below

    This is the RockPro rsync command - this has the OMV running on it

    /usr/bin/rsync -rlptDuv -e /usr/bin/ssh --progress /home/graham/media/ graham@rock:/home/graham/media

    Here is the Qnap rsync line

    /usr/bin/rsync -rlptDuv -e /usr/bin/ssh --progress /home/graham/media/ graham@qnap:/share/homes/graham/media

    As you can see they are almost identical - as would be expected using the same sync script - I have been using this script for many years with no problems until the OMV/RP64 came along !

    In both cases the '/home(s)/graham/media' is a symlink to the hard disk so nothing should be getting copied to the SD card on the RP64.

    If you have any suggestions I would be most grateful

  • I edited my first reply to say that In both cases the '/home(s)/graham/media' is a symlink - quite possible you did not see that.

    Mind you I have found a folder of junk that shouldn't be in my home - so that has helped a bit.

    Now all that is in my home are symlinks

    lrwxrwxrwx 1 graham users 22 Feb 22 10:54 bin -> /home/graham/work/bin/
    lrwxrwxrwx 1 graham users 33 Jan 31 17:16 media -> /sharedfolders/RP64D1Media/media/
    lrwxrwxrwx 1 graham users 31 Jan 31 17:15 work -> /sharedfolders/RP64D1Work/work/

    • Official Post

    If you use a symlink in the source path you can use -L to have rsync follow it. I have no idea how you do that in the destination path. Or even if rsync allows that.

    But why not simply use the real path to media? That should work fine.

  • I shall try the -L option - you add it to the list of options in the rsync call - these get passed to the remote rsync server (AFAIK anyway).

    My understanding of the -L is when copying/syncing folders/files as found in the list of things to sync, the destination (home/etc) folder is a symlink but not quite in the same way as the files to be sync'd.

    The reason for using symlinks from the home directory is for convenience and simplicity - if the destination folder/drive/etc is ever changed then a simple symlink update is all that is needed to restore order. This doesn't really work in M$ Windows, or at least it never used to - but as I don't use tit I am not affected.

    I shall try the -L idea tomorrow - thanks for the suggestion

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!