mouse@mcgill-vision.UUCP (02/05/87)
In article <6437@allegra.UUCP>, mp@allegra.UUCP (Mark Plotnick) writes: > As for ables@mcc-pp's question about cron not noticing changes in a > shared crontab, I think the problem may be due to the caching in ND. > [...] and periodically flushing the clients' disk caches should help. > We've found "du /pub" - we have several thousand files in our /pub - > and a couple "umount /pub"'s (umount will fail, of course, but it > does what we want) usually flush the cache. Doesn't `sync' work? There's a syscall sync() to flush the buffer cache, and there's a program /etc/sync which calls it. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu
guy@gorodish.UUCP (02/09/87)
>> shared crontab, I think the problem may be due to the caching in ND. >Doesn't `sync' work? There's a syscall sync() to flush the buffer >cache, and there's a program /etc/sync which calls it. Umm, err... having a writable ND partition available to more than one machine is an error. Would you take a vanilla UNIX kernel, put in a driver for a dual-ported disk, and have a file system writable by one machine and accessible to another machine, and expect it to work? I thought not. Think of an ND partition as residing on a multi-ported disk; it was not intended to be used in this fashion, and has no "cache invalidate" operation to enable an ND client to invalidate other ND clients' caches, so in that sense you still have a vanilla UNIX kernel. If you do a "sync" on a machine that has the disk mounted read-only, it does nothing for you. If you do it on a machine that has it mounted read-write, it will push any unwritten blocks to the disk but will *NOT* invalidate any copies of those blocks in any other machine's cache.