[Last Call] Learn how to a build a cloud-first strategyRegister Now


Recovering directory listing from degraded JBOD array

Posted on 2004-11-23
Medium Priority
Last Modified: 2013-12-15
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.

Question by:v2000
  • 3
  • 2
LVL 40

Expert Comment

ID: 12661456
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.

Author Comment

ID: 12692771
*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?  


Any help is appreciated.

Author Comment

ID: 12692780
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!

Author Comment

ID: 12692782
Although I guess fragmentation would render what I just described completely useless.  ARGH.  Maybe I ought to give up and reformat.
LVL 40

Accepted Solution

jlevie earned 1000 total points
ID: 12693239
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.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Over the last ten+ years I have seen Linux configuration tools come and go. In the early days there was the tried-and-true, all-powerful linuxconf that many thought would remain the one and only Linux configuration tool until the end of times. Well,…
I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
Suggested Courses
Course of the Month17 days, 14 hours left to enroll

829 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question