On 06/05/2016 10:46 AM, Mladen Milinkovic wrote: > On 06/03/2016 04:05 PM, Chris Murphy wrote: > > Make certain the kernel command timer value is greater than the driver > > error recovery timeout. The former is found in sysfs, per block > > device, the latter can be get and set with smartctl. Wrong > > configuration is common (it's actually the default) when using > > consumer drives, and inevitably leads to problems, even the loss of > > the entire array. It really is a terrible default. > > Since it's first time i've heard of this I did some googling. > > Here's some nice article about these timeouts: > http://strugglers.net/~andy/blog/2015/11/09/linux-software-raid-and-drive- > timeouts/comment-page-1/ > > And some udev rules that should apply this automatically: > http://comments.gmane.org/gmane.linux.raid/48193
I think the first link there is a good one. On my system: /sys/block/sdX/device/timeout defaults to 30 seconds - long enough for a drive with short TLER setting but too short for a consumer drive. There is a Red Hat link on setting up a udev rule for it here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/task_controlling-scsi-command-timer-onlining-devices.html I thought it looked a little funny, so I combined the above with one of the VMware udev rules pre-installed on my Ubuntu system and came up with this: # Update timeout from 180 to one of your choosing: ACTION=="add|change", SUBSYSTEMS=="scsi", ATTRS{type}=="0|7|14", \ RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'" Now my attached drives automatically get this timeout without any scripting or manual setting of the timeout. James -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
