From: pg@raid.list.sabi.co.UK (Peter Grandi)
To: list Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: SSD based sw RAID: is ERC/TLER really important?
Date: Mon, 26 Jul 2021 09:57:18 +0200 [thread overview]
Message-ID: <24830.27358.78544.178603@cyme.ty.sabi.co.uk> (raw)
In-Reply-To: <85c7e18c-5a77-2a20-b170-2a45d7e37dc7@turmel.org>
[...]
> I must not be the only one ignoring you, causing you to use
> multiple subdomains.
It seems sad that my changing address occasionally when they get
spammed as they get "harvested" may tickle someone's foolish
arrogance of thinking themselves so important that it is done
just to get their worthless attention.
http://www.sabi.co.uk/blog/0705may.html?070527c#070527c
Unfortunately in some cases my technical comments therefore get
replies without any technical content. As to this though:
> without going in detail about all other possible cases.
There are indeed many twists and turns and "legacy" situations,
as in several places timeouts and retries are hardcoded, and
IIRC the "default" for retries is 5. But I have spent a bit of
time looking at some of the weirdness and it turns out that
nowadays the 'sd' module defines a 'max_retries' setting in the
device attributes (rather than a module parameter as in
'nvme_core'):
https://elixir.bootlin.com/linux/latest/source/drivers/scsi/sd.c#L598
It is only available from 5.10 and would be for example at:
/sys/class/scsi_disk/0:0:0:0/max_retries
I have also noticed that XFS bizarrely has its own layer of
recovery on top of that of the Linux IO subsystems and of the
device itself:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_file_systems/configuring-xfs-error-behavior_managing-file-systems
https://elixir.bootlin.com/linux/v5.13.5/source/fs/xfs/xfs_buf.c#L1264
next prev parent reply other threads:[~2021-07-26 7:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-24 18:41 SSD based sw RAID: is ERC/TLER really important? Gianluca Frustagli
2021-07-24 20:19 ` Peter Grandi
2021-07-24 21:45 ` Phil Turmel
2021-07-25 7:00 ` Wols Lists
2021-07-25 10:28 ` Peter Grandi
2021-07-26 1:06 ` Phil Turmel
2021-07-26 7:57 ` Peter Grandi [this message]
2021-07-26 16:12 ` Peter Grandi
2021-07-25 11:04 ` Peter Grandi
2021-07-24 20:21 ` Andy Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24830.27358.78544.178603@cyme.ty.sabi.co.uk \
--to=pg@raid.list.sabi.co.uk \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.