Date: Sat, 25 May 2002 00:58:18 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Eugene Grosbein <eugen@svzserv.kemerovo.su> Cc: stable@FreeBSD.ORG Subject: Re: NFS problem with 4.6-PRERELEASE: SIGBUG in Apache Message-ID: <200205250758.g4P7wIHP061953@apollo.backplane.com> References: <3CEE5094.EFF31B42@grosbein.pp.ru> <200205242137.g4OLbFmi058923@apollo.backplane.com> <20020525102224.A43047@svzserv.kemerovo.su> <200205250250.g4P2oSdA060174@apollo.backplane.com> <3CEF1E41.841937F4@svzserv.kemerovo.su> <200205250740.g4P7ee6P061752@apollo.backplane.com> <3CEF42CC.74C2B50C@svzserv.kemerovo.su>
next in thread | previous in thread | raw e-mail | index | archive | help
: :How one can write reliable application using mmap :if plain read from file after successful mmap can destroy an application? : :Eugene Grosbein I don't understand. Reading from a file will not screw up an application. It's changing a file out from under mmap() ... specifically, changing the *size* of the file which can potentially cause an application using mmap() on the file to seg-fault if it attempts to read an area in the mmap() that is beyond the post-truncation file EOF. This has always been true and will occur with a local filesystem as well as with NFS. The major issue with NFS vs a local filesystem is that the since NFS is a stateless protocol, deleting a file on the server can cause clients with open file descriptors to the deleted file to get I/O errors on those descriptors (or seg faults if they happen to be mmap()'d). On a local filesystem the file doesn't actually go away until the last open descriptor is closed. So when updating files which might be mmap()'d over NFS, you have to be careful not to delete or truncate a file which may be in-use. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205250758.g4P7wIHP061953>