Thanks Rick, Yes, I know and expect cms access to work that way. If I have an R/O link to a dial and that disk changes, I have to access it again. That’s because the access command copies the disk directory to my storage/memory. If the disk contents change, my in-memory copy doesn’t know about it. That’s not too bad, cms is a single user system.
On Linux if I have to take the device offline/online to ensure I don’t see stale data, that can impact other Linux users. Good tip about flushing the cache… I’ll see if that’s an option. Even just unmounting the file system could fail if it’s in use. My bash script tries to unmount/mount. If the unmount fails it issues a warning saying the disk contents may be stale. I suppose another approach is to keep the device offline and serialize access so a process that needs those files would get exclusive use of a semaphore, bring the disk online, mount it, use whatever, unmount it, take it offline and finally release the semaphore so another waiting process could access it. That would ensure freshness but sure seems ugly in a multiuser environment. 🙁 On Fri, Dec 27, 2024 at 07:54 Rick Troth <tro...@gmail.com> wrote: > Hi Don -- > > This is a sort-of non-answer but hopefully sheds light and maybe will > trigger a clue from those in the know. > > There are multiple caching things happening. > In the filesystem, there is directory cache which could affect where the > driver reads the files from disk (what data blocks on the volume are > referenced). As I recall, filesystem data caching is separate but still > a thing to reckon with. All of that SHOULD be flushed by umount/mount, > but even that much is a hassle, I agree. > > The 'mount' command has a "flush" option (if the FS driver supports it). > Not sure if that will go as far as needed (because next). > > The kernel also caches blocks from devices. I know even less about this, > but it would explain why you have to chccwdev -d and then chccwdev -e. > > Personally I have lived with this for years and not bothered to find a > system call or a program which might force a refresh. > > Note that the "problem" of cached blocks affects CMS too. > If you shared this same disk with another CMS user, you'd have a > reACCESS requirement. (You prolly know that, but seems wise to point out > the correlation.) > > > -- R; <>< > > > > On 12/26/24 4:51 PM, Donald Russell wrote: > > I have a CMS disk mounted with cmsfs-fuse at /cms191. It’s defined in > the > > directory as RR and mounted on Linux read-only. > > > > From my cms id I changed a file there, but Linux doesn’t see the change. > > > > Based on that, I suspect the disk directory was copied to Linux memory > when > > the file system was mounted, so I have to unmount/mount it again. > > > > To my surprise that did not work either. I have to chccwdev -d 191 and > > enable/mount again. > > > > Is there a way to have Linux read the directory again without having to > > take disk offline/online? > > > > I have a bash script that uses the files on the 191 cms disk. I had code > > that checks if /cms191 is a mount point, and if so, unmount/mount but > > that’s not working. > > > > This is rhel 9, but I see the same on rhel 7 (and don’t have a rhel 8 > > system) > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email tolists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
