Disk /dev/sdc: 42.9 GB, 42949672960 bytes
64 heads, 32 sectors/track, 40960 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000现在就可以对这两块逻辑盘进行分区格式化(创建文件系统)，并投入使用。
此时先看下target端的target信息。
tgt-admin -s | less
其中I_T nexus表示initiator到target的关联信息，nexus的值是该initiator关联到target的次数。多个initiator会显示多个I_T nexus信息。这里可以看到只有一个I_T nexus，说明只有一个initiator进行了关联。
2.3.6 iSCSI的数据不安全性(不同步性)现在在initiator上将/dev/sdb进行格式化，并向其中写入一个文件。
parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart /dev/sdb1 ext4 1 10G
mkfs.ext4 /dev/sdb1
parted /dev/sdb print
mount /dev/sdb1 /mnt/
echo "haha" > /mnt/test.txt然后配置服务器C(192.168.100.6)，让其作为另一台initiator。
bash> yum -y install iscsi-initiator-utils
bash> iscsiadm -m discovery -t st -p 192.168.100.151:3260
bash> iscsiadm -m node -T iqn.2017-03.com.longshuai:test.disk1 -p 192.168.100.151:3260 -l
bash> fdisk -l
bash> mount /dev/sdb1 /mnt
bash> ls /mnt
lost+found test.txt不出所料，C服务器也能挂载/dev/sdb1，且在B服务器写入的test.txt文件也已经同步过来了。
再看看此时target的target信息。
bash> tgt-admin -s
Target 1: iqn.2017-03.com.longshuai:test.disk1
System information:
Driver: iscsi
State: ready
I_T nexus information:
I_T nexus: 1
Initiator: iqn.2017-03.com.longshuai:b01d684ad13f
Connection: 0
IP Address: 192.168.100.5
I_T nexus: 2
Initiator: iqn.1994-05.com.redhat:42b7f829d2ec
Connection: 0
IP Address: 192.168.100.6现在在C服务器上，向/dev/sdb1挂载的目录/mnt下写入一个文件，看看是否会同步到B服务器上。
echo "hehe" >/mnt/test1.txt在192.168.100.5上执行：
ls /mnt/
lost+found test.txt
echo "heihei" >/mnt/test3.txt显然，test1.txt并没有同步到B服务器上。同理，此时B中再写入文件也不会同步到C上。
那么在C上卸载/mnt，然后再次挂载会有什么情况呢？
umount /mnt
mount /dev/sdb1 /mnt
ls /mnt
lost+found test3.txt test.txt没看错，test1.txt确实没了。这就是使用iscsi出现的问题，多个主机同时使用逻辑存储，数据会冲突并且不能及时同步而导致数据丢失。
所以，iscsi一定要配合集群文件系统或者分布式文件系统来使用以防止上述问题。
2.3.7 initiator开机一直处于等待状态该问题在前文描述过。
出现这个问题是因为initiator端设置了iscsi或iscsid开机自启动，正好又无法和target联系，如通信出现故障、target处于关机状态、target中的tgtd服务未启动、target上的target_id和target_name等配置改变了。
总而言之，开机自启动的时候无法正常关联/var/lib/iscsi目录下记录的target就会出现此问题。
解决办法也是建议的办法是把iscsi和iscsid的开机自启动关闭掉，然后把启动他们的命令放到rc.local中。
如果已经遇到了无法正常开机的情况，那么可以多等待些时间，或者修改target端让target端能够和initiator匹配上。如target端本来是关机状态，将其开机即可。
第3章 target和initiator的配置文件 3.1 initiator的配置文件一般而言，对于initiator的配置文件/etc/iscsi/iscsid.conf，里面默认设置了重启服务就自动对已发现过的target进行关联，所以重启iscsi服务的时候会自动进行关联。
如果不使用CHAP，则基本可以无视这个配置文件。使用CHAP认证的时候配置下面CHAP相关的段落就够了，其他的配置段落可以不用理会。关于CHAP认证，稍后就介绍。
# *************
# CHAP Settings
# *************
####以下是initiator authentication相关
# To enable CHAP authentication set node.session.auth.authmethod to CHAP. The default is None.
#node.session.auth.authmethod = CHAP
# To set a CHAP username and password for initiator authentication by the target(s):
#node.session.auth.username = username
#node.session.auth.password = password