This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
On firmware 6.7.4 ran a scrub before leaving for the weekend on Friday, came back in today after not having received a notification that the scrub had ever finished, couldn't make any changes to the contents of any shares, was getting permission denied, even on accounts that have read/write. Reset permissions for these shares.
Finally rebooted and now the volume has disappeared. To my knowledge this system has never suffered a power failure since the last time I rebuilt. Please let me know which logs to post if any.
Yes, so there is definitely some corruption on the filesystem - unfortunately. You can probably see that yourself reading through some of those messages. It would cause issues mounting the volume and thus you see no wolume anymore. This is not a result of the scrub by the way.
It is one of the problems with running a RAID0. You are much more prone to these sort of problems as there is no fault tolerance at all. If any of the disks were stalling or if there are errors on any of the disks it can cause serious issues for a RAID0. Are all the disks OK? You can check it in the disk_info.log
Do you have have a backup of the data? If so, you are best to factory default and restore from backups. Also, you might want to consider whether RAID0 is the correct RAID for your setup? It is rather risky on 4 drives I think.
Okay, so your data RAID is active which is good. But I can see that it is a RAID0. A scrub will have no effect on a RAID0 as there is no redundancy to recover from in case of the filesystem finding corrupt versions of your files during the scrub. So, if you run a RAID0 (or any other RAID with no redundancy), don't run a scrub.
That being said, the scrub shouldn't break the volume - it just won't do anything useful. Can you enable SSH access and login to the CLI of the NAS and run this command:
journalctl | grep -i btrfs
It is to see if the system logged any filesystem warnings. We need to see if the filesystem is OK.
Yes, so there is definitely some corruption on the filesystem - unfortunately. You can probably see that yourself reading through some of those messages. It would cause issues mounting the volume and thus you see no wolume anymore. This is not a result of the scrub by the way.
It is one of the problems with running a RAID0. You are much more prone to these sort of problems as there is no fault tolerance at all. If any of the disks were stalling or if there are errors on any of the disks it can cause serious issues for a RAID0. Are all the disks OK? You can check it in the disk_info.log
Do you have have a backup of the data? If so, you are best to factory default and restore from backups. Also, you might want to consider whether RAID0 is the correct RAID for your setup? It is rather risky on 4 drives I think.
The data is not unique and I have backups I can restore from. I'll reformat as XRAID. disk_info.log does not show any issues. Here it is below for your reference, also:
Device: sda
Controller: 0
Channel: 0
Model: WL6000GSA12872E
Serial: WOL240343186
Firmware: 01.01C01
Class: SATA
Sectors: 11721532032
Pool: data
PoolType: RAID 0
PoolState: 5
PoolHostId: 117c606a
Health data
ATA Error Count: 0
Reallocated Sectors: 0
Reallocation Events: 0
Spin Retry Count: 0
Current Pending Sector Count: 0
Uncorrectable Sector Count: 0
Temperature: 36
Start/Stop Count: 184
Power-On Hours: 8504
Power Cycle Count: 133
Load Cycle Count: 153
Device: sdb
Controller: 0
Channel: 1
Model: WL6000GSA6472E
Serial: WOL240336490
Firmware: 01.0RRE2
Class: SATA
RPM: 5700
Sectors: 11721045168
Pool: data
PoolType: RAID 0
PoolState: 5
PoolHostId: 117c606a
Health data
ATA Error Count: 0
Reallocated Sectors: 0
Reallocation Events: 0
Spin Retry Count: 0
Current Pending Sector Count: 0
Uncorrectable Sector Count: 0
Temperature: 39
Start/Stop Count: 227
Power-On Hours: 8890
Power Cycle Count: 140
Load Cycle Count: 187
Device: sdc
Controller: 0
Channel: 2
Model: WL6000GSA6472E
Serial: WOL240336488
Firmware: 01.0RRE2
Class: SATA
RPM: 5700
Sectors: 11721045168
Pool: data
PoolType: RAID 0
PoolState: 5
PoolHostId: 117c606a
Health data
ATA Error Count: 0
Reallocated Sectors: 0
Reallocation Events: 0
Spin Retry Count: 0
Current Pending Sector Count: 0
Uncorrectable Sector Count: 0
Temperature: 39
Start/Stop Count: 213
Power-On Hours: 8737
Power Cycle Count: 136
Load Cycle Count: 175
Device: sdd
Controller: 0
Channel: 3
Model: WL6000GSA6472E
Serial: WOL240336487
Firmware: 01.0RRE2
Class: SATA
RPM: 5700
Sectors: 11721045168
Pool: data
PoolType: RAID 0
PoolState: 5
PoolHostId: 117c606a
Health data
ATA Error Count: 0
Reallocated Sectors: 0
Reallocation Events: 0
Spin Retry Count: 0
Current Pending Sector Count: 0
Uncorrectable Sector Count: 0
Temperature: 36
Start/Stop Count: 221
Power-On Hours: 8826
Power Cycle Count: 139
Load Cycle Count: 178
Yes, your disks seems fine here. But a RAID0 is so intolerant that any hicpus can be problematic - the more disks involved the bigger the risk. It is hard to say exactly what caused it. The point is that there is no recovery for the filesystem once it encouters errors - as there is no redundancy.
I am glad you had a backup and that you are considering a RAID with some redundancy.
Just as an FYI - things that can typically lead to filesystem corruption is:
1. Disk issues. 2. Filling the filesystem too much. You should leave about 10% free space. 3. Non-graceful shutdowns (such as power-cuts).
That is good news if you were in a potential data loss situation. ReclaiME is a good software and might find some files. BTRFS has some built-in tools for that as well, namely: BTRFS restore. But none of those really fixes the filesystem and might find corrupted versions of your files.
So unless you really need some data that isn't backed up, I would still go the factory default route.
