On 09/09/2012 02:34 PM, Will Sheldon wrote:
> Hello clever people :-)
> Once upon a time I had a 3 disk LVM (instructed to fill the disks
> sequentially). This LVM had a single LV formatted jfs and filled my life
> with sunshine and joy.
> Then I dropped a UPS on top of the server, one of the three PV's decided
> that this sort of treatment was not acceptable and proceeded to die
> (tick…tick….tick) and all the sunshine and joy left my life. :-(
> I tried a dd_rescue and recovered about 250gb onto a new disk from the
> area at the beginning (centre) of the disk.
> My next step was to try a fsck with the new disk, but I'm guessing that
> there is an important bit of the log missing because it seems to have hung:
> root@...:/# fsck.jfs -v -f /dev/VG_bob/pri
> fsck.jfs version 1.1.15, 04-Mar-2011
> processing started: 9/8/2012 14:33:37
> The current device is: /dev/VG_bob/pri
> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
> Primary superblock is valid.
> The type of file system for the device is JFS.
> Block size in bytes: 4096
> Filesystem size in blocks: 1464862720
> **Phase 0 - Replay Journal Log
> It's been doing that for some time (~20 hours):
> root@...:/# date
> Sun Sep 9 12:22:18 PDT 2012
> Is this normal? Is it broken? Will I ever see any of my data again? Is
> this the right place to ask?
This is not normal. I'm not aware of a specific bug or situation that
would explain this.
> Any pointers would be appreciated. I do have a backup however it's 6/7
> months old and about 3000 miles away. I've not been able to find SATA
> cables that long :-/
The safest thing to try initially is to attempt a read-only mount and
hope that your data is available and that you can make a fresh backup.
At least backup as much as you can.
You can then try to run fsck.jfs while skipping the journal replay with
the flag --omit_journal_replay. This could cause fsck to throw away any
files and directories that appear broken, so it might be risky.