Recovering directory listing from degraded JBOD array

I have low expectations of partially recovering from an unfortunate disk crash.  Let me describe my situation, but please be advised that I am not labouring under the misconception that I can recover any actual files -- I am looking for whatever I can get, which might be nothing.

I have an old Linux machine who functions as a mail and file server.  Its mail server duties happen on the root disk, an ancient 9GB U2W SCSI Cheetah drive.  Its file server duties happen on a "RAID" array which is constructed from a hodge-podge of disks -- all of which are SCSI except 1 40GB Western Digital IDE drive.  As you can guess, it's not really RAID at all, but "linear" mode in the kernel's RAID definition, otherwise known as JBOD or Just a Bunch Of Disks.  The array consisted of four devices, three SCSI drives and an IDE drive, all of which had one partition spanning the length of the entire disk.

The IDE disk crashed horribly.  I've never seen a WD drive crash this hard; the BIOS recognizes it as a drive with the incorrect geometry, size, and DMA/PIO mode.  Western Digital's data lifeguard tools give up with error 1320 or 1032 or 1230 or something that I looked up to identify that the disk is definitely bad and could be returned for an RMA.  I'm not interested in getting the 40GB back, the data was much more important.

I just checked on the ordering of the devices, and am disheartened to report that the IDE disk was first in the list of drives describing the array (/dev/hda1,/dev/sdb1,/dev/sdc1,/dev/sdd1), so I doubt I can recover anything at all.

The one ray of hope I have is my complete ignorance about reiserfs, which is the file system I chose for the array.  Where does it store its file allocation information?  Is there a backup?  I know if this were a FAT device I would be in trouble because the FAT itself is stored on the beginning of the disk.  But I thought perhaps reiser, like e2fs, was a bit more intelligent and stored backup superblocks in various regions on the device.

If this was heaven, I would get some files back off the device.  If I am lucky, I just want a listing of files ON the drive, so I can begin to reconstruct them.  However, I fully expect that there's nothing I can do and can recover absolutely no information on or about this array.

So please enlighten me, if there are any REISER gurus out there, as to my options, if any.

Thanks
-Paul
LVL 1
v2000Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jlevieCommented:
From what little experience I've had with Reiser FS I don't believe that it has the concept of alternate superblocks. And what I've read of it's internals tends to support that.

I'm sorry to say that all of the data on that volume is most likely lost.
0
v2000Author Commented:
*sobs quietly*

What concerns me most are the MP3 files.  What do people think of the following idea:

Read each remaining device in the array as one long bitsream, searching for the standard (if there is a standard!) BOF and EOF bits for MP3 files, and writing each file to a generated filename on another device.

Would this work?  I could get more fancy and read the ID3 information in the bits and write a more intelligent filename, but this will only work if there is really a standard BOF/EOF bit sequence for MP3 files.  Is there?  

*sigh*

Any help is appreciated.
0
v2000Author Commented:
I have written an ID3 parser for MP3 files in C#.NET (don't shoot me, I have to write in .NET at work -- Microsoft pays the bills, but I am a Linux geek at heart, with Perl, PHP, and Python forming the trifecta of my Linux enjoyment), but what I know about ID3v1 and v2 does not include BOF/EOF standards for MP3 files.

I am going to figure out some way to partially recover from this disk crash!
0
v2000Author Commented:
Although I guess fragmentation would render what I just described completely useless.  ARGH.  Maybe I ought to give up and reformat.
0
jlevieCommented:
Your idea might work, at least for some of the data. There's a good chance that quite a bit of the data will have been recorded in contiguous blocks. So scanning the remaining disks, looking for the beginning of an MP3, and storing that as a file until you readsomething that doesn't look like an MP3 should recover some of the data.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.