From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Hoeppner Subject: Re: Grub-install, superblock corrupted/erased and other animals Date: Fri, 05 Aug 2011 05:32:25 -0500 Message-ID: <4E3BC6B9.8050803@hardwarefreak.com> References: <20110802163907.29fc40b4@notabene.brown> <20110803150108.58f5c70b@notabene.brown> <20110803192054.6097d2c0@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-raid-owner@vger.kernel.org To: Aaron Scheiner Cc: NeilBrown , linux-raid@vger.kernel.org List-Id: linux-raid.ids On 8/5/2011 5:04 AM, Aaron Scheiner wrote: > I followed your advice and ran a scalpel instance for every drive in > the array. The scanning process finished this morning yay (and > obviously went a lot faster). Glad I could help. ... > So now the next step would have been to re-create the array and check Unless Neil has some hex editor (or other similar) trick up his sleeve that would allow you to manually recreate the sectors you hosed installing grub.. > if a file system check finds something... but because of the offsets > that probably won't work ? If you are able to use the Force to assemble the disks in the correct order, getting the raid device back up and running, then run 'xfs_repair -n /dev/md0' to do the check. The '-n' means "no modify". xfs_repair is better than xfs_check in many aspects. They are two separate code paths that serve the same function, but they behave a little differently under the hood. > Thanks again :) Wish I could have helped you recover the array. When a patient comes through emergency with 3 GSWs to the forehead and no pulse, there's nothing that can be done. :( -- Stan