Re: using dd (or dd_rescue) to salvage array

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Feb 06, 2012 at 10:37:38PM +0100, Stefan *St0fF* Huebner wrote:
> From the logical point of view those lost 8k would create bad data - 
> i.e. a filesystem problem OR simply corrupted data.  That depends on 
> which blocks exactly are bad.  If you were using lvm it could even be 
> worse, like broken metadata.

FWIW, xfs_repair has spit out over 100k lines on stderr, but when I
mounted before the repair (this is suggested if you need to replay the
log), everything seemed intact.  So I'm not yet sure what to make of
things; perhaps it'll be fine, or perhaps I need to start over.
(Alternatively, perhaps the next rsnapshot run will expose problems.)


On Mon, Feb 06, 2012 at 10:38:27PM -0500, Phil Turmel wrote:
> 
> But, I reviewed the OEM documentation for the 7K3000 family, and they
> clearly document support for the SCT ERC commands (para 9.18.1.2).

If I'm reading the docs right, then the 5K3000 also supports them (if
you're really cheap and can tolerate the slower speeds).  At this point,
if we're waiting till April for real ''enterprise'' drives, I can't see
anything too bad about getting one or two of these and testing them out
in my environment--the EARS drives are bad enough with my configuration
that it's hard to imagine being any worse.  (To be fair, I have to blame
the 3ware 9550 controller a bit too; I have EARS drives on other 3ware
controllers without all these issues.)

--keith



-- 
kkeller@xxxxxxxxxxxxxxxxxxxxxxxxxx

Attachment: pgpiUYpaupGJ8.pgp
Description: PGP signature


[ATA RAID]     [Linux SCSI Target Infrastructure]     [Managing RAID on Linux]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device-Mapper]     [Kernel]     [Linux Books]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Photos]     [Yosemite Photos]     [Yosemite News]     [AMD 64]     [Linux Networking]

Add to Google Powered by Linux