Reiser4progs-1.0.4-1 issues with gcc-4.0.1

Reiser4progs-1.0.4-1 issues with gcc-4.0.1

[Stef van der Made]

Dear Sir / Madam,

I'm having an issue when compiling reiser4progs-1.0.4-1 using gcc-4.0.1. 
The compiler spits out the following error but I'm afraid that I'm not 
famaliar with C code or compilers.

I hope you can fix this issue.

 gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -D_REENTRANT 
-D_FILE_OFFSET_BITS=64 -DENABLE_SYMLINKS -DENABLE_SPECIAL 
-DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH 
-DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS 
-DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE 
-DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O3 -W -Wall -Wuninitialized 
-Wno-unused-parameter -Wredundant-decls -MT liboid40_static_la-oid40.lo 
-MD -MP -MF .deps/liboid40_static_la-oid40.Tpo -c oid40.c  -fPIC -DPIC 
-o .libs/liboid40_static_la-oid40.o
oid40.c:204: error: static declaration of 'oid40_plug' follows 
non-static declaration
oid40.h:33: error: previous declaration of 'oid40_plug' was here
make[4]: *** [liboid40_static_la-oid40.lo] Error 1


Best regards,

Stef

Re: Reiser4progs-1.0.4-1 issues with gcc-4.0.1

[Vladimir V. Saveliev]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

Hello

Stef van der Made wrote:
> 
> Dear Sir / Madam,
> 
> I'm having an issue when compiling reiser4progs-1.0.4-1 using gcc-4.0.1. 
> The compiler spits out the following error but I'm afraid that I'm not 
> famaliar with C code or compilers.
> 
> I hope you can fix this issue.
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -D_REENTRANT 
> -D_FILE_OFFSET_BITS=64 -DENABLE_SYMLINKS -DENABLE_SPECIAL 
> -DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH 
> -DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS 
> -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE 
> -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O3 -W -Wall -Wuninitialized 
> -Wno-unused-parameter -Wredundant-decls -MT liboid40_static_la-oid40.lo 
> -MD -MP -MF .deps/liboid40_static_la-oid40.Tpo -c oid40.c  -fPIC -DPIC 
> -o .libs/liboid40_static_la-oid40.o
> oid40.c:204: error: static declaration of 'oid40_plug' follows 
> non-static declaration
> oid40.h:33: error: previous declaration of 'oid40_plug' was here
> make[4]: *** [liboid40_static_la-oid40.lo] Error 1
> 
> 

pleas try the attached patch

> Best regards,
> 
> Stef
> 
> 


[-- Attachment #2: reiser4progs.patch --]
[-- Type: text/plain, Size: 4147 bytes --]

Id: 9cd3adfda4ed00816d05545fa28ddd45a636289a
tree a331c2ddc4cc0dbc376c4f1f055e0c82dd87a6ae
parent 4d6752ee8165ea27b03059c70f1ce16ecb9797cb
author namesys.com!vitaly <namesys.com!vitaly> 1119552435 +0000
committer namesys.com!vitaly <namesys.com!vitaly> 1119552435 +0000

(Logical change 1.4306)


======== diff against 4d6752ee8165ea27b03059c70f1ce16ecb9797cb ========
diff --git a/plugin/key/key_large/key_large.c b/plugin/key/key_large/key_large.c
--- a/plugin/key/key_large/key_large.c
+++ b/plugin/key/key_large/key_large.c
@@ -6,6 +6,8 @@
 #ifdef ENABLE_LARGE_KEYS
 #include "key_large.h"
 
+extern reiser4_plug_t key_large_plug;
+
 /* Returns minimal key */
 static reiser4_key_t *key_large_minimal(void) {
 	return key_common_minimal(&key_large_plug);
@@ -382,7 +384,7 @@ static reiser4_key_ops_t key_large_ops =
 	.get_name	= key_large_get_name
 };
 
-static reiser4_plug_t key_large_plug = {
+reiser4_plug_t key_large_plug = {
 	.cl    = class_init,
 	.id    = {KEY_LARGE_ID, 0, KEY_PLUG_TYPE},
 #ifndef ENABLE_MINIMAL
diff --git a/plugin/key/key_large/key_large.h b/plugin/key/key_large/key_large.h
--- a/plugin/key/key_large/key_large.h
+++ b/plugin/key/key_large/key_large.h
@@ -43,8 +43,6 @@ union key_large {
 
 typedef union key_large key_large_t;
 
-extern reiser4_plug_t key_large_plug;
-
 typedef enum {
 	/* Major locality occupies higher 60 bits of the first element */
 	KEY_LARGE_LOCALITY_MASK		= 0xfffffffffffffff0ull,
diff --git a/plugin/key/key_short/key_short.c b/plugin/key/key_short/key_short.c
--- a/plugin/key/key_short/key_short.c
+++ b/plugin/key/key_short/key_short.c
@@ -6,6 +6,8 @@
 #ifdef ENABLE_SHORT_KEYS
 #include "key_short.h"
 
+extern reiser4_plug_t key_short_plug;
+
 /* Returns minimal key */
 static reiser4_key_t *key_short_minimal(void) {
 	return key_common_minimal(&key_short_plug);
@@ -367,7 +369,7 @@ static reiser4_key_ops_t key_short_ops =
 	.get_name       = key_short_get_name
 };
 
-static reiser4_plug_t key_short_plug = {
+reiser4_plug_t key_short_plug = {
 	.cl    = class_init,
 	.id    = {KEY_SHORT_ID, 0, KEY_PLUG_TYPE},
 #ifndef ENABLE_MINIMAL
diff --git a/plugin/key/key_short/key_short.h b/plugin/key/key_short/key_short.h
--- a/plugin/key/key_short/key_short.h
+++ b/plugin/key/key_short/key_short.h
@@ -42,8 +42,6 @@ union key_short {
 
 typedef union key_short key_short_t;
 
-extern reiser4_plug_t key_short_plug;
-
 typedef enum {
 	/* Major locality occupies higher 60 bits of the first element */
 	KEY_SHORT_LOCALITY_MASK    = 0xfffffffffffffff0ull,
diff --git a/plugin/oid/oid40/oid40.c b/plugin/oid/oid40/oid40.c
--- a/plugin/oid/oid40/oid40.c
+++ b/plugin/oid/oid40/oid40.c
@@ -8,6 +8,8 @@
 #include "oid40.h"
 #include "oid40_repair.h"
 
+extern reiser4_plug_t oid40_plug;
+
 static uint32_t oid40_get_state(generic_entity_t *entity) {
 	aal_assert("umka-2088", entity != NULL);
 	return ((oid40_t *)entity)->state;
@@ -201,7 +203,7 @@ reiser4_oid_ops_t oid40_ops = {
 	.slink_locality = oid40_slink_locality
 };
 
-static reiser4_plug_t oid40_plug = {
+reiser4_plug_t oid40_plug = {
 	.cl    = class_init,
 	.id    = {OID_REISER40_ID, 0, OID_PLUG_TYPE},
 	.label = "oid40",
diff --git a/plugin/oid/oid40/oid40.h b/plugin/oid/oid40/oid40.h
--- a/plugin/oid/oid40/oid40.h
+++ b/plugin/oid/oid40/oid40.h
@@ -30,8 +30,6 @@ struct oid40 {
 
 typedef struct oid40 oid40_t;
 
-extern reiser4_plug_t oid40_plug;
-
 #define oid40_get_next(area)            LE64_TO_CPU(*((d64_t *)area))
 #define oid40_set_next(area, val)       (*((d64_t *)area) = CPU_TO_LE64(val))
 
======== end ========

Id: 65146bcee1fa04cf3976db38e2cf19c53ccfcac4
tree a331c2ddc4cc0dbc376c4f1f055e0c82dd87a6ae
parent 9cd3adfda4ed00816d05545fa28ddd45a636289a
author namesys.com!vitaly <namesys.com!vitaly> 1119552435 +0000
committer namesys.com!vitaly <namesys.com!vitaly> 1119552435 +0000

Merge vitaly@Thebsh:/home/bk/reiser4progs
into digger.namesys.com:/home/vitaly/stuff/work/bk/reiser4progs

2005/05/27 19:20:18+04:00 namesys.com!vitaly
variable declaration cleaups

BKrev: 42bb03b3fy7na4E3psnnaw48s2JAhA


======== diff against 9cd3adfda4ed00816d05545fa28ddd45a636289a ========
======== end ========

recovering from "rm -rf"

[David Masover]

I've got a Reiser4 partition which I just moved (mv) a bunch of stuff
off of, onto another drive.  The other drive died immediately after.

I'm trying to repair the other drive, and to find any backups, but is
there a reasonable chance to recover from the good drive?  Maybe force
fsck.reiser4 to rebuild stuff... somehow?  It's sort of the equivalent
of an "rm -rf".

Re: recovering from "rm -rf"

[michael chang]

On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> I've got a Reiser4 partition which I just moved (mv) a bunch of stuff
> off of, onto another drive.  The other drive died immediately after.
> 
> I'm trying to repair the other drive, and to find any backups, but is
> there a reasonable chance to recover from the good drive?  Maybe force
> fsck.reiser4 to rebuild stuff... somehow?  It's sort of the equivalent
> of an "rm -rf".

I have no idea what you're trying to say; can you identify your drives
by e.g. Drive A and Drive B?  However, I've heard that Spinrite
(grc.com) is known to be pretty good at drive recovery, and supposedly
compatable with Linux partitions.  Requires an i386 compatable
machine, and I believe you need Windows to write the diskette/iso
which you can boot the recovery system from.  Haven't tried it though.

What are you trying to do?  Format a broken hard drive so you can
write to it again, or recover data you deleted unintentionally?  A
"dead" hard drive usually may be usable, but using one is extremely
dangerous (read: you're best off throwing it away, because any data
stored on it would have to have a backup on another e.g. hard drive
anyways, so you shouldn't use it).  For all you know, the drive could
have died because the internals wore out/broke, or because your cable
died/broke/etc.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: recovering from "rm -rf"

[David Masover]

michael chang wrote:
> On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> 
>>I've got a Reiser4 partition which I just moved (mv) a bunch of stuff
>>off of, onto another drive.  The other drive died immediately after.
>>
>>I'm trying to repair the other drive, and to find any backups, but is
>>there a reasonable chance to recover from the good drive?  Maybe force
>>fsck.reiser4 to rebuild stuff... somehow?  It's sort of the equivalent
>>of an "rm -rf".
> 
> 
> I have no idea what you're trying to say; can you identify your drives
> by e.g. Drive A and Drive B?  However, I've heard that Spinrite
> (grc.com) is known to be pretty good at drive recovery, and supposedly
> compatable with Linux partitions.  Requires an i386 compatable
> machine, and I believe you need Windows to write the diskette/iso
> which you can boot the recovery system from.  Haven't tried it though.

I could do that, but this is Reiser4.  Does anyone but Namesys support
recovery from Reiser4 yet?

> What are you trying to do?  Format a broken hard drive so you can
> write to it again, or recover data you deleted unintentionally?  A

Sort of both.

Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
then had its power plug fall out (don't ask me how I managed that), I
plugged it back in (stupid!) -- there was a spark -- drive B now won't
spin up, and drive A is essentially "rm -rf"ed.

Drive C is an 80 gig drive with a good, working install of Linux on it.
 I can throw a fully working Gentoo Linux system, and any recovery tools
I can get for it, at Drive A.

If I can't recover the data from Drive A, I will send Drive B to some
recovery experts.  If I can recover the data from Drive A, I will throw
out Drive B and buy a replacement.

> anyways, so you shouldn't use it).  For all you know, the drive could
> have died because the internals wore out/broke, or because your cable
> died/broke/etc.

I'm guessing that the internals did break, so I think that a recovery
service would probably be able to recover 100% of my data (as an image),
but only after replacing some parts, or even pulling the whole thing
apart in a cleanroom.  This would cost at least $300-500, and if it goes
to the cleanroom, probably $700 and up.

By the way, do you know any good data recovery services?

Re: recovering from "rm -rf"

[michael chang]

On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> michael chang wrote:
> > On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> >
> >>I've got a Reiser4 partition which I just moved (mv) a bunch of stuff
> >>off of, onto another drive.  The other drive died immediately after.
> >>
> >>I'm trying to repair the other drive, and to find any backups, but is
> >>there a reasonable chance to recover from the good drive?  Maybe force
> >>fsck.reiser4 to rebuild stuff... somehow?  It's sort of the equivalent
> >>of an "rm -rf".
> >
> >
> > I have no idea what you're trying to say; can you identify your drives
> > by e.g. Drive A and Drive B?  However, I've heard that Spinrite
> > (grc.com) is known to be pretty good at drive recovery, and supposedly
> > compatable with Linux partitions.  Requires an i386 compatable
> > machine, and I believe you need Windows to write the diskette/iso
> > which you can boot the recovery system from.  Haven't tried it though.
> 
> I could do that, but this is Reiser4.  Does anyone but Namesys support
> recovery from Reiser4 yet?

No clue.  They'll be able to tell you, for $25, from what I've heard.

> > What are you trying to do?  Format a broken hard drive so you can
> > write to it again, or recover data you deleted unintentionally?  A
> 
> Sort of both.
> 
> Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
> mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
> then had its power plug fall out (don't ask me how I managed that), I
> plugged it back in (stupid!) -- there was a spark -- drive B now won't
> spin up, and drive A is essentially "rm -rf"ed.

Well, most filesystems [I don't know for sure about Reiser4] will not
immediately clear out unused data.  However, if Drive A has been
running for a while post "rm -rf" and has some sort of repacker
enabled (I think they haven't implemented it yet or it was removed in
recent versionf of Reiser4) then the data could be all gone. 
Otherwise, I suppose if you had a backup of the metadata [which you
probably don't], you could try recovering from that...

As a note for the Power Plug + Sparks -- in the future, if it falls
out, unplug BOTH ends of the cord, then plug in the end that is
connected to the device FIRST, then the power socket/source SECOND. 
This goes for _ALL_ electronic devices, and will save you a lot of
hassle.  Paranoid people will also unplug electronics during a
thunderstorm/rolling blackouts/brownouts, and get a UPS system.

> > anyways, so you shouldn't use it).  For all you know, the drive could
> > have died because the internals wore out/broke, or because your cable
> > died/broke/etc.
> 
> I'm guessing that the internals did break, so I think that a recovery
> service would probably be able to recover 100% of my data (as an image),
> but only after replacing some parts, or even pulling the whole thing
> apart in a cleanroom.  This would cost at least $300-500, and if it goes
> to the cleanroom, probably $700 and up.

Considering the situation, most likely you shocked (e.g. with static
electricity or from that AC)  the motor and head and whatnot, although
if you're lucky, the spindle containing your data will be untouched.
In that case, a data recovery center only has to take it apart, move
the spindle to an identical drive, and put it back in the machine
(hopefully, without shocking it a second time).  As for drive A, you
can ask if there is some hack to get an older version of the metadata.
 *shrugs*

> By the way, do you know any good data recovery services?

Not that I've used.  What area [e.g. country, metro area, etc.]

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: recovering from "rm -rf"

[David Masover]

michael chang wrote:
> On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> 
>>michael chang wrote:
>>
>>>On 8/5/05, David Masover <ninja@slaphack.com> wrote:
>>>
>>>
>>>>I've got a Reiser4 partition which I just moved (mv) a bunch of stuff
>>>>off of, onto another drive.  The other drive died immediately after.
>>>>
>>>>I'm trying to repair the other drive, and to find any backups, but is
>>>>there a reasonable chance to recover from the good drive?  Maybe force
>>>>fsck.reiser4 to rebuild stuff... somehow?  It's sort of the equivalent
>>>>of an "rm -rf".
>>>
>>>
>>>I have no idea what you're trying to say; can you identify your drives
>>>by e.g. Drive A and Drive B?  However, I've heard that Spinrite
>>>(grc.com) is known to be pretty good at drive recovery, and supposedly
>>>compatable with Linux partitions.  Requires an i386 compatable
>>>machine, and I believe you need Windows to write the diskette/iso
>>>which you can boot the recovery system from.  Haven't tried it though.
>>
>>I could do that, but this is Reiser4.  Does anyone but Namesys support
>>recovery from Reiser4 yet?
> 
> 
> No clue.  They'll be able to tell you, for $25, from what I've heard.

I meant more along the lines of sending in Drive B to somewhere.  The
standard procedure is to pull apart the drive and replace as much as
they need to to create an image, then start working on the image in a
fairly low-level fashion that's highly FS-dependant.

I'm figuring that if repair on Drive A fails, I'll have one of these
guys send me the raw image of Drive B, which I'll then try to repair
with fsck and such if I have to, and that's where Namesys would be a
possibility.  Of course, I still haven't given up on Drive A.

> Well, most filesystems [I don't know for sure about Reiser4] will not
> immediately clear out unused data.  However, if Drive A has been
> running for a while post "rm -rf" and has some sort of repacker
> enabled (I think they haven't implemented it yet or it was removed in
> recent versionf of Reiser4) then the data could be all gone. 
> Otherwise, I suppose if you had a backup of the metadata [which you
> probably don't], you could try recovering from that...

No, I don't.  And, Drive A wasn't running for nearly long enough, even
if the repacker was implemented -- I think it's supposed to run
something like once a week.

> As a note for the Power Plug + Sparks -- in the future, if it falls
> out, unplug BOTH ends of the cord, then plug in the end that is
> connected to the device FIRST, then the power socket/source SECOND. 
> This goes for _ALL_ electronic devices, and will save you a lot of
> hassle.  Paranoid people will also unplug electronics during a
> thunderstorm/rolling blackouts/brownouts, and get a UPS system.

No, what I should have done was pull the main power cable *immediately*,
then plugged everything back in with power off.  I'm talking about the
power cable that leads to the drive -- the four-pin molex connector --
not the big, usually black cable that leads to the box.

>>>anyways, so you shouldn't use it).  For all you know, the drive could
>>>have died because the internals wore out/broke, or because your cable
>>>died/broke/etc.
>>
>>I'm guessing that the internals did break, so I think that a recovery
>>service would probably be able to recover 100% of my data (as an image),
>>but only after replacing some parts, or even pulling the whole thing
>>apart in a cleanroom.  This would cost at least $300-500, and if it goes
>>to the cleanroom, probably $700 and up.
> 
> 
> Considering the situation, most likely you shocked (e.g. with static
> electricity or from that AC)  the motor and head and whatnot, although
> if you're lucky, the spindle containing your data will be untouched.
> In that case, a data recovery center only has to take it apart, move
> the spindle to an identical drive, and put it back in the machine
> (hopefully, without shocking it a second time).  As for drive A, you
> can ask if there is some hack to get an older version of the metadata.
>  *shrugs*

I'm counting on some combination of that and of a grep on the raw
device.  And so help me, I'm not writing a single byte more onto the
drive until I'm sure there's nothing left to recover.

>>By the way, do you know any good data recovery services?
> 
> 
> Not that I've used.  What area [e.g. country, metro area, etc.]

I was assuming I'd have to ship it.  I'm in a small town in Iowa.

Re: recovering from "rm -rf"

[PFC]

> Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
> mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
> then had its power plug fall out (don't ask me how I managed that), I
> plugged it back in (stupid!) -- there was a spark -- drive B now won't
> spin up, and drive A is essentially "rm -rf"ed.

	You probably fried the electronics... if the heads are still OK, you  
could recover your data by exchanging the PCB from a brand new drive, with  
the fried PCB of the old drive. You need some electronics skillz, but a  
friend of mine did this (it was an adventure, as he had to find the same  
drive as he had, from ebay, etc) and it worked for him... if something  
that's not on the PCB is dead, well, you need a recovery company.
	Or you could give $25 to Hans Reiser via his website for an answer ?

Re: recovering from "rm -rf"

[Aaron D. Ball]

PFC wrote:

>     You probably fried the electronics... if the heads are still OK, 
> you  could recover your data by exchanging the PCB from a brand new 
> drive, with  the fried PCB of the old drive. You need some electronics 
> skillz, but a  friend of mine did this (it was an adventure, as he had 
> to find the same  drive as he had, from ebay, etc) and it worked for 
> him... if something  that's not on the PCB is dead, well, you need a 
> recovery company. 

I have actually done this a couple of times with modern drives and found 
it shockingly easy.  You buy an identical drive, unscrew the board, and 
screw the other board in, and it just works.  The contacts are little 
springs that connect correctly as long as the board is screwed on properly.

Re: recovering from "rm -rf"

[PFC]

> I have actually done this a couple of times with modern drives and found  
> it shockingly easy.  You buy an identical drive, unscrew the board, and  
> screw the other board in, and it just works.  The contacts are little  
> springs that connect correctly as long as the board is screwed on  
> properly.

	No solder ? You got lucky ;)
	Pretty cool huh !
	So, to the OP : if you do this, equip yoursef with a multi-head  
screwdriver (like, mini torx and the like) ($5 at Home Depot), google for  
"electronics static electricity protection" (basically, wear cotton,  
ground yourself and the drive (or just be barefeet on a tile floor) and be  
extra careful).

Re: recovering from "rm -rf"

[David Masover]

Aaron D. Ball wrote:
> PFC wrote:
> 
>>     You probably fried the electronics... if the heads are still OK,
>> you  could recover your data by exchanging the PCB from a brand new
>> drive, with  the fried PCB of the old drive. You need some electronics
>> skillz, but a  friend of mine did this (it was an adventure, as he had
>> to find the same  drive as he had, from ebay, etc) and it worked for
>> him... if something  that's not on the PCB is dead, well, you need a
>> recovery company. 
> 
> 
> I have actually done this a couple of times with modern drives and found
> it shockingly easy.  You buy an identical drive, unscrew the board, and
> screw the other board in, and it just works.  The contacts are little
> springs that connect correctly as long as the board is screwed on properly.

Which ones?

My drive is a Western Digital, and they strongly advise against this
procedure, becaues different drives (even of the same model number) may
have different firmware versions, and this may make things worse.

Re: recovering from "rm -rf"

[Aaron D. Ball]

On 05 Aug 2005, at 19:03, David Masover wrote:

[swapping boards on disks]

> Which ones?

I believe it was whatever Maxtor IDE disks are inside their 5000DV 
enclosure, and probably also Western Digital 1200JBs, but I'm not 
entirely sure.  It's been a few months.

> My drive is a Western Digital, and they strongly advise against this
> procedure, becaues different drives (even of the same model number) may
> have different firmware versions, and this may make things worse.

Well, I'm not sure there's a "worse" in this case.  If you need or can 
afford to do the strictly right thing (pay several thousand dollars to 
a data recovery company), by all means do so.  But if you can't afford 
that, buying a new drive and swapping electronics may work and is 
certainly much cheaper.

Re: recovering from "rm -rf"

[Rudy Zijlstra]

Aaron D. Ball wrote:

> On 05 Aug 2005, at 19:03, David Masover wrote:
>
> [swapping boards on disks]
>
>> Which ones?
>
>
> I believe it was whatever Maxtor IDE disks are inside their 5000DV 
> enclosure, and probably also Western Digital 1200JBs, but I'm not 
> entirely sure.  It's been a few months.
>
>> My drive is a Western Digital, and they strongly advise against this
>> procedure, becaues different drives (even of the same model number) may
>> have different firmware versions, and this may make things worse.
>
>
> Well, I'm not sure there's a "worse" in this case.  If you need or can 
> afford to do the strictly right thing (pay several thousand dollars to 
> a data recovery company), by all means do so.  But if you can't afford 
> that, buying a new drive and swapping electronics may work and is 
> certainly much cheaper.
>
>
I've done it with Western Digital disks. They were same type and 
manufactured on consequetive days (1 day apart).

Rudy

Re: recovering from "rm -rf"

[David Masover]

PFC wrote:
> 
>> Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
>> mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
>> then had its power plug fall out (don't ask me how I managed that), I
>> plugged it back in (stupid!) -- there was a spark -- drive B now won't
>> spin up, and drive A is essentially "rm -rf"ed.
> 
> 
>     You probably fried the electronics... if the heads are still OK,
> you  could recover your data by exchanging the PCB from a brand new
> drive, with  the fried PCB of the old drive. You need some electronics
> skillz, but a  friend of mine did this (it was an adventure, as he had
> to find the same  drive as he had, from ebay, etc) and it worked for
> him... if something  that's not on the PCB is dead, well, you need a
> recovery company.

Seems kind of a waste to buy a whole new drive, if it does end up being
that simple.  I wonder if I couldn't ship this back to the manufacturer
and have them do it?  I'm sure they have extras...

Re: recovering from "rm -rf"

[Rudy Zijlstra]

David Masover wrote:

>PFC wrote:
>  
>
>>>Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
>>>mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
>>>then had its power plug fall out (don't ask me how I managed that), I
>>>plugged it back in (stupid!) -- there was a spark -- drive B now won't
>>>spin up, and drive A is essentially "rm -rf"ed.
>>>      
>>>
>>    You probably fried the electronics... if the heads are still OK,
>>you  could recover your data by exchanging the PCB from a brand new
>>drive, with  the fried PCB of the old drive. You need some electronics
>>skillz, but a  friend of mine did this (it was an adventure, as he had
>>to find the same  drive as he had, from ebay, etc) and it worked for
>>him... if something  that's not on the PCB is dead, well, you need a
>>recovery company.
>>    
>>
>
>Seems kind of a waste to buy a whole new drive, if it does end up being
>that simple.  I wonder if I couldn't ship this back to the manufacturer
>and have them do it?  I'm sure they have extras...
>
>  
>
forget that idea, the extra's are bough by the recovery companies...

In other words, its not cost effective for the manufacturers to keep 
spare parts around.

/Kick in open door
The thing you *should* have done is keep good backups, especially 
considering the amount you are willing to pay to recover...
No matter how you do it, no matter what type of RAID level you run, 
nothing beats a backup on a separate medium, with an automated script to 
make it every night (or more often if needed).
Kick in open door/

With respect to pricing, your cheapest option is likely to get a similar 
drive from Ebay. Lots cheaper than spare parts from the manufacturer 
(which i do not expect them to have). Even buying a similar drive new 
from a shop will be cheaper than spare parts.

What you can do is ask the manufacturer which drives are using the same 
PCBs. You might get lucky.

Cheers,

Rudy

Re: recovering from "rm -rf"

[David Masover]

Rudy Zijlstra wrote:
> David Masover wrote:
> 
>> PFC wrote:
>>  
>>
>>>> Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
>>>> mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
>>>> then had its power plug fall out (don't ask me how I managed that), I
>>>> plugged it back in (stupid!) -- there was a spark -- drive B now won't
>>>> spin up, and drive A is essentially "rm -rf"ed.
>>>>     
>>>
>>>    You probably fried the electronics... if the heads are still OK,
>>> you  could recover your data by exchanging the PCB from a brand new
>>> drive, with  the fried PCB of the old drive. You need some electronics
>>> skillz, but a  friend of mine did this (it was an adventure, as he had
>>> to find the same  drive as he had, from ebay, etc) and it worked for
>>> him... if something  that's not on the PCB is dead, well, you need a
>>> recovery company.
>>>   
>>
>>
>> Seems kind of a waste to buy a whole new drive, if it does end up being
>> that simple.  I wonder if I couldn't ship this back to the manufacturer
>> and have them do it?  I'm sure they have extras...
>>
>>  
>>
> forget that idea, the extra's are bough by the recovery companies...
> 
> In other words, its not cost effective for the manufacturers to keep
> spare parts around.
> 
> /Kick in open door
> The thing you *should* have done is keep good backups, especially
> considering the amount you are willing to pay to recover...

I'm not sure yet how much I'm willing to pay.  If the Namesys people can
help me out, there will certainly be a donation headed their way, but
I'm not sure yet if I want to spend $500 to $5000 on a recovery.  It's
an academic question, anyway -- if it costs too much, I'll have to wait.

> No matter how you do it, no matter what type of RAID level you run,

Striping is fast, but not really RAID.

> nothing beats a backup on a separate medium, with an automated script to
> make it every night (or more often if needed).
> Kick in open door/

Indeed, a lesson learned.  I've got some sort of backup script
somewhere, but I'm not sure exactly what it's backing up, or to where.
It may have the really important stuff, but almost certainly won't have
all the music and anime, so I'm still trying to recover Drive A.

> With respect to pricing, your cheapest option is likely to get a similar
> drive from Ebay. Lots cheaper than spare parts from the manufacturer
> (which i do not expect them to have). Even buying a similar drive new
> from a shop will be cheaper than spare parts.

Similar drive, if it'd work.  But my manufacturer warns me that even
identical-looking drives sometimes have different firmware.

> What you can do is ask the manufacturer which drives are using the same
> PCBs. You might get lucky.

(same PCBs and firmware.)  Thanks, I'll do that.

Re: recovering from "rm -rf"

[michael chang]

On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> Rudy Zijlstra wrote:
> > David Masover wrote:
> >
> >> PFC wrote:
> >>
> >>
> >>>> Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
> >>>> mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
> >>>> then had its power plug fall out (don't ask me how I managed that), I
> >>>> plugged it back in (stupid!) -- there was a spark -- drive B now won't
> >>>> spin up, and drive A is essentially "rm -rf"ed.
> >>>>
> >>>
> >>>    You probably fried the electronics... if the heads are still OK,
> >>> you  could recover your data by exchanging the PCB from a brand new
> >>> drive, with  the fried PCB of the old drive. You need some electronics
> >>> skillz, but a  friend of mine did this (it was an adventure, as he had
> >>> to find the same  drive as he had, from ebay, etc) and it worked for
> >>> him... if something  that's not on the PCB is dead, well, you need a
> >>> recovery company.
> >>>
> >>
> >>
> >> Seems kind of a waste to buy a whole new drive, if it does end up being
> >> that simple.  I wonder if I couldn't ship this back to the manufacturer
> >> and have them do it?  I'm sure they have extras...
> >>
> >>
> >>
> > forget that idea, the extra's are bough by the recovery companies...
> >
> > In other words, its not cost effective for the manufacturers to keep
> > spare parts around.
> >
> > /Kick in open door
> > The thing you *should* have done is keep good backups, especially
> > considering the amount you are willing to pay to recover...
> 
> I'm not sure yet how much I'm willing to pay.  If the Namesys people can
> help me out, there will certainly be a donation headed their way, but
> I'm not sure yet if I want to spend $500 to $5000 on a recovery.  It's
> an academic question, anyway -- if it costs too much, I'll have to wait.

Most people I've seen, when the drive dies, they just buy a new one,
and forget about their old data.

> > No matter how you do it, no matter what type of RAID level you run,
> 
> Striping is fast, but not really RAID.

So this was a performance raid, not a backup raid?  Did you RAID on
the same drive?  o_O  [If memory serves me right, RAID/Striping only
gives better performance on multiple drives.]

> > nothing beats a backup on a separate medium, with an automated script to
> > make it every night (or more often if needed).
> > Kick in open door/
> 
> Indeed, a lesson learned.  I've got some sort of backup script
> somewhere, but I'm not sure exactly what it's backing up, or to where.
> It may have the really important stuff, but almost certainly won't have
> all the music and anime, so I'm still trying to recover Drive A.

Music and Anime?  Lol.  No wonder you're trying to recover it all. 
I'd suggest a data recovery company, all the same, before you damage
your computer completely.  And maybe consider using e.g. a backup -
two drives; while you have to store data twice, at least if one fails,
you'll have a backup [how in the world did you end up with two drives
dead anyways?!?].

> Similar drive, if it'd work.  But my manufacturer warns me that even
> identical-looking drives sometimes have different firmware.

In the manual, or over the phone?

> > What you can do is ask the manufacturer which drives are using the same
> > PCBs. You might get lucky.
> 
> (same PCBs and firmware.)  Thanks, I'll do that.

You'll be hard pressed to find a e-bay listing that lists the PCBs and
Firmware, per the components, though?  *shrugs*

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: recovering from "rm -rf"

[David Masover]

michael chang wrote:
> On 8/5/05, David Masover <ninja@slaphack.com> wrote:
> 
>>Rudy Zijlstra wrote:
>>
>>>David Masover wrote:
>>>
>>>
>>>>PFC wrote:
>>>>
>>>>
>>>>
>>>>>>Drive A is a 500 gig striped RAID.  Drive B is a 200 gig IDE drive.  I
>>>>>>mv'ed all my data (about 100 gigs) from drive A to drive B.  Drive B
>>>>>>then had its power plug fall out (don't ask me how I managed that), I
>>>>>>plugged it back in (stupid!) -- there was a spark -- drive B now won't
>>>>>>spin up, and drive A is essentially "rm -rf"ed.
>>>>>>
>>>>>
>>>>>   You probably fried the electronics... if the heads are still OK,
>>>>>you  could recover your data by exchanging the PCB from a brand new
>>>>>drive, with  the fried PCB of the old drive. You need some electronics
>>>>>skillz, but a  friend of mine did this (it was an adventure, as he had
>>>>>to find the same  drive as he had, from ebay, etc) and it worked for
>>>>>him... if something  that's not on the PCB is dead, well, you need a
>>>>>recovery company.
>>>>>
>>>>
>>>>
>>>>Seems kind of a waste to buy a whole new drive, if it does end up being
>>>>that simple.  I wonder if I couldn't ship this back to the manufacturer
>>>>and have them do it?  I'm sure they have extras...
>>>>
>>>>
>>>>
>>>
>>>forget that idea, the extra's are bough by the recovery companies...
>>>
>>>In other words, its not cost effective for the manufacturers to keep
>>>spare parts around.
>>>
>>>/Kick in open door
>>>The thing you *should* have done is keep good backups, especially
>>>considering the amount you are willing to pay to recover...
>>
>>I'm not sure yet how much I'm willing to pay.  If the Namesys people can
>>help me out, there will certainly be a donation headed their way, but
>>I'm not sure yet if I want to spend $500 to $5000 on a recovery.  It's
>>an academic question, anyway -- if it costs too much, I'll have to wait.
> 
> 
> Most people I've seen, when the drive dies, they just buy a new one,
> and forget about their old data.

Depends what that data is, and what it would take to reconstruct.  I
know what you mean, but this isn't a few word documents and records and
things, it's the closest thing to a life's work that I can have at my age.

> So this was a performance raid, not a backup raid?  Did you RAID on
> the same drive?  o_O  [If memory serves me right, RAID/Striping only
> gives better performance on multiple drives.]

Indeed it does, and "Drive" A is an array of two identical drives, both
of which still work, if I can get the data off of them.

>>>nothing beats a backup on a separate medium, with an automated script to
>>>make it every night (or more often if needed).
>>>Kick in open door/
>>
>>Indeed, a lesson learned.  I've got some sort of backup script
>>somewhere, but I'm not sure exactly what it's backing up, or to where.
>>It may have the really important stuff, but almost certainly won't have
>>all the music and anime, so I'm still trying to recover Drive A.
> 
> 
> Music and Anime?  Lol.  No wonder you're trying to recover it all. 
> I'd suggest a data recovery company, all the same, before you damage
> your computer completely.  And maybe consider using e.g. a backup -
> two drives; while you have to store data twice, at least if one fails,
> you'll have a backup [how in the world did you end up with two drives
> dead anyways?!?].

They aren't.  It's a *third* drive that's dead.

I needed to rebuild the two-disk array, to make room for Windows (a
dual-boot), because there's a *fourth* drive that I'd been using for
that.  I could have just resized the filesystem, but it was Reiser4.
So, I moved all the files from the RAID to the third drive, then the
third drive promptly died.  So I have a choice between trying to rescue
the dead drive and trying to rebuild a filesystem that's essentially
been "rm -rf"ed.

>>Similar drive, if it'd work.  But my manufacturer warns me that even
>>identical-looking drives sometimes have different firmware.
> 
> 
> In the manual, or over the phone?

In the FAQ on their website.  I sent them a more specific question,
still waiting for a reply.

>>>What you can do is ask the manufacturer which drives are using the same
>>>PCBs. You might get lucky.
>>
>>(same PCBs and firmware.)  Thanks, I'll do that.
> 
> 
> You'll be hard pressed to find a e-bay listing that lists the PCBs and
> Firmware, per the components, though?  *shrugs*

Yeah, I'm asking the manufacturer if they can help out with that.  I
don't mind buying a new drive.  New drive: $100 or less.  Data recovery
service:  $350 or more, probably $1k-7k.  But then, if it ends up just
being music and anime -- if I can recover the more important stuff from
a backup that I may or may not have -- maybe it'll be cheaper to just
buy more bandwidth for a few weeks.

Re: recovering from "rm -rf"

[michael chang]

> that.  I could have just resized the filesystem, but it was Reiser4.

*sigh* And that is why there are two features in Reiser4 that I am
still waiting for before I upgrade: resizing partitions (preferably
both shrink and grow) and the repacker (online or otherwise).  [And
maybe something that will tell me which kernels have the online
repacker and which ones don't, (e.g. if I only get the repacker by
applying a namesys patch).]  Otherwise I'd be using Reiser4 right now.

Re: recovering from "rm -rf"

[Hans Reiser]

David Masover wrote:

>
>
>I'm not sure yet how much I'm willing to pay.  If the Namesys people can
>help me out, there will certainly be a donation headed their way,
>
Nah, for you it is no charge, you have done a lot for us.  Did you try
what Vitaly advised yet?

Re: recovering from "rm -rf"

[David Masover]

Hans Reiser wrote:
> David Masover wrote:
> 
> 
>>
>>I'm not sure yet how much I'm willing to pay.  If the Namesys people can
>>help me out, there will certainly be a donation headed their way,
>>
> 
> Nah, for you it is no charge, you have done a lot for us.

What exactly have I done?  I haven't contributed a single line of code,
just ranted on the mailing list for you.

I appreciate it, but I think I will pay you anyway.  $25 for a question
very well answered, and my mother says she'll match it -- which is still
nowhere near what I'd have had to pay to get the other hard drive
repaired.  Does that WorldPay link work?

> Did you try
> what Vitaly advised yet?

Yes, it seems to have worked.  I seem to have all my important files,
except one album of music and the last few episodes of anime -- and I'm
still going through lost+found.  That's really not much of a loss.

By the way, I also discovered a nice trick to avoid making a full disk
backup.  I had a 500 gig RAID array that I was trying to rescue, and the
biggest spare disk I had available was 80 gigs.  So, I used dm_snapshot
to create a writable snapshot, using a loopback file on the 80 gig drive
as the COW device.  I did the fsck on the snapshot, then wrote the
snapshot back to the original device (dd if=snapshot of=orig_device)
once I was sure it worked.  If it hadn't worked, I could have simply
removed the snapshot (dmsetup remove snapshot).

The COW file was a 60 gig sparse file that ended up using only 2 gigs or
so on disk after the fsck.

Be warned, though, that dm_snapshot isn't quite like LVM snapshots, and
only LVM snapshots are documented, while only dm_snapshot will work for
this.  I had to read the source.

Re: recovering from "rm -rf"

[michael chang]

On 8/6/05, David Masover <ninja@slaphack.com> wrote:
> > Did you try
> > what Vitaly advised yet?
> 
> Yes, it seems to have worked.  I seem to have all my important files,
> except one album of music and the last few episodes of anime -- and I'm
> still going through lost+found.  That's really not much of a loss.
> 
> By the way, I also discovered a nice trick to avoid making a full disk
> backup.  I had a 500 gig RAID array that I was trying to rescue, and the
> biggest spare disk I had available was 80 gigs.  So, I used dm_snapshot
> to create a writable snapshot, using a loopback file on the 80 gig drive
> as the COW device.  I did the fsck on the snapshot, then wrote the
> snapshot back to the original device (dd if=snapshot of=orig_device)
> once I was sure it worked.  If it hadn't worked, I could have simply
> removed the snapshot (dmsetup remove snapshot).
> 
> The COW file was a 60 gig sparse file that ended up using only 2 gigs or
> so on disk after the fsck.
> 
> Be warned, though, that dm_snapshot isn't quite like LVM snapshots, and
> only LVM snapshots are documented, while only dm_snapshot will work for
> this.  I had to read the source.

Congratulations.  Hopefully, you'll have another way to make room for
Windows though [assuming you haven't already] -- if it's not too much
of a pain, I've found some people resort to having disk images (e.g. a
FAT32 image on a Linux Filesystem) and using either VMWare or QEMU...
*sigh*  But you'll need a fast machine to get even a semi decent
speed, and the file can be huge (e.g. couple of gigs) and if it gets
fragmented, then performance is a pain (fragemented files on a
fragmented disk image.. uggh, I don't want to think about it).

I guess something to keep in mind on the online resizer -- ability to
handle larger images than free space (if possible) or at least large
files.  This, I suppose, could be boasted as a reason to convert e.g.
VMWare users to use Resier4 as an underlying filesystem in the future.
 If you make a Windows driver also, [with a decent defragmenter,
online or otherwise, that handles large disk images] then people who
use VMWare surely wouldn't mind paying a couple of bucks to ensure
maximum "performance" from their disks.  Just something to consider.
;)  [Note: I don't personally use VMWare, but this is my opinion of
their users, considering how expensive VMWare licences are in and of
themselves - a Resier4 driver would probably pale in comparison, and
be considered a bargain.  Hopefully.]

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: recovering from "rm -rf"

[Hans Reiser]

David Masover wrote:

>Hans Reiser wrote:
>  
>
>>David Masover wrote:
>>
>>
>>    
>>
>>>I'm not sure yet how much I'm willing to pay.  If the Namesys people can
>>>help me out, there will certainly be a donation headed their way,
>>>
>>>      
>>>
>>Nah, for you it is no charge, you have done a lot for us.
>>    
>>
>
>What exactly have I done?  I haven't contributed a single line of code,
>just ranted on the mailing list for you.
>  
>
That's worth more than you might think....

>I appreciate it, but I think I will pay you anyway.  $25 for a question
>very well answered, and my mother says she'll match it -- which is still
>nowhere near what I'd have had to pay to get the other hard drive
>repaired.  Does that WorldPay link work?
>  
>
Sure.  Thanks.

>  
>
>>Did you try
>>what Vitaly advised yet?
>>    
>>
>
>Yes, it seems to have worked.  I seem to have all my important files,
>except one album of music and the last few episodes of anime -- and I'm
>still going through lost+found.  That's really not much of a loss.
>
>By the way, I also discovered a nice trick to avoid making a full disk
>backup.  I had a 500 gig RAID array that I was trying to rescue, and the
>biggest spare disk I had available was 80 gigs.  So, I used dm_snapshot
>to create a writable snapshot, using a loopback file on the 80 gig drive
>as the COW device.  I did the fsck on the snapshot, then wrote the
>snapshot back to the original device (dd if=snapshot of=orig_device)
>once I was sure it worked.  If it hadn't worked, I could have simply
>removed the snapshot (dmsetup remove snapshot).
>
>The COW file was a 60 gig sparse file that ended up using only 2 gigs or
>so on disk after the fsck.
>
>Be warned, though, that dm_snapshot isn't quite like LVM snapshots, and
>only LVM snapshots are documented, while only dm_snapshot will work for
>this.  I had to read the source.
>
>
>
>  
>