Hi Reco!
Jan 13, 2019, 1:47 PM by recovery...@enotuniq.net: > On Sun, Jan 13, 2019 at 01:20:50PM +0100, Tom Bachreier wrote: > >> Jan 13, 2019, 12:46 PM by >> recovery...@enotuniq.net >> <mailto:recovery...@enotuniq.net>>> : >> >> > On Sun, Jan 13, 2019 at 12:27:19PM +0100, Tom Bachreier wrote: >> > >> >> TLDR; >> >> My /home on dmcrypt -> software Raid5 blocks irregular usually without >> >> any error messages. >> >> >> >> I can get it going again with "fdisk -l /dev/sdx". >> >> >> >> Do you have an ideas how I can debug this issue further? Is it a dmcrypt, >> >> a dm-softraid or a hardware issue? >> >> >> > >> > Let's start with something uncommon: >> > >> >> Thanks for your suggestions. >> > > My suspicion is that either some/all HDDs' firmware or disk controller > puts drive(s) in sleep mode. > In this case: Why don't they awake with a write from dm-raid but with a read from fdisk? I don't see the logic behind. >> hdparm seems OK. Keep in mind only sdc and sdf ar WD drives. >> > > Since you have Seagates, please check them with 'hdparm -Z'. > I don't think that did much to my drives. $ hdparm -Z /dev/sdb /dev/sdb: disabling Seagate auto powersaving mode SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $ hdparm -Z /dev/sde /dev/sde: disabling Seagate auto powersaving mode SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Unsure about that Toshiba drive, though. > > I'd be wary of including those into the RAID (a single bad block can > paralyze your whole RAID): > >> DISK: /dev/sdc >> DISK: /dev/sde >> Thanks, I keep that in mind. I try to replace them in the near future. > And I'd enable it for sdd. > Done. $ smartctl -l scterc,70,70 /dev/sdd SCT Error Recovery Control set to: Read: 70 (7.0 seconds) Write: 70 (7.0 seconds) Tom
