From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 23 Apr 2010 18:01:51 -0600 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>, "erik quanstrom" From: "EBo" Message-ID: In-Reply-To: <145bac50d1cc889e4e602cefa3be5478@kw.quanstro.net> References: , Subject: Re: [9fans] corrupted update on 9vx Topicbox-Message-UUID: 0ced2e4e-ead6-11e9-9d60-3106f5b1d025 Sorry for the delay > 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. Thanks for the pointer. I'll try playing around with NBUF and also see if I can play with the number of processes (thwack it to 1 for testing and see if that helps). > you're not using a fuse-based fs, are you? no. I did have fuse installed, but it was only used by usermode-utilities, and I have since removed both that and fuse. > 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. If I recall correctly, qlock has not been ported to 9vx. Ahhh... I see that it has. This saves me the hassles of porting it myself ;-) Laters, EBo --