Lamar,
Thanks for the info.
Paras.
On Tue, Sep 27, 2011 at 10:44 AM, Lamar Owen <lowen@xxxxxxxx> wrote:
> On Monday, September 26, 2011 11:18:06 AM Paras pradhan wrote:
>> On Mon, Sep 26, 2011 at 5:53 AM, Lamar Owen <lowen@xxxxxxxx> 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@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
