On 25 August 2011 18:54, Chris Rees wrote:
> On 24 August 2011 16:14, wrote:
>>> When the specified or calculated rate exceeds 64KB/sec, the
>>> required sleep interval between 64KB chunks is less than one
>>> second. Since diskcheckd calculates the interval in whole seconds
>>> -- because it c
On 24 August 2011 16:14, wrote:
>> When the specified or calculated rate exceeds 64KB/sec, the
>> required sleep interval between 64KB chunks is less than one
>> second. Since diskcheckd calculates the interval in whole seconds
>> -- because it calls sleep() rather than usleep() or nanosleep()
>
> When the specified or calculated rate exceeds 64KB/sec, the
> required sleep interval between 64KB chunks is less than one
> second. Since diskcheckd calculates the interval in whole seconds
> -- because it calls sleep() rather than usleep() or nanosleep()
> -- an interval of less than one secon
On 2011-Aug-19 20:24:38 -0700, Jeremy Chadwick wrote:
>The reallocated LBA cannot be dealt with aside from re-creating the
>filesystem and telling it not to use the LBA. I see no flags in
>newfs(8) that indicate a way to specify LBAs to avoid. And we don't
>know what LBA it is so we can't refer
Jeremy Chadwick wrote:
> On Sun, Aug 21, 2011 at 02:00:33AM -0700, per...@pluto.rain.com
> wrote:
> > Jeremy Chadwick wrote:
> > > ... using dd to find the bad LBAs is the only choice he has.
> > or sysutils/diskcheckd ...
> That software has a major problem where it runs constantly, rather
> tha
Am 20.08.2011 19:34, schrieb Dan Langille:
> This is an older system. I suspect insufficient ventilation. I'll look at
> getting
> a new case fan, if not some HDD fans.
The answer is quite simple, get new drives.
They have gone for some 24000 hours, IOW, at least 3 years (assuming
24x7), and a
On Sun, Aug 21, 2011 at 02:00:33AM -0700, per...@pluto.rain.com wrote:
> Jeremy Chadwick wrote:
>
> > ... using dd to find the bad LBAs is the only choice he has.
>
> or sysutils/diskcheckd. It uses a 64KB blocksize, falling back to
> 512 -- to identify the bad LBA(s) -- after getting a failure
Jeremy Chadwick wrote:
> ... using dd to find the bad LBAs is the only choice he has.
or sysutils/diskcheckd. It uses a 64KB blocksize, falling back to
512 -- to identify the bad LBA(s) -- after getting a failure when
reading a large block, and IME it runs something like 10x faster
than dd with
A follow-up given that I just viewed the SMART attribute data at the
very bottom of this page as of this writing (Sat Aug 20 13:00:09 PDT
2011):
http://beta.freebsddiary.org/smart-fixing-bad-sector.php
And I see this:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WH
On Aug 20, 2011, at 3:57 PM, Jeremy Chadwick wrote:
>>> I still suggest you replace the drive, although given its age I doubt
>>> you'll be able to find a suitable replacement. I tend to keep disks
>>> like this around for testing/experimental purposes and not for actual
>>> use.
>>
>> I have se
Dan, sorry for the previous mail. Seems my schedule today has just
unexpected changed; I had social events to deal with but as I found out
a few minutes ago those events are cancelled, which means I have time
today to look at your mail.
On Sat, Aug 20, 2011 at 01:34:41PM -0400, Dan Langille wrote
On Sat, Aug 20, 2011 at 08:43:09PM +0200, Alex Samorukov wrote:
>
> >"The SMART tests you did didn't really amount to anything; no surprise.
> >short and long tests usually do not test the surface of the disk. There
> >are some drives which do it on a long test, but as I said before,
> >everythin
"The SMART tests you did didn't really amount to anything; no surprise.
short and long tests usually do not test the surface of the disk. There
are some drives which do it on a long test, but as I said before,
everything varies from drive to drive."
It is not correct statement, sorry. Long tes
On Aug 20, 2011, at 2:36 PM, Jeremy Chadwick wrote:
> Dan, I will respond to your reply sometime tomorrow. I do not have time
> to review the Email today (~7.7KBytes), but will have time tomorrow.
No worries. Thank you.
--
Dan Langille - http://langille.org
_
Dan, I will respond to your reply sometime tomorrow. I do not have time
to review the Email today (~7.7KBytes), but will have time tomorrow.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Sys
On Sat, Aug 20, 2011 at 07:54:30PM +0200, Alex Samorukov wrote:
> You can run long self-test in smartmontools (-t long). Then you can
> get failed sector number from the smartmontools (-l selftest) and
> then you can use DD to write zero to the specific sector.
This is inaccurate advice. I covere
On Aug 20, 2011, at 2:04 PM, Diane Bruce wrote:
> On Sat, Aug 20, 2011 at 01:34:41PM -0400, Dan Langille wrote:
>> On Aug 19, 2011, at 11:24 PM, Jeremy Chadwick wrote:
>>
>>> On Fri, Aug 19, 2011 at 09:39:17PM -0400, Dan Langille wrote:
> ...
Information such as this?
http://beta.fre
On Aug 20, 2011, at 1:54 PM, Alex Samorukov wrote:
>> [root@bast:~] # dd of=/dev/null if=/dev/ad2 bs=1m conv=noerror
>> dd: /dev/ad2: Input/output error
>> 2717+0 records in
>> 2717+0 records out
>> 2848980992 bytes transferred in 127.128503 secs (22410246 bytes/sec)
>> dd: /dev/ad2: Input/output
On Sat, Aug 20, 2011 at 01:34:41PM -0400, Dan Langille wrote:
> On Aug 19, 2011, at 11:24 PM, Jeremy Chadwick wrote:
>
> > On Fri, Aug 19, 2011 at 09:39:17PM -0400, Dan Langille wrote:
...
> >> Information such as this?
> >> http://beta.freebsddiary.org/smart-fixing-bad-sector.php
...
> > 3) A v
You can run long self-test in smartmontools (-t long). Then you can get
failed sector number from the smartmontools (-l selftest) and then you
can use DD to write zero to the specific sector. Also i am highly
recommending to setup smartd as daemon and to monitor number of
relocated sectors. If
On Aug 19, 2011, at 11:24 PM, Jeremy Chadwick wrote:
> On Fri, Aug 19, 2011 at 09:39:17PM -0400, Dan Langille wrote:
>>
>> On Aug 19, 2011, at 7:21 PM, Jeremy Chadwick wrote:
>>
>>> On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
System in question: FreeBSD 8.2-STABLE #3: Thu
On Aug 20, 2011, at 06:24 , Jeremy Chadwick wrote:
> You might also be wondering "that dd command writes 512 bytes of zero to
> that LBA; what about the old data that was there, in the case that the
> drive remaps the LBA?"
If you write zeros at OS level to an LBA, you will end up with zeros at
On Fri, 19 Aug 2011, Chuck Swiger wrote:
Reading the underlying failing drive with dd will help identify any
other questionable sectors. However, your drive temps are too high--
many vendors call out either 50C or 55C as the point where drive
reliability becomes significantly degraded.
The
On Fri, Aug 19, 2011 at 09:39:17PM -0400, Dan Langille wrote:
>
> On Aug 19, 2011, at 7:21 PM, Jeremy Chadwick wrote:
>
> > On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
> >> System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
> >>
> >> After a recent power fa
On Aug 19, 2011, at 7:21 PM, Jeremy Chadwick wrote:
> On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
>> System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
>>
>> After a recent power failure, I'm seeing this in my logs:
>>
>> Aug 19 20:36:34 bast smartd[1575]:
On Fri, Aug 19, 2011 at 05:51:02PM -0700, Kevin Oberman wrote:
> On Fri, Aug 19, 2011 at 4:57 PM, Diane Bruce wrote:
> > On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
> >> System in question: FreeBSD 8.2-STABLE #3: Thu Mar ?3 04:52:04 GMT 2011
> >>
> >> After a recent power failure
On Fri, Aug 19, 2011 at 4:57 PM, Diane Bruce wrote:
> On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
>> System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
>>
>> After a recent power failure, I'm seeing this in my logs:
>>
>> Aug 19 20:36:34 bast smartd[1575]: De
On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
> System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
>
> After a recent power failure, I'm seeing this in my logs:
>
> Aug 19 20:36:34 bast smartd[1575]: Device: /dev/ad2, 2 Currently unreadable
> (pending) sector
On Fri, Aug 19, 2011 at 04:50:01PM -0400, Dan Langille wrote:
> System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
>
> After a recent power failure, I'm seeing this in my logs:
>
> Aug 19 20:36:34 bast smartd[1575]: Device: /dev/ad2, 2 Currently unreadable
> (pending) sector
On Aug 19, 2011, at 1:50 PM, Dan Langille wrote:
> Searching on that error message, I was led to believe that identifying the
> bad sector and
> running dd to read it would cause the HDD to reallocate that bad block.
>
> http://smartmontools.sourceforge.net/badblockhowto.html
>
> However, since
System in question: FreeBSD 8.2-STABLE #3: Thu Mar 3 04:52:04 GMT 2011
After a recent power failure, I'm seeing this in my logs:
Aug 19 20:36:34 bast smartd[1575]: Device: /dev/ad2, 2 Currently unreadable
(pending) sectors
And gmirror reports:
# gmirror status
NameStatus Components
31 matches
Mail list logo
