On 2019/4/16 下午3:46, Daniel Brunner wrote: > Hi, > > thanks for the quick response. > > The filesystem went read-only on its own right at the first read error.
Then the fs metadata should get corrupted. > I unmounted all mounts and rebooted (just to be sure). > > I ran the command you suggested with --progress > All output is flushed away with thousands of lines like those at the > end of the log paste. Then please stop that running command, as it won't help much. Regular "btrfs check --readonly" should be able to report the metadata corruption. > > Does it make sense to let it run until the end or can I assume that 2 > drives are bad? No need to continue, there should be some metadata corruption. Above command should report something. For the device corruption part, I'm not sure. But I think there is definitely something wrong. Please start salvage your data, as I'm afraid the fs is already damaged, although not sure how serious it is. Thanks, Qu > Also I checked SMART values but they seem to be ok. > > https://0x0.st/zNg6.log > > -- Daniel > > Am Mo., 15. Apr. 2019 um 13:58 Uhr schrieb Qu Wenruo <quwenruo.bt...@gmx.com>: >> >> >> >> On 2019/4/15 下午7:44, Daniel Brunner wrote: >>> Hi, >>> >>> after normal a reboot I noticed that many files fail to open / read >>> (Input/Output error). I don't really have a backup of it (only >>> snapshots which also seem to be corrupted too). >>> The machine is remote, I can only ssh into it (at the moment). The >>> raid consists of 8x 10TB drives. >>> >>> System & Metadata is RAID1 >>> Data is RAID6 >>> >>> kernel is the most recent from arch linux repositories: >>> 5.0.7-arch1-1-ARCH #1 SMP PREEMPT Mon Apr 8 10:37:08 UTC 2019 x86_64 >>> GNU/Linux >>> >>> Disk layout & usage: >>> https://0x0.st/zNBl.log >>> >>> Output of btrfs check: >>> https://0x0.st/zNJs.log >> >> Strange, btrfs check reports no error at all. >> >> Would you please try btrfs check unmounted just in case. >> >>> >>> Kernel messages: >>> http://cwillu.com:8080/84.115.44.105/2 >> >> According to the dmesg, it looks like one device is bad, affecting both >> data and metadata. >> >> And thanks to recent RAID6 enhancement to try all possible mirror >> combination, it doesn't cause too many problem to metadata at least. >> >> Although data csum is not that good. >> Quite a lot of combination doesn't match checksum, and even more, some >> check doesn't exist in csum tree. >> >> An unmounted btrfs check is recommended. >> # btrfs check --check-data-csum --readonly >> >> This would be better than scrub. >> >> And please check the SMART info, some devices look suspicious. >> >> Also, please remount the fs read only at least to prevent further >> corruption. >> >> Thanks, >> Qu >> >>> >>> btrfs scrub is running but it seems like it will take weeks to finish... >>> >>> Do you think my data is gone or is there anything I can try? An rsync >>> is already running, but every 5th file fails to read. >>> >>> Best regards, >>> Daniel >>> >>
signature.asc
Description: OpenPGP digital signature
