How to recover linux JFS Partition

[dmbgo]

I have a failed raid5 array from an adaptec 2410sa sata raid controller. It was very important because it contained my mythtv data :)
These controllers are notorious for reporting drives as failed, when still ok.

I am currently scanning the drives with ZAR and it is finding data etc, but I suspect it will not recognise the partition type.

Is it possible just to recover the entire partition to a new single drive, then mount it under linux when the array has been rebuilt?

[Alexey V. Gubin]

ZAR does not know JFS at all.
Also, we never tested it with a failed JFS RAID.

If it rebuilds the RAID successfully, it will then prompt you to select a partition on this reconstructed array. Alternatively, it may prompt you to "do you want to define the volume manually now", in this case click "No".

This or that way, you arrive at a (possibly empty) list of volumes (partitions).
At this point, click "BACK" button and ZAR would return to the list of a physical devices. Right click "Virtual RAID 0" device and select "Create an image file". This would write a sector-by-sector copy of the array to the file.

[dmbgo]

thanks for the reply, I believe the raid is undamaged, if it can bit copy the partition, that should be enough to be able to remount on a linux pc.
it is still rebuilding at present, there is 1.2 tb of data there.
merry xmas
Dave

[dmbgo]

Hi again,
after several tries I finally ended up with the results below. initially I tried to rebuild the array with varying combinations of 3 of the original 4 drives, but Zar was unable to determine the array parameters. The reason for this approach was that one of the disks was offline for a day before a power failure put the entire array offline. I wanted to try to regenerate parity from the 3 disks that were online at the time of the power failure.
An image of the array based on your previous instructions is currently in progress.
I was wondering if you would mind me asking some questions about these results please?

1/ How much confidence would you have in the results, do you think that Zar has correctly determined the array parameters?
2/ I notice that it has detected the array as MS/LDM is this likely to be correct when the array came from an Adaptec 2410sa SATA raid?
3/ does the stripe size of 512 mean sectors or kb?
4/ Is the parity index conflict between 0102 and 0103, due to one of these two disks being the one that was offline for a day?
Thanks again for your help so far.
David

000009E0: 02:55:48.828: Parity index conflict between 0102 and 0103
000009E0: 02:55:48.828: Parity index conflict between 0103 and 0102
000009E0: 02:55:48.828: RAID: Test RAID5/Checkerboard
000009E0: 02:55:48.828: Vote Starting disk: 258; Count=3 ; separation 66.7%
000009E0: 02:55:48.828: Unable to detect next disk in sequence - no related references
000009E0: 02:55:48.828: RAID: Test RAID5/LDM
000009E0: 02:55:48.828: Vote LDM start disk: 258; Count=4 ; separation 75.0%
000009E0: 02:55:48.828: LDM disk 0: 0102
000009E0: 02:55:48.828: LDM disk 1: 0103
000009E0: 02:55:48.828: LDM disk 2: 0100
000009E0: 02:55:48.828: LDM disk 3: 0104
000009E0: 02:55:48.844: Vote Parity rot RAID5 (MS/LDM): 0; Count=1 ; separation 100.0%
000009E0: 02:55:48.844: Rotation parameters for array type RAID5 (MS/LDM) start 0 rotation 3
000009E0: 02:55:48.844: ALERT!: LDM rotation parameters mismatch
000009E0: 02:55:48.844: Final nonzero RAID layout scores
000009E0: 02:55:48.844: RAID5 (MS/LDM):88.89
00000884: 02:55:48.844: Virtual RAID settings changed for Virtual RAID #0
00000884: 02:55:48.844: -------------------------------------
00000884: 02:55:48.844: Volume information for ID 00000000
00000884: 02:55:48.844: Origin : Reconstructed RAID
00000884: 02:55:48.844: Partition type : Unknown
00000884: 02:55:48.844: Capacity : 1117 GB
00000884: 02:55:48.844: Number of sectors : 2344268304
00000884: 02:55:48.844: RAID type : RAID5 (MS/LDM)
00000884: 02:55:48.844: Stripe size : 512
00000884: 02:55:48.844: Rotation parameters: 0 / 0
00000884: 02:55:48.844: Member 00 : 781422768 sectors at LBA 0 on device 0102
00000884: 02:55:48.844: Member 01 : 781422768 sectors at LBA 0 on device 0103
00000884: 02:55:48.844: Member 02 : 781422768 sectors at LBA 0 on device 0100
00000884: 02:55:48.844: Member 03 : 781422768 sectors at LBA 0 on device 0104

[Alexey V. Gubin]

1. Given the above data, I have little confidence in the results.
2. Do not really know for this particular model.
3. 512 is sectors.
4. Parity index conflict is due to insufficient data recognized to base decisions upon. From what I see, pattern recognition pretty much failed.

[dmbgo]

Thanks Alexy, looks like I'll have to give up using this method. Appreciate your help
Dave

[Alexey V. Gubin]

Unfortunately, RAID reconstruction in ZAR is interconnected with a filesystem recognition. So, with an FS type not known to ZAR, the results are mostly low-quality guesswork.