From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 22 Apr 2010 14:53:50 -0400 To: 9fans@9fans.net Message-ID: <145bac50d1cc889e4e602cefa3be5478@kw.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] corrupted update on 9vx Topicbox-Message-UUID: 0c33e3d0-ead6-11e9-9d60-3106f5b1d025 On Thu Apr 22 14:45:38 EDT 2010, steve@quintile.net wrote: > replica uses fcp which works multithreaded for speed. > > Perhaps the implementation of fswrite() #Z in 9vx uses a seek() > followed by a write() rather than pwrite() which is not thread safe. replica actually uses replica/applylog.c:^/worker internally, not fcp. but essentially, it's the same thing. it copies NBUF=8192 bytes at a time with 16 parallel processes. #Z uses pwrite on non-sockets. in theory, since NBUF < SSIZE_MAX, pwrite should be atomic to normal files. you're not using a fuse-based fs, are you? possible ways to debug: 1. reduce NBUF to PIPE_BUF=4096. guard against someone treating the fd as a pipe. 2. put a qlock in the UnixFd structure in devfs-posix.c. lock for all io. - erik