On Tuesday, 03/10/2009 at 12:19 EDT, "Edmund R. MacKenty" <[email protected]> wrote:
> 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! For large-scale sharing, xip2fs and DCSSes are the only way (IMO) to share files in the way we all originally envisioned minidisk sharing. The DCSS owner makes all the updates and then saves a new copy of the DCSS. New users get the new one - previous users still have the old DCSS. When no one is using the old one any more, it magically disappears. And the DCSSes always have consistent content, even if someone loads the DCSS while you're in the middle of building a new one. Without unionfs or its moral equivalent, it requires a clear separation of config, runtime temp storage, and executables into separate directories. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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
