On 10/9/20 2:04 pm, Simon Walter wrote:
On 2020-09-09 15:53, Brad Campbell via Dng wrote:
It really doesn't. It'll mark a sector as "pending" (as in, I can't read
from it so I'll mark it for later).
What does the OS get at this point? Is that a short read error?
Yep. I have some old drives
On 2020-09-09 15:53, Brad Campbell via Dng wrote:
> On 5/9/20 10:38 pm, Simon Walter wrote:
>> On 9/5/20 12:50 PM, Gregory Nowak wrote:
>>> On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
Reallocation, to my knowledge, should happen in the background. It's
*possible* that
On 5/9/20 10:38 pm, Simon Walter wrote:
On 9/5/20 12:50 PM, Gregory Nowak wrote:
On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
Reallocation, to my knowledge, should happen in the background. It's
*possible* that the reallocation event and the FS corruption are unrelated.
My
On Wed, Sep 09, 2020 at 04:53:49PM +1000, Brad Campbell via Dng wrote:
>
> A drive will absolutely not re-allocate a sector until it is written to.
> Then it will first try and re-write the sector in case the error is due to
> something like a power loss or other transient. Failing a good
On 30/8/20 8:19 pm, Hendrik Boom wrote:
There's also the badblocks program, which can be set up either to do a
nondestructive read-only test for bad blocks, or a more throrough
destructive test, where it writes every block and later checks tht it
can read it correctly again, using a variety of
On 5/9/20 10:38 pm, Simon Walter wrote:
On 9/5/20 12:50 PM, Gregory Nowak wrote:
On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
Reallocation, to my knowledge, should happen in the background. It's
*possible* that the reallocation event and the FS corruption are unrelated.
My
On Sun, Sep 06, 2020 at 06:08:51PM -0400, Mason Loring Bliss wrote:
> On Sat, Sep 05, 2020 at 01:41:46PM -0400, Hendrik Boom wrote:
>
> > Nowadays the hardware replaces individual bad blocks without bothering
> > the file system.
>
> Where it can, yeah. That said, I've seen some of the
On 2020-09-05 01:34, goli...@devuan.org wrote:
I'll try to get the content on the drive archived over the weekend and
ready for long-term storage.
A bit of a followup . . . first I deleted all the files in lost+found
and the drive didn't explode. Then deleted some files in the remaining
On Sat, Sep 05, 2020 at 01:41:46PM -0400, Hendrik Boom wrote:
> Nowadays the hardware replaces individual bad blocks without bothering
> the file system.
Where it can, yeah. That said, I've seen some of the corruption that we're
supposed to never see - the bitflips in files that people use to
On 2020-09-05 13:41, Hendrik Boom wrote:
> This seems to say we now have two independent levels of bad block
> checking.
>
> When the low-level one fails, the other takes over. I't expect the
> file system to be unlikely to see bad blocks until the drive is hosed.
That is true if the drive is
On Sat, Sep 05, 2020 at 09:07:10PM +0900, Simon Walter wrote:
> On 9/5/20 3:34 PM, goli...@devuan.org wrote:
> ...
> > Yes we do! I checked a log I had saved from before I did the e2fsck and
> > those values are identical to the post-e2fsck log.
>
> If they are identical, then it would seem that
On Saturday 05 September 2020 at 19:28:24, Hendrik Boom wrote:
> On Fri, Sep 04, 2020 at 08:50:32PM -0700, Gregory Nowak wrote:
>
> > If you delete lost+found by accident, you can recreate it with
> > mklost+found(8).
>
> So lost+found isn't identified by its file name but by something else
>
On Fri, Sep 04, 2020 at 08:50:32PM -0700, Gregory Nowak wrote:
> On Fri, Sep 04, 2020 at 11:25:21PM -0400, Hendrik Boom wrote:
> > Delete the contents all you want, but keep the lost and found directory.
>
> If you delete lost+found by accident, you can recreate it with
> mklost+found(8).
So
On 9/5/20 12:50 PM, Gregory Nowak wrote:
On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
Reallocation, to my knowledge, should happen in the background. It's
*possible* that the reallocation event and the FS corruption are unrelated.
My understanding is that the drive won't
On 9/5/20 3:21 PM, goli...@devuan.org wrote:
My board doesn't have an eSATA port. Neither does the new dock but at
least it is USB 3.0. Current enclosures are 2.0 . . .
...
If you are a data hoarder and like disks, I'd suggest getting your
hands on some hardware that has a SATA
On 9/5/20 3:34 PM, goli...@devuan.org wrote:
...
Yes we do! I checked a log I had saved from before I did the e2fsck and
those values are identical to the post-e2fsck log.
If they are identical, then it would seem that the fsck did not trigger
the reallocation. However, what caused the
On Fri, 04 Sep 2020 20:22:56 -0500
goli...@devuan.org wrote:
> On 2020-09-04 19:24, spiralofhope wrote:
> > On Fri, 04 Sep 2020 15:03:55 -0500
> > goli...@devuan.org wrote:
> >
> >> ...2 new 500 GB WD Black drives...
>
> Not sure if they still have the 5 yr. warranty though . . .
They do,
On 2020-09-04 22:33, Gregory Nowak wrote:
On Fri, Sep 04, 2020 at 09:19:42PM -0500, goli...@devuan.org wrote:
=== START OF READ SMART DATA SECTION ===
SMART Status command failed: scsi error medium or hardware error
(serious)
SMART overall-health self-assessment test result: PASSED
Warning:
On 2020-09-04 22:26, Simon Walter wrote:
On 9/5/20 11:19 AM, goli...@devuan.org wrote:
On 2020-09-04 20:46, Simon Walter wrote:
On 9/5/20 1:34 AM, Andreas Messer wrote:
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
On 2020-09-01 00:07, goli...@devuan.org
On 2020-09-04 22:25, Hendrik Boom wrote:
On Fri, Sep 04, 2020 at 02:47:38PM -0500, goli...@devuan.org wrote:
A few posts after yours Hendrik suggested checking the lost and found
directory and in it I found 57 folders and 15798 other items totaling
16.6
GB. They are mostly edits from audacity
On Fri, Sep 04, 2020 at 11:25:21PM -0400, Hendrik Boom wrote:
> Delete the contents all you want, but keep the lost and found directory.
If you delete lost+found by accident, you can recreate it with
mklost+found(8).
On Sat, Sep 05, 2020 at 12:26:21PM +0900, Simon Walter wrote:
> Reallocation,
On Fri, Sep 04, 2020 at 09:19:42PM -0500, goli...@devuan.org wrote:
> === START OF READ SMART DATA SECTION ===
> SMART Status command failed: scsi error medium or hardware error (serious)
> SMART overall-health self-assessment test result: PASSED
> Warning: This result is based on an Attribute
On Fri, Sep 04, 2020 at 02:00:13PM -0700, Gregory Nowak wrote:
> On Fri, Sep 04, 2020 at 03:03:55PM -0500, goli...@devuan.org wrote:
> > This particular drive has no data that is not backed up elsewhere so I am
> > comfortable experimenting with it a bit as a learning experience. OTOH,
> >
On Fri, Sep 04, 2020 at 02:47:38PM -0500, goli...@devuan.org wrote:
>
> A few posts after yours Hendrik suggested checking the lost and found
> directory and in it I found 57 folders and 15798 other items totaling 16.6
> GB. They are mostly edits from audacity (.au) and avidemux (in C). Also some
On 9/5/20 11:19 AM, goli...@devuan.org wrote:
On 2020-09-04 20:46, Simon Walter wrote:
On 9/5/20 1:34 AM, Andreas Messer wrote:
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
On 2020-09-01 00:07, goli...@devuan.org wrote:
[...]
I have no idea how reliable the
On 2020-09-04 20:46, Simon Walter wrote:
On 9/5/20 1:34 AM, Andreas Messer wrote:
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
On 2020-09-01 00:07, goli...@devuan.org wrote:
[...]
I have no idea how reliable the repaired drive is after this radical
surgery.
On 9/5/20 1:34 AM, Andreas Messer wrote:
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
On 2020-09-01 00:07, goli...@devuan.org wrote:
[...]
I have no idea how reliable the repaired drive is after this radical
surgery. Can it be written to or files deleted?
On 2020-09-04 19:24, spiralofhope wrote:
On Fri, 04 Sep 2020 15:03:55 -0500
goli...@devuan.org wrote:
...2 new 500 GB WD Black drives...
You have good taste.
LOL! It's a learning process if you're paying attention. Note that the
funky drive I'm currently playing with is a 1 TB WD Caviar
On Fri, 04 Sep 2020 15:03:55 -0500
goli...@devuan.org wrote:
> ...2 new 500 GB WD Black drives...
You have good taste.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
On Fri, Sep 04, 2020 at 03:03:55PM -0500, goli...@devuan.org wrote:
> This particular drive has no data that is not backed up elsewhere so I am
> comfortable experimenting with it a bit as a learning experience. OTOH,
> trashing the remaining life it has for no reason wouldn't make sense.
You're
On 2020-09-04 11:34, Andreas Messer wrote:
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
On 2020-09-01 00:07, goli...@devuan.org wrote:
[...]
I have no idea how reliable the repaired drive is after this radical
surgery. Can it be written to or files deleted?
On 2020-09-04 05:38, Simon Walter wrote:
On 9/4/20 3:50 PM, goli...@devuan.org wrote:
Well . . . I decided to run an fsck on the misbehaving harddrive. It
started off by identifying the errors and rewriting them and then went
through Free block counts, Inode bitmap differences and Free inodes
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
> On 2020-09-01 00:07, goli...@devuan.org wrote:
> > Thanks to everyone who has responded to this thread (some off-list). I
> > just wanted to drop a short note updating you that the dock arrived
> > earlier today but I haven't
On Fri, 4 Sep 2020 18:34:29 +0200
Andreas Messer wrote:
> Hi golinux,
>
> On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
> > On 2020-09-01 00:07, goli...@devuan.org wrote:
> > [...]
> > I have no idea how reliable the repaired drive is after this radical
> > surgery. Can it
Hi golinux,
On Fri, Sep 04, 2020 at 01:50:07AM -0500, goli...@devuan.org wrote:
> On 2020-09-01 00:07, goli...@devuan.org wrote:
> [...]
> I have no idea how reliable the repaired drive is after this radical
> surgery. Can it be written to or files deleted? Should I even try?
> [...]
I wouldn't
Il 04/09/20 08:50, goli...@devuan.org ha scritto:
> On 2020-09-01 00:07, goli...@devuan.org wrote:
>> Thanks to everyone who has responded to this thread (some off-list). I
>> just wanted to drop a short note updating you that the dock arrived
>> earlier today but I haven't yet had a chance to
On 9/4/20 3:50 PM, goli...@devuan.org wrote:
Well . . . I decided to run an fsck on the misbehaving harddrive. It
started off by identifying the errors and rewriting them and then went
through Free block counts, Inode bitmap differences and Free inodes and
directory count. Some snippets of the
On 2020-09-01 00:07, goli...@devuan.org wrote:
Thanks to everyone who has responded to this thread (some off-list). I
just wanted to drop a short note updating you that the dock arrived
earlier today but I haven't yet had a chance to open the box. I am not
an impulsive person. I tend to measure
Thanks to everyone who has responded to this thread (some off-list). I
just wanted to drop a short note updating you that the dock arrived
earlier today but I haven't yet had a chance to open the box. I am not
an impulsive person. I tend to measure 6 times and cut once! So it's
going to take
On Sat, Aug 29, 2020 at 06:45:15PM -0700, Gregory Nowak wrote:
> On Sat, Aug 29, 2020 at 04:35:01PM -0500, goli...@devuan.org wrote:
> > What are the chances of fsck repairing the bad sectors? I shamefully admit I
> > have not thought about fsck for years.
>
> This looks to be at the media level,
Il 30/08/20 06:33, Gregory Nowak ha scritto:
> On Sat, Aug 29, 2020 at 10:36:26PM -0500, goli...@devuan.org wrote:
>> On 2020-08-29 22:15, Gregory Nowak wrote:
>>> On Sat, Aug 29, 2020 at 09:15:13PM -0500, goli...@devuan.org wrote:
dd if=/dev/zero bs=1M of=/dev/sdx
>>>
>>> That will just
On Sat, Aug 29, 2020 at 10:36:26PM -0500, goli...@devuan.org wrote:
> On 2020-08-29 22:15, Gregory Nowak wrote:
> >On Sat, Aug 29, 2020 at 09:15:13PM -0500, goli...@devuan.org wrote:
> >>dd if=/dev/zero bs=1M of=/dev/sdx
> >
> >That will just erase the first megabyte of the drive, leaving
>
On 2020-08-29 22:15, Gregory Nowak wrote:
On Sat, Aug 29, 2020 at 09:15:13PM -0500, goli...@devuan.org wrote:
dd if=/dev/zero bs=1M of=/dev/sdx
That will just erase the first megabyte of the drive, leaving
utilities like cfdisk to think the drive is new and unformatted. It
won't attempt to
On Sat, Aug 29, 2020 at 09:15:13PM -0500, goli...@devuan.org wrote:
> dd if=/dev/zero bs=1M of=/dev/sda
That will just erase the first megabyte of the drive, leaving
utilities like cfdisk to think the drive is new and unformatted. It
won't attempt to over write the bad sector(s) though. See the
I was wondering if a reformat might be possible but if it requires the
nuclear option so be it. LOL! I've only had to dd a handful of times so
searched and found this command to zero a drive. Will that get the job
done? Any idea how long that might take on a 1 TB drive? There is
On Sat, Aug 29, 2020 at 04:35:01PM -0500, goli...@devuan.org wrote:
> What are the chances of fsck repairing the bad sectors? I shamefully admit I
> have not thought about fsck for years.
This looks to be at the media level, so is most likely beyond
fsck. Since you said you can afford to lose
If you just want to reuse the physical drive, without the data, there is a
way to do that. Write zeros the entire length of the block device. If there
are enough spare sectors left on the disk, the bad ones will be relocated
as you write them. The various disk tools will then tell you what the
On 2020-08-29 18:13, terryc wrote:
On Sat, 29 Aug 2020 16:35:01 -0500
goli...@devuan.org wrote:
PS. There is no critical data on this disk because I always keep
multiple backups. But it would be nice to have that drive functioning
in some capacity.
The only other suggestion is 'the put it
On Sat, 29 Aug 2020 16:35:01 -0500
goli...@devuan.org wrote:
> PS. There is no critical data on this disk because I always keep
> multiple backups. But it would be nice to have that drive functioning
> in some capacity.
The only other suggestion is 'the put it in the freezer trick' which
may
On 2020-08-29 17:15, Bruce Perens via Dng wrote:
Copy the block partition (not the mounted files) to a same size or
larger
blank block partition using ddrescue or gddrescue. Try to mount that
read
only and copy the files off. If it doesn't work, try to restore the
superblock using one of the
On 2020-08-29 16:52, Dimitris via Dng wrote:
On 8/30/20 12:35 AM, goli...@devuan.org wrote:
advice is most welcome.
Thanks, Dimitris . . .
maybe a "long shot" , but did you try another cable/adapter/case for
that disk?
Yes. Tested different usb and adapter. Have ordered a dock which
Copy the block partition (not the mounted files) to a same size or larger
blank block partition using ddrescue or gddrescue. Try to mount that read
only and copy the files off. If it doesn't work, try to restore the
superblock using one of the tutorials online.
On Sat, Aug 29, 2020, 2:52 PM
On 8/30/20 12:35 AM, goli...@devuan.org wrote:
> advice is most welcome.
maybe a "long shot" , but did you try another cable/adapter/case for
that disk?
a few badblocks (?) would slow down the whole disk and maybe not open
some folder(s)...
"input/output error" and smart "read failure" could be
53 matches
Mail list logo
