On Sun, Jan 13, 2019 at 02:22:09PM +0100, Tom Bachreier wrote: > > 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.
RAID5 may be the reason. If you're reading a short sequence of bytes from the array it does not mean you're utilizing all the drives. > >> 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. I agree. It seems that drive's firmware rejected the request. > $ smartctl -l scterc,70,70 /dev/sdd > SCT Error Recovery Control set to: > Read: 70 (7.0 seconds) > Write: 70 (7.0 seconds) > This setting may not survive the powercycle. Happen to have four such drives. I just apply it at every reboot. Reco
