Was BTRFS scrub on mount now flashmemory conflict/error

1st Official Post
    • New

    I recently replaced some drives on my omv server and decided to format the drives as single unit btrfs (this isn't a thread debate about format choices). My system is usually powered down but is woken up (wol) from another server to allow use as a backup destination. The following the completion of the backup on the other server the autoshutdown turns off the omv server.

    I've noticed that the omv server wasn't powering down as it used to pre btrfs drives and after investigation found that a scrub was being performed on the btrfs drives. Syslog entries suggest that the btrfs drives are being scrubbed as a result of them being mounted at power up, but not 100% sure.

    I've looked at various cron entries and can only find a weekly and monthly entry for scheduled scrubs.


    I've found in fstab an option to force a scub of btrfs on mount but this doesn't appear in my fstab.


    I've no issue with the scrub as such but instead of my omv server being powered on for typically an hour or so during a backup from my primary system it's now powered up for over 12 hours as it sequentially scrubs three btrfs formatted dives.

    I've got a second omv server that also has some btrfs formatted drives but is doesn't appear to initiate a scrub at power up. However they have been powered up at different times, omv running scrub ~midnight powerup, second non-auto-scrub (so far) powered up ~11:40. So a bit inconclusive.


    Has anyone else noticed anything similar regarding scrub initialisation?

    • New

    Just restarted my main omv server ~16:35 and no scrub initiated.

    I've found/read this thread Stop btrfs-scrub on omv boot but it talks about a scrub at every boot, not the same as what I'm seeing here.

    Is this perhaps a side effect of anacron starting either the weekly or monthly scrub task if my primary omv server is started around midnight?

    • New

    Further info

    On the primary omv server upon boot anacron is updating timestamps in /var/spool/anacron for day/week & month. I think this means that is has passed each of those cron directories.

    Code
    ls -l /var/spool/anacron
total 12
-rw------- 1 root root 9 May 19 16:28 cron.daily
-rw------- 1 root root 9 May 19 16:38 cron.monthly
-rw------- 1 root root 9 May 19 16:33 cron.weekly

    On the other omv server, that isn't doing a scrub on boot the timestamps in /var/spool/anacron are updated only for day, not week/month.

    Code
    ls -l /var/spool/anacron
total 12
-rw------- 1 root root 9 May 19 11:40 cron.daily
-rw------- 1 root root 9 May 10 08:32 cron.monthly
-rw------- 1 root root 9 May 18 08:53 cron.weekly

    hmmm, I'm also running proxmox backup server on the primary omv. I'm suspecting PBS has configured something to cause force anacron to execute at boot. My changes to use btrfs in OMV has made this noticable due to the scrub occurring because anacron has passed the cron.weekly/cron.monthly folders.


    If anyone is running a combined PBS/OMV server could they check /var/spool/anacron for updated timestamps after boot and report back.

    • New

    I understand I can disable the scrub with an environment variable, I believe the issue is deeper than the scrub as all of the cron daily/weekly/monthly entries are being executed on boot. I'm investigating further as it appears to be isolated to only one of mv omv servers, the one with proxmox backup server also installed.

    Topic title may need editing as I think that the scrub is more a symptom than the actual issue. And it's, so far, not an omv specific issue.

    Am just about to crank up a few test vm's to see if I can diagnose it further.

    I'll update here if/as I learn more.

    • New

    Sort of around in circles we go.

    Now it is looking like it's an issue with folder2ram_startup not copying /var/spool. On the omv with issues (clamav installed)


    Whereas the omv with anacron working as expected (clamav plugin not installed)

    Code
    journalctl -u folder2ram_startup.service -b
May 20 07:57:09 omv-qnap systemd[1]: Starting folder2ram_startup.service - folder2ram systemd service...
May 20 07:57:10 omv-qnap folder2ram[541]: will now start all mountpoints
May 20 07:57:11 omv-qnap folder2ram[541]: start /var/log
May 20 07:57:33 omv-qnap folder2ram[541]: start /var/lib/openmediavault/rrd
May 20 07:57:33 omv-qnap folder2ram[541]: start /var/spool
May 20 07:57:34 omv-qnap folder2ram[541]: start /var/lib/rrdcached
May 20 07:57:35 omv-qnap folder2ram[541]: start /var/lib/monit
May 20 07:57:35 omv-qnap folder2ram[541]: start /var/cache/samba
May 20 07:57:36 omv-qnap systemd[1]: Finished folder2ram_startup.service - folder2ram systemd service.


    I'm now leaning more towards a folder2ram related issue. Both systems are running openmediavault-flashmemory 7.0.1

    • New

    Uninstalled antivirus plugin and primary omv server now appears to have folder2ram initialising as expected and updating the time stamps in /var/spool/anacron which is no longer processing cron/daily/weekly/monthly as they heven't met the date since last run criteria.


    I don't have the history to check how long this may have been occuring. I feel that there is something about the antivirus plugin and folder2ram that isn't quite right.

    From what I have seen if you have a system with antivirus and folder2ram plugin installed, check /var/spool/anacron vs /var/folder2ram/var/spool/anacron to see if it's been updating on boot, also systemctl status folder2ram_startup for errors.


    [edit] created a fresh install on a vm, same result as above, conflict with permissions with clamav and flashmemory causing flashmemory (folder2ram) to fail to copy folder data to/from flash to ram.

  • greybeard

    Added the Label OMV 7.x

  • greybeard

    Changed the title of the thread from “BTRFS scrub on mount” to “Was BTRFS scrub on mount now flashmemory conflict/error”.

Participate now!

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

Register Yourself Login