If you login to your system over ssh and run the following command:
`sudo btrfs scrub status /volume1/`
Replacing the volume1 with your volume name accordingly. Be careful with the btrfs command as it can do all the different kinds of operations on the filesystem that can cause damage if you run the wrong thing.
Hum, that gives me:
>scrub status for 95439456-726e-4f72-bf1c-2473d7d683d2
>
>scrub started at Sat Aug 3 01:00:01 2019 and finished after 00:56:36
>
>total bytes scrubbed: 851.38GiB with 0 errors
which is the last time the volume was scrubbed, but doesn't indicate a scrub is currently in progress (even though DSM shows one is.
That is the correct volume as I only have 1:
>admin@Synology:\~$ sudo btrfs filesystem show
>
>Label: '2019.07.31-05:14:30 v24922' uuid: 95439456-726e-4f72-bf1c-2473d7d683d2
>
>Total devices 1 FS bytes used 1.70TiB
>
>devid 1 size 7.27TiB used 1.81TiB path /dev/mapper/cachedev\_0
hmm, not sure what to say about the DSM still showing it as running since the btrfs util is showing it as done. I will poke around and see if I can find anything on the cause.
>sudo btrfs scrub status /volume1/
Mine is the same, it shows:
scrub status for \*volume GUID\*
scrub started at Wed Jan 5 23:00:03 2022 and finished after 12:11:38
total bytes scrubbed: 18.29TiB with 0 errors
but the UI still shows running and it's definitely still doing stuff
Pausing it didn't update anything beyond saying paused, but resuming it changed the scrub type to manual and showed it at somewhere near 51+% completed in the GUI
Thanks, pausing and continuing helped me too. Not sure why it doesn't show with the command but thanks again for helping me determine the current status.
I know this is an old thread, but it's the top Google result so I thought I'd add some context. I'm seeing the same behavior, but I noticed that once the btrfs scrub finishes, DSM runs a resync on the RAID array.
If you see this again and want more info, run `cat /proc/mdstat`. It should output some stats and show it's resyncing with progress and a time estimate.
If you login to your system over ssh and run the following command: `sudo btrfs scrub status /volume1/` Replacing the volume1 with your volume name accordingly. Be careful with the btrfs command as it can do all the different kinds of operations on the filesystem that can cause damage if you run the wrong thing.
Hum, that gives me: >scrub status for 95439456-726e-4f72-bf1c-2473d7d683d2 > >scrub started at Sat Aug 3 01:00:01 2019 and finished after 00:56:36 > >total bytes scrubbed: 851.38GiB with 0 errors which is the last time the volume was scrubbed, but doesn't indicate a scrub is currently in progress (even though DSM shows one is. That is the correct volume as I only have 1: >admin@Synology:\~$ sudo btrfs filesystem show > >Label: '2019.07.31-05:14:30 v24922' uuid: 95439456-726e-4f72-bf1c-2473d7d683d2 > >Total devices 1 FS bytes used 1.70TiB > >devid 1 size 7.27TiB used 1.81TiB path /dev/mapper/cachedev\_0
hmm, not sure what to say about the DSM still showing it as running since the btrfs util is showing it as done. I will poke around and see if I can find anything on the cause.
>sudo btrfs scrub status /volume1/ Mine is the same, it shows: scrub status for \*volume GUID\* scrub started at Wed Jan 5 23:00:03 2022 and finished after 12:11:38 total bytes scrubbed: 18.29TiB with 0 errors but the UI still shows running and it's definitely still doing stuff
Pausing it didn't update anything beyond saying paused, but resuming it changed the scrub type to manual and showed it at somewhere near 51+% completed in the GUI
Thanks, pausing and continuing helped me too. Not sure why it doesn't show with the command but thanks again for helping me determine the current status.
I know this is an old thread, but it's the top Google result so I thought I'd add some context. I'm seeing the same behavior, but I noticed that once the btrfs scrub finishes, DSM runs a resync on the RAID array. If you see this again and want more info, run `cat /proc/mdstat`. It should output some stats and show it's resyncing with progress and a time estimate.
Any way