6.1.6 [RC10] Hangs System on Initial Installation Only

[JMehring]

Just a FYI incase this is happening to anyone else (I noticed someone posted about this the the defrag hangs thread).

I upgraded my ReadyNas Ultra 6 Plus from OS 6.1.4 to 6.1.6 [RC10] (encrypted file system) due to non responsive issues. The upgraded OS installed fine and once the system rebooted I immediately was able to log in to the newly created 6.1.6 [RC10] NAS via ssh. I started a 'top' to check things out and about a minute later the system became non responsive for at least 30 minutes (I had to manually power off NAS). I was still able to ping the NAS during this time though.

After restarting the NAS, I have not yet had any non responsive issues yet; cross fingers 🙂

I did notice that the disks did not start an auto scrub when I shut down the system by manually powering off. I thought that was odd since I figured it would check to make sure raid array did not have problems, so I manually started a scrub.

The manually started scrub seems to be taking about 2 times longer than it used to, but I figure maybe that's due to the new tweaks. I also noticed that the progress indication of percentage complete of the scrub is way way off. Right now it says its only 5.06% complete when its really like 50% complete:

root:~# btrfs scrub status /data
scrub status for d2d2b9e8-9acb-4fd9-8152-9c7c0bebc294
	scrub started at Sat Jan 18 15:51:03 2014, running for 164811 seconds
	total bytes scrubbed: 6.23TiB with 0 errors

root:~# btrfs filesystem show /data
Label: 33  uuid: d2d2b9e8-9acb-4fd9-8152-9c7c0bebc294
	Total devices 1 FS bytes used 7.90TiB
	devid    1 size 14.54TiB used 8.03TiB path /dev/mapper/data-0

[Skywalker]

JMehring wrote:
I also noticed that the progress indication of percentage complete of the scrub is way way off. Right now it says its only 5.06% complete when its really like 50% complete

The scub operation does a full RAID scrub in addition to the filesystem scrub, which also gets figured into the progress calculation. Check /proc/mdstat to see that status.

[JMehring]

Thanks.

I checked /proc/mdstat. Does not look like there is much of a status on progress though, unless the [UUUUUU] means something.

root:~# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md127 : active raid6 sda3[11] sdf3[6] sde3[7] sdd3[8] sdc3[9] sdb3[10]
      15608674560 blocks super 1.2 level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]
      
md1 : active raid6 sdf2[0] sda2[5] sdb2[4] sdc2[3] sdd2[2] sde2[1]
      2095104 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      
md0 : active raid1 sda1[11] sdf1[6] sde1[7] sdd1[8] sdc1[9] sdb1[10]
      4190208 blocks super 1.2 [6/6] [UUUUUU]
      
unused devices: <none>

root:~# btrfs scrub status /data
scrub status for d2d2b9e8-9acb-4fd9-8152-9c7c0bebc294
	scrub started at Sat Jan 18 15:51:03 2014, running for 176605 seconds
	total bytes scrubbed: 6.84TiB with 0 errors

[mdgm-ntgr]

Maybe it does one scrub then the other or does it do them both at once?

[Skywalker]

It should do both concurrently. But it looks like this is an actual bug, in cases where the RAID scrub finished before the filesystem scrub. We should be able to fix this for 6.1.6 final. Thanks for reporting this JMehring. I haven't been able to reproduce your hang issue yet though.

[JMehring]

The hang issue could be a fluke, but another user did report same issue so I reported it.

The other question is that is it 'normal' that when I had to shut down the unit manually by powering off the NAS via the power switch that when it rebooted it did not automatically start a scrub to verify drive integrity.

Maybe this did not happen since the unit hung within a few minutes of initial booting or maybe BTRFS did not report any errors so it did not think it needed to be done.

Just reporting this issue as well in case its a bug. I did not mind manually selecting scrub from gui.

[Skywalker]

The current approach is to let the user decide if he wants to do a scrub. Since BTRFS will verify checksums on every read, a scrub will just inform you earlier.

[StephenB]

Skywalker wrote:
The current approach is to let the user decide if he wants to do a scrub. Since BTRFS will verify checksums on every read, a scrub will just inform you earlier.

I agree that the system shouldn't scrub at power up. It is not the same as a volume check.

But I would like to be able to schedule scrubs like I can with OS4. Also, I'd like to schedule defrags.

[ljung]

StephenB wrote:
Skywalker wrote: The current approach is to let the user decide if he wants to do a scrub. Since BTRFS will verify checksums on every read, a scrub will just inform you earlier. I agree that the system shouldn't scrub at power up. It is not the same as a volume check. But I would like to be able to schedule scrubs like I can with OS4. Also, I'd like to schedule defrags.

+1 on that

[Skywalker]

+1 from me too. 🙂 But I do know that it is being worked on.

[xeltros]

There is also the autodefrag option for BTRFS, could be a good option too for normal system (no DB intensive work).

[Nessi]

Skywalker wrote:
The current approach is to let the user decide if he wants to do a scrub. Since BTRFS will verify checksums on every read, a scrub will just inform you earlier.

you mean this checksum : Frontview->System->Volumes->Data->Settings ?
Its disabled by default.

[Skywalker]

Yes, that's true on ARM systems, but not on x86 like he is using.

[Nessi]

After updating from RC10 to RC11, the RN104 had to reboot.
On the LCD panel was the message “the system is rebooting …” but nothing happens.
No disk access, no Web GUI but ping responds.
After 4h I disconnected power and started it again. After the reboot everything looks good now.