On 09/12/13 13:38, David C. Rankin wrote:
On 12/08/2013 06:52 PM, Adam Goryachev wrote:
Have you tried this:
mdadm --verbose --assemble /dev/md1 /dev/sdb5
mdadm --manage /dev/md1 --run
Being raid1, you should be able to use only a single device....
BTW, chances to recover your data should be exceptional, as long as you don't do
anything too silly. You should even be able to mount the device directly
(read-only):
mount -o ro /dev/sdb5 /mnt
(Depending on the content is a filesystem).
Then you can just backup the data, create a new array, and restore the data.
Depending on data and size this might even be a better option...
nemtemp:/mnt # mount -o ro /dev/sdb5 /mnt/sdb/
mount: unknown filesystem type 'linux_raid_member'
nemtemp:/mnt # mount -t ext3 -o ro /dev/sdb5 /mnt/sdb/
Now since I can mount it, how in the heck do I get the raid put back together.
Seems really simple, but I'm stuck... Try with a newer mdadm?
Probably the best option is to follow Neil's advise to use mdadm from
git....
The alternative as I mentioned is to backup the data, re-create the raid
+ filesystem, and then restore the data.
BTW, the bitmap location looks.... strange...
I thought so too, but checking the other arrays, /dev/md2 has a negative
number as well:
nemtemp:/mnt # mdadm -E /dev/sda7
/dev/sda7:
<snip>
Internal Bitmap : -213 sectors from superblock
Update Time : Mon Dec 9 02:14:18 2013
It looks strange when I first saw it, but now that I think about it, it
is probably right (correct) since 1.0 metadata is at the very end of the
drive, so the bitmap is probably before the metadata, hence negative offset.
--
Adam Goryachev Website Managers www.websitemanagers.com.au
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
