Difference between revisions of "Iscsi notes"

From Noah.org
Jump to navigationJump to search
m (Mount ntfs moved to Iscsi notes)
m
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category: Engineering]]
 
[[Category: Engineering]]
 +
[[Category:Drives_and_Filesystems]]
  
When mounting an NTFS partition for an iSCSI shared partition I found that the trick to make it
+
= See also =
work is to use the errors=recover option.
+
 
 +
iSCSI seems sort of dead these days and Fibrechannel over Ethernet is annoying. What is one to do? There is SCST for Linux, but I haven't checked it out. See http://scst.sourceforge.net/ a generic SCSI target for Linux.
 +
 
 +
= iSCSI =
 +
 
 +
This describes my iSCSI server. This is a Linux server used as an iSCSI target. iSCSI has the annoying nomenclature of using "target" for server and "initiator" for client. Why not just call them client and server? I am still on the fence about iSCSI technology. Support seems just beyond experimental. I have the feeling that iSCSI will just end up as curiosity and will be abandoned in favor of other technologies. I would be happy to find a better distributed SAN technology. In my application I only choose iSCSI because we had to provide storage for some Windows servers which have built-in support for iSCSI.
 +
 
 +
In my particular application, the drives are formatted as NTFS. The iSCSI devices are defined as:
 +
 
 +
  /dev/sda1
 +
  /dev/sdb1
 +
  /dev/sdb2
 +
  /dev/sdc1
 +
  /dev/sdc2
 +
  /dev/sdd1
 +
 
 +
Under Linux you can manually mount these devices to see NTFS drives from Linux:
 +
 
 +
<pre>
 +
mount -t ntfs -o errors=recover /dev/sda1 /media/raid1
 +
</pre>
 +
 
 +
I found that when you mount an NTFS partition that it will not refresh the directory if anything is updated from the Windows side. I'm not sure if iSCSI was intended to be used in a multipath setup like this.
 +
 
 +
== mount NTFS partitions ==
 +
 
 +
When mounting an NTFS partition for an iSCSI shared partition I found that the trick to make it work is to use the errors=recover option.
  
 
<pre>
 
<pre>
 
mount -t ntfs -o errors=recover /dev/sda1 /media/raid1
 
mount -t ntfs -o errors=recover /dev/sda1 /media/raid1
 +
</pre>
 +
 +
=== iSCSI /etc config ===
 +
 +
/etc/ietd.conf
 +
 +
See `man ietd.conf`. See "chkconfig --list" to make sure the iscsi-target is on for the current run-level.
 +
 +
=== iSCSI errors ===
 +
 +
The ISCSI SAN periodically dies and the file systems become inaccessible. Logwatch error symptoms can look like this:
 +
 +
<pre>
 +
--------------------- Kernel Begin ------------------------
 +
 +
WARNING:  Kernel Errors Present
 +
  connection0:0: iscsi: detected conn error (1011) ...:  3 Time(s)
 +
  Buffer I/O error on device sdc1,  ...:  29 Time(s)
 +
  EXT2-fs error (device sdc1): e ...:  171 Time(s)
 +
  end_request: I/O error, dev sdc, sector ...:  2421 Time(s)
 +
  lost page write due to I/O error on sdc1 ...:  29 Time(s)
 +
  sd 3:0:0:0: SCSI error: return code = 0 ...:  2421 Time(s)
 +
  sd 3:0:0:0: SCSI error: return code ueu ...:  1 Time(s)
 +
</pre>
 +
 +
To fix, Reboot the Linux server that mounts the SAN. If you don't want to reboot, try restarting the iscsi daemon and remounting the file system. Use `fdisk -l` to make sure that the iscsi devices are visible.
 +
 +
<pre>
 +
service iscsi restart
 +
fdisk -l
 +
mount /my/iscsi/partition
 
</pre>
 
</pre>

Latest revision as of 07:20, 17 July 2012


See also

iSCSI seems sort of dead these days and Fibrechannel over Ethernet is annoying. What is one to do? There is SCST for Linux, but I haven't checked it out. See http://scst.sourceforge.net/ a generic SCSI target for Linux.

iSCSI

This describes my iSCSI server. This is a Linux server used as an iSCSI target. iSCSI has the annoying nomenclature of using "target" for server and "initiator" for client. Why not just call them client and server? I am still on the fence about iSCSI technology. Support seems just beyond experimental. I have the feeling that iSCSI will just end up as curiosity and will be abandoned in favor of other technologies. I would be happy to find a better distributed SAN technology. In my application I only choose iSCSI because we had to provide storage for some Windows servers which have built-in support for iSCSI.

In my particular application, the drives are formatted as NTFS. The iSCSI devices are defined as:

 /dev/sda1
 /dev/sdb1
 /dev/sdb2
 /dev/sdc1
 /dev/sdc2
 /dev/sdd1

Under Linux you can manually mount these devices to see NTFS drives from Linux:

mount -t ntfs -o errors=recover /dev/sda1 /media/raid1

I found that when you mount an NTFS partition that it will not refresh the directory if anything is updated from the Windows side. I'm not sure if iSCSI was intended to be used in a multipath setup like this.

mount NTFS partitions

When mounting an NTFS partition for an iSCSI shared partition I found that the trick to make it work is to use the errors=recover option.

mount -t ntfs -o errors=recover /dev/sda1 /media/raid1

iSCSI /etc config

/etc/ietd.conf

See `man ietd.conf`. See "chkconfig --list" to make sure the iscsi-target is on for the current run-level.

iSCSI errors

The ISCSI SAN periodically dies and the file systems become inaccessible. Logwatch error symptoms can look like this:

--------------------- Kernel Begin ------------------------

WARNING:  Kernel Errors Present
   connection0:0: iscsi: detected conn error (1011) ...:  3 Time(s)
  Buffer I/O error on device sdc1,  ...:  29 Time(s)
  EXT2-fs error (device sdc1): e ...:  171 Time(s)
  end_request: I/O error, dev sdc, sector ...:  2421 Time(s)
  lost page write due to I/O error on sdc1 ...:  29 Time(s)
  sd 3:0:0:0: SCSI error: return code = 0 ...:  2421 Time(s)
  sd 3:0:0:0: SCSI error: return code ueu ...:  1 Time(s)

To fix, Reboot the Linux server that mounts the SAN. If you don't want to reboot, try restarting the iscsi daemon and remounting the file system. Use `fdisk -l` to make sure that the iscsi devices are visible.

service iscsi restart
fdisk -l
mount /my/iscsi/partition