>Anybody know of a reliable way to cause buffer cache pages to be purged (not >written to disk, but released)??
Sure ... umount ... but this isn't going to help you :) >Problem: In a shared disk environment, changes made by the owner (R/W) are >not seen by R/O sharers in a timely fashion. This is especially problematic How are your disk readers ever going to know that disk hard sectors have been updated ... in any kind of reliable fashion? Scenario ... the vm with writeable access to the disk rewrites some hard sectors. Some/All of these sectors have already been read ... and buffered ... by the vms with read access to the disk. So, (1) the readers have no reason to go out and re-read these sectors again (2) you have no idea if the readers will seel all the updated sectors. >when the Linux virtual machine has a sizable virtual memory size allowing it >to have lots of buffercache. In small memory Linux images, the changes are >recognized fairly quickly, you can force by editing a sizeable file which >will cause the buffercache pages to be re-used (stolen). How are the changes recognized ... are the readers doing directory scans of the file system on the shared dasd? Are you using cron or something? There are no events to tell the disk readers (1) that changes have been made (2) what sectors have been updated. How about remounting the file system? Is this possible in your situation? >I realize that this is unsafe in the general sense (writing to a minidisk >that is shared by others), but I believe that it is fairly safe in the usage >I am attempting. Dunno about that ... >Have tried several variations of commands on both the owner and sharers. >Sync'ing and even shutting down the owner (to make sure the buffers are >written) does not have any effect. On the sharing systems, 'mount -o >remount', various other mount options and various blockdev options >(flushbufs, rereadpt) don't seem to help. Interestingly enough, 'blockdev >--rereadpt' will cause deleted files to be noticed immediately, but not >newly created files (I would have thought it wouldn't have affected either, >but was trying about anything!). >Have scoured some kernel code and believe there are routines that will do >what is needed. Usually used when unmounting a device or some other act of >removing, but don't see a way to force them to be called via any system >call/command available. Use a cluster file system (opengfs) or a network file system (nfs) and forget trying to sync your reader vms with the writer vm. The simplest method is probably just to nfs mount the file system. You still will not know when changes occur but at least you'll be in sync amongst the vms with the nfs mount. -Don
