Skip to main content
20 events
when toggle format what by license comment
Sep 2, 2017 at 2:17 history edited Jeff Schaller
edited tags
S Aug 14, 2014 at 9:27 history bounty ended CommunityBot
S Aug 14, 2014 at 9:27 history notice removed CommunityBot
S Aug 6, 2014 at 7:56 history bounty started imz -- Ivan Zakharyaschev
S Aug 6, 2014 at 7:56 history notice added imz -- Ivan Zakharyaschev Reward existing answer
S Aug 6, 2014 at 7:40 history bounty ended imz -- Ivan Zakharyaschev
S Aug 6, 2014 at 7:40 history notice removed imz -- Ivan Zakharyaschev
Aug 5, 2014 at 11:13 answer added Ian Macintosh timeline score: 4
Aug 5, 2014 at 3:27 answer added Bratchley timeline score: 10
Jul 29, 2014 at 22:08 comment added imz -- Ivan Zakharyaschev @gol What if I want to catch it faster? Without waiting God knows how much time before the IO operation unblocks reporting an error? (Actually, I'm attempting to save the data from a disk with errors, but my problem is similar: running into these "erroneous" sectors causes huge delays. ... Perhaps I could also follow the advice, and invent a way to feed the info from SMART test to ddrescue so that it doesn't even touch the sectors reported by SMART.)
Jul 29, 2014 at 21:55 history tweeted twitter.com/#!/StackUnix/status/494239879002607616
Jul 29, 2014 at 20:09 comment added goldilocks @imz--IvanZakharyaschev unix.stackexchange.com/a/147304/25985 However, the kernel does log these errors, so if all you want to do is catch a failing disk before it becomes more trouble, you could scan the system logs at regular intervals.
Jul 29, 2014 at 19:41 history edited imz -- Ivan Zakharyaschev
Specify the OS in tags.
Jul 29, 2014 at 19:37 comment added imz -- Ivan Zakharyaschev The question hasn't received a direct answer, so we don't know whether it's a possible thing in linux: How can I reduce the IO wait time and retry times?
S Jul 29, 2014 at 19:37 history bounty started imz -- Ivan Zakharyaschev
S Jul 29, 2014 at 19:37 history notice added imz -- Ivan Zakharyaschev Draw attention
Jul 15, 2014 at 5:55 comment added Ryan Sorensen Thanks, I will research smartmonctl more. In my experience, if the bad sectors happened during the last shipment, the SMART status shows that the drive is still good, and it performs fine until some random part during the copy, and then slows down to a crawl, also affecting other drives until it is removed.
Jul 15, 2014 at 4:43 comment added Deer Hunter What's wrong with checking SMART data through udisks/smartmonctl? A classical XY problem here, methinks.
Jul 14, 2014 at 21:51 review First posts
Jul 14, 2014 at 21:54
Jul 14, 2014 at 21:44 history asked Ryan Sorensen CC BY-SA 3.0