A JM schrieb:
> Yes, "/dev/hdc/video" was a typo on my behalf it should read "/dev/hdc".
ok.
> Here a link to my latest
> post(http://oss.sgi.com/archives/linux-xfs/2005-08/msg00139.html).
yes, i commented on that :-)
> I've got to figure this data is recoverable since the drive is still
> functional? I guess that could bequestionable.
*if* the data is functional, then you can get your data. dd'ing is fine,
but it'll stop on read errors which are likely to happen if the drive is
damaged. dd_rescue will continue its work and has some nice other features
too (see http://www.garloff.de/kurt/linux/ddrescue/ again)
> So, if I'm runing out of space on the new drive what would happen if I
> save it to a file? (% dd_rescue /dev/VGforMyth/video
> /tmp/VGforMyth.img) Will it be reduced in size? Would I then run
> xfs_repair on it?
/tmp/VGforMyth.img will be the size of /dev/VGforMyth/video. it may be
smaller if some sectors could not be read. say dd_rescue can't read 100
sectors from /dev/VGforMyth/video, then /tmp/VGforMyth.img will be 100
sectors smaller.
> Would that also possible fix the superblock error: "Found candidate
> secondary superblock error reading superblock 22 -- seek to offset
> 209002168320 failed unable to verify superblock continuing"
fixing XFS filesystems is a job for xfs_repair. dd_rescue has nothing to
do with it. please try to finish step one (dd_rescue), then continue with
xfs_repair.
> This drive was part of a volume group "VGforMyth/video" and was the
> second drive in the group. I believe itwas formatted using ext3 if I
> recall correctly.
erm, if it is ext3....then you should be using e2fsprogs and eventually
posting on ext3-users@xxxxxxxxxx right?
Christian.
--
BOFH excuse #48:
bad ether in the cables
|