I've used raw mapped LUN to a windows server guest on ESX in the past but from a different SAN (netapp via fibre) with no problems.<div><br></div><div>I wonder if some how the same LUN got mapped to two different drive letters or to two different systems. That's about the only way I can think that there would be corruption because of this. </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 12:34 PM, Jim Ockers <span dir="ltr"><<a href="mailto:ockers@ockers.net" target="_blank">ockers@ockers.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div bgcolor="#ffffff" text="#000000">
<font size="+1"><tt>Hi CLUEbies,<br>
<br>
We had a major filesystem corruption event and I was wondering if
anyone else had experienced something like this or if there is some
good/obvious reason why it happened.<br>
<br>
We have a Windows 2003 (NTFS5) data volume (not the OS volume) on an
iSCSI target on a Linux OpenFiler, with Windows running under VMWare
ESXi5. In order to give the Windows VM access to the iSCSI target
volume there are 3 ways to do it:<br>
</tt></font>
<ol>
<li><font size="+1"><tt>Boot the OS in the usual way for its VM, and
use the Microsoft iSCSI initiator to access the target. The OS via its
own initiator finds a NTFS5 filesystem and assigns it a drive letter as
usual.<br>
</tt></font></li>
<li><font size="+1"><tt>Configure VMWare to access the target using
its iSCSI initiator, and then configure the VM with the <u><b>raw
mapped LUN</b></u> as another disk drive. The OS finds a VMWare
virtual disk, and finds a NTFS5 filesystem on the disk. VMWare handles
the block device translation between a virtual disk and an iSCSI
target, and the OS has no knowledge that the actual block device is an
iSCSI target.<br>
</tt></font></li>
<li><font size="+1"><tt>Configure VMWare to access the target using
its iSCSI initiator, and mount the target as a VMWare datastore using
VMFS5 filesystem. In the datastore there would be a VMWare VMDK
virtual disk, and the VM has this VMDK as one of its disk drives. The
OS would then see a normal VMWare virtual disk and has no knowledge of
VMFS5 datastore or iSCSI.<br>
</tt></font></li>
</ol>
<font size="+1"><tt><br>
We first tried a raw mapped LUN, and things were fine for 2
or 3 days and then we started getting massive NTFS data corruption, but
no indication was given other than Windows event viewer ntfs errors.
Because the system didn't crash, it ran for over a day like this, and
the backups got corrupted too. CHKDSK made matters worse. We wound up
having to merge two backups together because there were inconsistencies
that required manual resolution. What a pain.<br>
<br>
We switched to using the Microsoft iSCSI initiator to access the
volume, and it's been fine for a few days now with no NTFS errors or
corruption or data loss that we know of.<br>
<br>
The VMDK on VMFS5 datastore on iSCSI is also problem-free as far as we
can tell.<br>
<br>
I was wondering if anyone on this list had any ideas or wild
speculation about why using the VMWare iSCSI initiator and giving the
iSCSI target to the OS as a raw mapped LUN would cause filesystem
corruption, whereas the other 2 options are both trouble-free? Is
there some good reason why the raw mapped LUN approach is not
recommended? Is it only bad for iSCSI or is it also bad for fiber
channel etc?<br>
<br>
Obviously we won't be doing this again but I wish I had some good
reasons for why it was so problematic.<br>
<br>
Thanks,<br>
Jim<span class="HOEnZb"><font color="#888888"><br>
</font></span></tt></font><span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Jim Ockers, P.E., P.Eng. (<a href="mailto:ockers@ockers.net" target="_blank">ockers@ockers.net</a>)
Contact info: <a href="http://www.ockers.net/" target="_blank">http://www.ockers.net/</a>
</pre>
</font></span></div>
<br>_______________________________________________<br>
clue mailing list: <a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
For information, account preferences, or to unsubscribe see:<br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br></blockquote></div><br></div>