From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Snapshots slowing system
Date: Fri, 18 Mar 2016 23:58:47 +0000 (UTC) [thread overview]
Message-ID: <pan$9214$e77e0ea$9e58bc49$a0b72fea@cox.net> (raw)
In-Reply-To: 56EBE8B5.4090705@gmail.com
Austin S. Hemmelgarn posted on Fri, 18 Mar 2016 07:38:29 -0400 as
excerpted:
>>> 188 Command_Timeout 0x0032 100 099 000 Old_age
>>> Always
>>> - 8590065669
>>
>> Again, a non-zero raw value indicating command timeouts, probably due
>> to those bad seeks. It'll have to retry those commands, and that'll
>> definitely mean slowdowns.
>>
>> Tho there's no threshold, but 99 worst-value cooked isn't horrible.
>>
>> FWIW, on my spinning rust device this value actually shows a worst of
>> 001, here (100 current cooked value, tho), with a threshold of zero,
>> however. But as I've experienced no problems with it I'd guess that's
>> an aberration. I haven't the foggiest why/how/when it got that 001
>> worst.
> Such an occurrence is actually not unusual when you have particularly
> bad sectors on a 'desktop' rated HDD, as they will keep retrying for an
> insanely long time to read the bad sector before giving up.
Which is why it's mystifying to me how it could be reporting a worst-
value 1, when the device seems to be working just fine, and I don't
recall even one event of waiting "an insanely long time", or even
anything out of the ordinary, for anything on that device, ever.
Tho I suppose it's within reason that whatever it was froze up the system
bad enough that I rebooted, and I attributed the one-off to something
else. But with no other attributes indicating issues, I remain clueless
as to what might have happened and why that 1-worst, particularly so
given the 0 threshold for that attribute and that it's an old-age
indicator rather than a fail indicator, but the device is neither that
old, nor as I said, in any other way indicating anything close to what
that 1-worst value for just that single attribute implies.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-03-18 23:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 23:03 Snapshots slowing system pete
2016-03-15 15:52 ` Duncan
2016-03-15 22:29 ` Peter Chant
2016-03-16 11:39 ` Austin S. Hemmelgarn
2016-03-17 21:08 ` Pete
2016-03-18 9:17 ` Duncan
2016-03-18 11:38 ` Austin S. Hemmelgarn
2016-03-18 17:58 ` Pete
2016-03-18 23:58 ` Duncan [this message]
2016-03-18 18:16 ` Pete
2016-03-18 18:54 ` Austin S. Hemmelgarn
2016-03-19 0:59 ` Duncan
2016-03-19 1:15 ` Duncan
-- strict thread matches above, loose matches on Subject: below --
2016-03-12 13:01 pete
2016-03-13 3:28 ` Duncan
2016-03-11 20:03 Pete
2016-03-11 23:38 ` boris
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='pan$9214$e77e0ea$9e58bc49$a0b72fea@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).