read only access on 1 LUN for multiple initiators
Kapetanakis Giannis
This probably have been brought up before, but I couldn't find any info.
I'd like to setup multiple initiators (web/ftp cluster) to access
read-only the same iscsi target.
I would prefer to do this without cluster fs (ie GFS) if possible.
However I want to have right access on the target server locally.
I managed to do this but I have the following problem:
When I write something on the target (locally on the server)
the updates are not propagated to the initiators.
If I unmount and mount again I can see the changes.
I'm sharing /dev/vg01/iscsi which is an ext3 fs. It's locally mounted on
server
and also mounted (/dev/sde -> /mnt) on clients.
Server is centos 5.4 scsi-target-utils-0.0-6.20091205snap.el5_4.1
<target iqn.2008-09.com.example:server.target2>
backing-store /dev/vg01/iscsi
incominguser user pass
initiator-address 10.0.0.0/26
write-cache off
</target>
client is Fedora 12 iscsi-initiator-utils-6.2.0.870-10.fc12.1.x86_64
scsi22 : iSCSI Initiator over TCP/IP
scsi 22:0:0:0: RAID IET Controller 0001 PQ: 0
ANSI: 5
scsi 22:0:0:0: Attached scsi generic sg5 type 12
scsi 22:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0
ANSI: 5
sd 22:0:0:1: Attached scsi generic sg6 type 0
sd 22:0:0:1: [sde] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
sd 22:0:0:1: [sde] Write Protect is off
sd 22:0:0:1: [sde] Mode Sense: 79 00 00 08
sd 22:0:0:1: [sde] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sde: unknown partition table
sd 22:0:0:1: [sde] Attached SCSI disk
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
so is GFS the only option?
Giannis
Ulrich Windl
> Hi,
>
> This probably have been brought up before, but I couldn't find any info.
>
> I'd like to setup multiple initiators (web/ftp cluster) to access
> read-only the same iscsi target.
> I would prefer to do this without cluster fs (ie GFS) if possible.
> However I want to have right access on the target server locally.
>
> I managed to do this but I have the following problem:
> When I write something on the target (locally on the server)
> the updates are not propagated to the initiators.
Naturally, read-only media don't propagate changes, because they don't
change. Remember that clients (especially Linux) doe cache blocks
locally, and they do not invalidate that cache. So you could even
experience application crashes when accessing data structures that were
partially cached while being changed on the original.
> If I unmount and mount again I can see the changes.
Naturally, because unmount invalidates the cached blocks for the
device.
Regards,
Ulrich
> --
> You received this message because you are subscribed to the Google Groups "open-iscsi" group.
> To post to this group, send email to open-...@googlegroups.com.
> To unsubscribe from this group, send email to open-iscsi+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
>
Yangkook Kim
> locally
Doesn't kernel refresh the read cache for blocks at some intervals?
If I make a new file on target locally, and waiting for sometime,
hitting read command like "ls" on initiator side will read data from
block device, not from stale cache, so that I can read updated data.
I believed that this is how the file-system is supposed to work,
but it is not?
>they do not invalidate that cache.
Clients not invalidating cache means that they do not
update their read cahce unless the volume is remounted?
2010/3/1, Ulrich Windl <Ulrich...@rz.uni-regensburg.de>:
Yangkook Kim
Doesn't kernel refresh the read cache for blocks at some intervals?
If I make a new file on target locally, and waiting for sometime,
hitting read command like "ls" on initiator side will read data from
block device, not from stale cache, so that I can read updated data.
I believed that this is how the file-system is supposed to work,
but it is not?
>they do not invalidate that cache.
Clients not invalidating cache means that they do not
update their read cahce unless the volume is remounted?
Thanks.
kim
2010/3/1, Ulrich Windl <Ulrich...@rz.uni-regensburg.de>:
romeotheriault
>
> so is GFS the only option?
Is NFS an option?
Romeo Theriault
so is GFS the only option?
Is NFS an option?
--
Romeo Theriault
Ulrich Windl
> > Remember that clients (especially Linux) doe cache blocks
> > locally
>
> Doesn't kernel refresh the read cache for blocks at some intervals?
>
> If I make a new file on target locally, and waiting for sometime,
> hitting read command like "ls" on initiator side will read data from
> block device, not from stale cache, so that I can read updated data.
Did you try this:
"ls" on the initiator
create file on local target
"ls" again on initiator
I would be really surprised if the second "ls" would not take the
directory listing from the cache.
Pasi Kärkkäinen
> On 2 Mar 2010 at 2:03, Yangkook Kim wrote:
>
> > > Remember that clients (especially Linux) doe cache blocks
> > > locally
> >
> > Doesn't kernel refresh the read cache for blocks at some intervals?
> >
> > If I make a new file on target locally, and waiting for sometime,
> > hitting read command like "ls" on initiator side will read data from
> > block device, not from stale cache, so that I can read updated data.
>
> Did you try this:
> "ls" on the initiator
> create file on local target
> "ls" again on initiator
>
> I would be really surprised if the second "ls" would not take the
> directory listing from the cache.
>
Yes, I'm 99% certain the second "ls" will come from the initiator box
kernel cache.
Why? Because that's how it's supposed to work! You're using ext3,
which is NOT cluster-aware filesystem!
The ext3 filesystem contents do NOT change 'on it's own', ie. all the
changes to the disk/lun will be done by the same system itself..
So when the initiator box didn't change anything (and it didn't, since
the lun is read-only), why would it have to re-read the disk or flush the cache?
ext3 (and all the other non-cluster-filesystems) are not designed to be used like this.
-- Pasi