> 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. 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 <[email protected]>: > On 27 Feb 2010 at 0:23, Kapetanakis Giannis wrote: > >> 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 > >> >> 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 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "open-iscsi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/open-iscsi?hl=en. >> > > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
