From: "Ara.T.Howard" Date: 2003-11-17T10:25:48+09:00 Subject: pstore and nfs rubyists- i'm developing a system which needs to coordinate some actions against a nfs mounted filesystem. there are million ways to skin a cat, but one simple way is to coordinate actions using fcntl locks on nfs files. to that end i wrote a module that, when included, replaces File#flock with an fcntl (vs flock) based implimentation (essentially this is missing/flock.c). this works really well, i've tested in situations with many machines running many multi threaded process - each competing to update an ordered on nfs disk list - and it's runs without error for days on end. next i thought i'd test an nfs mounted pstore, using the replacement locking mechanism (fcntl). this does not work. rather, it sort of works but eventually fails with 'Marshal data too short'. i've tried adding a seek to end of file after the lock is obtained to pstore.rb, but that does not address the problem. so my question is this, assuming that my locking mechanism works (which pretty serious test show that it does) are there known race conditions when many processes are competing to update a pstore which could result in dirty reads, partial writes, or the like? stumped. -a -- ATTN: please update your address books with address below! =============================================================================== | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328 | STP :: http://www.ngdc.noaa.gov/stp/ | NGDC :: http://www.ngdc.noaa.gov/ | NESDIS :: http://www.nesdis.noaa.gov/ | NOAA :: http://www.noaa.gov/ | US DOC :: http://www.commerce.gov/ | | The difference between art and science is that science is what we | understand well enough to explain to a computer. | Art is everything else. | -- Donald Knuth, "Discover" | | /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done' ===============================================================================