Thanks for your reply - I understand your points .. but darn, it seemed so 'easy' :-) I come from the days of heavy CMS application/data usage, so a 'reacc' made life nice -- and techniques like renaming files before copying the new version of the file allowed you to get by 99% of the time and avoid shared minidisks causing others grief..
I don't suppose such techniques apply here? - Rename a file - don't erase it until next 'IPL' so others sharing the disk don't get corruption. - Rename a file before 'replacing' with a new one - so that 'old' users see the 'old' copy and 'new' users see the new copy. (TOOLSRUN used these methods IIRC..) Would those techniques help with a 'shared' Linux filesystem the way they did with a CMS one, do you think? Thanks! Scott On Tue, Mar 10, 2009 at 10:16 AM, Edmund R. MacKenty < [email protected]> wrote: > On Tuesday 10 March 2009 11:44, Scott Rohling wrote: > >Along these lines .. does a Linux filesystem on a RO minidisk reflect > any > >changes at all if changes are made by a user with RW? > > Yes, but you *really* don't want to do that. Your guest with the RO > minidisk > will get corrupted data. You see, Linux caches blocks it has read from the > filesystem in memory. So imagine that it reads in a block containing a set > of directory entries and caches that. Now imagine that another guest with > RW > access to that filesystem removes that directory. The RO guest won't know > about it: it will still happily use that cached directory block when > reading > that directory, which contains references to files that no longer exist. > What happens when it tries to read those files? It reads those blocks from > DASD, which may well have been overwritten by the RW guest with some other > data, because those blocks were freed up when the directory was deleted. > Oops! > > Another bad case is if the RO guest has cached some blocks from an > executable > file, and the RW guest has overwritten some or all of those blocks, perhaps > with another executable. The RO guest will read in blocks it hadn't cached > and load it as code, but it has been overwritten by something else (other > code, a text file, who knows?). When that process executes whatever is in > the newly-read block: boom! It will seg-fault at best. Or execute some > other code even! > > >Is a deactivate/activate necessary? re-LINK? remount? Anyone know the > >minimum necessary action to see changes? > > You should just never do this. Do not modify DASD while a Linux guest has > it > mounted read-only. There is no way you can know what parts of that DASD > are > cached and what is not. > - MacK. > ----- > Edmund R. MacKenty > Software Architect > Rocket Software > 275 Grove Street · Newton, MA 02466-2272 · USA > Tel: +1.617.614.4321 > Email: [email protected] > Web: www.rocketsoftware.com > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
