home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / aix / 9130 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  5.1 KB
  1. Path: sparky!uunet!gatech!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
  2. From: Barry_Wolman@transarc.com
  3. Newsgroups: comp.unix.aix
  4. Subject: HELP! How to Restore Lost Logical Vol
  5. Message-ID: <web30vD0Bwx3I0mEQy@transarc.com>
  6. Date: 27 Aug 92 01:30:35 GMT
  7. Organization: Carnegie Mellon, Pittsburgh, PA
  8. Lines: 102
  9.  
  10. Sorry for the length of the posting.  Don't bother reading on if
  11. you're not an AIX Logical Volume Manager (LVM) expert.
  12.  
  13. Several weeks ago the 320H I used for performance testing was
  14. upgraded from five to eight external Maxtor 203 disks.  The
  15. original five disks had been organized into two volume groups vg01
  16. and vg02.  I reorganized the volume groups so vg01 had six disks
  17. and vg02 had two disks hdisk5 and hdisk9.  Some of the disks that
  18. used to be in vg02 were moved into vg01.
  19.  
  20. In vg02 I created two 48MB raw partitions (one per disk) and a
  21. 300MB mounted file system /perf striped across the two drives.
  22. lv01, the logical volume for /perf, consisted of 38 LPs on hdisk5
  23. and 36 LPs on hdisk9.  There was a loglv01 on hdisk9.  I used the
  24. system without problems until today.
  25.  
  26. I used the past tense in the preceding paragraph, because when I
  27. logged in today, I discovered that the system had been rebooted
  28. for a reason unrelated to the problems reported here.  I found
  29. that /perf wasn't mounted.  When I checked, I found that vg02 and
  30. all the logical volumes in it had disappeared!  When I called our
  31. operations group I was told that they hadn't been able to varyon
  32. the logical volumes in vg02 after the reboot and that they had
  33. tried "various things" without success.
  34.  
  35. About 90+% of /perf consisted of files duplicated elsewhere or
  36. files that can be regenerated by recompiling sources stored on a
  37. regularly backed up partition.  There were a small number of files
  38. that I'd miss, e.g. some recent raw profiles and traces, so I was
  39. willing to invest a few hours in trying to regenerate /perf.
  40.  
  41. Fortunately, when I did reorganized the volume groups, I wrote a
  42. script that ran various combinations of lslv, lvpv, and lsvg to
  43. generate a detailed summary of the status and location of every
  44. logical volume.  I had a hard copy of the output of this script
  45. from just after the reorganization.
  46.  
  47. I decided to see if I could recreate the logical volumes exactly
  48. where they were before the crash.  My hope was that I could mount
  49. lv01 as /perf and be back on the air.
  50.  
  51. I recreated vg02 and then realized it might be a good idea to make
  52. a physical copy of the two disks.  I used
  53.     dd if=/dev/hdisk5 of=/dev/rmt0 bs=4096k to make a copy of
  54. hdisk5 on a 8mm tape and used a similar dd to make a copy of
  55. hdisk9.
  56.  
  57. Using the detailed info of where the logical volumes had been, I
  58. used smit to recreate new instances of the logical volumes and
  59. verified that they occupied the same ranges of PPs that they used
  60. to occupy and had the same attributes.  I then tried to mount
  61. /perf by
  62.     mount -o rw,log=/dev/loglv01 /dev/lv01 /perf
  63. Of course this didn't work (if it had, I wouldn't have made this
  64. posting :-().
  65.  
  66. I then tried the smit command that adds a new journaled file
  67. system using an existing logical volume (lv01).  It got the right
  68. size for the file system (608xxx blocks), but after I mounted
  69. /perf I discovered it was empty.
  70.  
  71. I then tried to refill lv01 and loglv01 with what was on the disk
  72. before I started fiddling with smit.  After unmounting /perf I
  73. used dd with appropriate skip= and seek= commands to copy the
  74. right number of PPs from the two tapes into the LPs in lv01 and
  75. loglv01. After I did this, mount complained about a file system
  76. call receiving an invalid parameter.  I'm pretty sure I used the
  77. right set of parameters when I "refilled" lv01 and loglv01, but
  78. it's possible I made a mistake.  I'll double check when I get back
  79. to work tomorrow.
  80.  
  81. After refilling the logical volumes failed, I used dd to restore
  82. the two physical disks from the tapes I had written.  This didn't
  83. result in a usable file system either.  I think smit showed the
  84. file system size as 0.
  85.  
  86. I'm a bit surprised that none of the above worked (I suppose it's
  87. possible that operations did something to clobber the disk when
  88. they were trying to "fix" the problem).  If I had been booting the
  89. system, I would have taken the two physical dumps as soon as the
  90. first varyon attempt failed and I realized that vg02 was gone.
  91.  
  92. Is there anything I can do?  Should I resign myself to the loss of
  93. the files that weren't backed up?
  94.  
  95. A more troubling question is why did vg02 disappear?  I did all
  96. the file operations from smit and my detailed display of LVM
  97. values showed no signs of error.  Could there be a LVM bug here?
  98. In case it is relevant, I have a record of what was in vg01 and
  99. vg02 before the reorganization, but not at the same level of
  100. detail as for after the reorganization.
  101.  
  102. Unfortunately, I have a partial, but not a complete log of the
  103. smit operations I did during the reorganization.  We use AFS, so
  104. when I "su rootl", I lose access to my home directory in AFS where
  105. smit.log is stored.  If I remember to "klog barry", the smit ops
  106. get logged, if I don't klog, they aren't.  The reorganization was
  107. done in stages, and I sometimes didn't klog.
  108.  
  109. Thanks in advance for any advice,
  110.  
  111. Barry
  112.