On 06/29/2017 04:57 PM, Benjamin Marzinski wrote: >>> + .fast_io_fail = 10, >>> + .dev_loss = MAX_DEV_LOSS_TMO, > On Wed, Jun 28, 2017 at 07:48:38PM +0200, Xose Vazquez Perez wrote: > >> It would be nice to have more information. >> Why and when is this needed? > > I assume the change to dev_loss_tmo is simply a preference issue. Like > Netapp, they don't want their devices to get auto-removed when they go > down. I also assume that in their internal testing, they hit cases where > 5 seconds wasn't enough time to wait for some transient issue with the > array to resolve. At any rate, I'm simply passing along their request, > which seems like a perfectly reasonable one to me. Those arguments should come from the vendor. "dev_loss_tmo 14" is recommended(???) in latest 3PAR docs (Jun 2017): - HPE 3PAR SUSE Linux Enterprise Implementation Guide (Wed 14 Jun 2017 11:48:14 PM CEST) http://h20564.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay/?docId=c02663748 - HPE 3PAR Red Hat Enterprise Linux and Oracle Linux Implementation Guide (Wed 14 Jun 2017 12:10:06 AM CEST) http://h20564.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay/?docId=c04448818 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
