Lamar, Thanks for the info.
Paras. On Tue, Sep 27, 2011 at 10:44 AM, Lamar Owen <lo...@pari.edu> wrote: > On Monday, September 26, 2011 11:18:06 AM Paras pradhan wrote: >> On Mon, Sep 26, 2011 at 5:53 AM, Lamar Owen <lo...@pari.edu> wrote: >> > May I ask what sort of SAN? >> Its a Hitachi OpenV fibre channel SAN (4Gbps HBA). My storage admin >> checked if this LUN can be accessible by others and he found no other >> hosts have access to it. > > Ok. > >> > I've seen some odd LUN reshuffling before, > ... >> reshuffling here means automatically changing disk's geometry as I am >> having an issue? It would be interesting to know if this can happen. > > No, reshuffling as in a host gained access to LUNs in a 'phantom' manner that > it should not have had access to. No longer a problem, and hasn't been for a > great while. It was an odd interaction, but I forget the details. > > If another host were put onto the FC with the exact same WWN onto the fabric > it might be possible to see this sort of thing, too, but the WWN's are all > supposed to be unique. > >> Here are some new additional info : > ... >> So my question is: if the LUN has been re partitioned for ex: say to >> install windows , why am i seeing our data in these newly created >> partitions? Is it possible to see data in a reapportioned drive? > > Yes, it is. If the recovery tool can look at the raw device it can grab > stuff that isn't in any partition, and you can look at that data. Standard > forensics. Repartitioning erases nothing except the partition table. > > Now, in the specific case of GPT, it is further possible to have a GPT and an > MBR at the same time, and while the 'shadow' MBR is supposed to match the > GPT's partitioning it doesn't have to. > > If you read through the LVM2 documentation and source code you may be able to > find the signature used to mark a partition as being LVM; once you do that > you should be able to find the start of the partition, and re-write the > partition table(s). I use the plural there since with GPT you can have the > GPT and the MBR coexisting; ideally you'd want to wipe the GPT out, but in > reality you may not want to. > > But, being that you really don't want to write anything to this volume, you > really should set up an offset, read-only, loop device; that is, find the > starting sector of the partition (preferably an image of the LUN, and not the > actual LUN; can the Hitachi array do LUN replication (EMC's SANcopy or > Snapview or MirrorView being the rough equivalents)?). Then, once you find > the starting position of the LVM physical volume: > > START_OFFSET_BYTE='actual starting sector number * sector size, zero origin' > DEVLUN='LUN device, probably /dev/sde in your case' > losetup -o $START_OFFSET_BYTE --read-only /dev/loop0 $DEVLUN > > Then see if you can get LVM to see this physical volume (by default loop > devices are included in the scan, but you may want to verify they're not > filtered in /etc/lvm/lvm.conf): > pvscan > vgscan > lvscan > > You may be able to mount (-o ro of course) the LV at that point (I'm going > through the LVM business because you mentioned VG names in your post). > > Hope that helps. > _______________________________________________ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
