You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Alexis Rosen <al...@panix.com> on 2004/04/04 23:00:55 UTC
Re: [alexis@panix.com: Fwd: Reminder: SpamAssassin needs your help!]
On Fri, Apr 02, 2004 at 04:13:05PM -0800, Justin Mason said:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Alexis Rosen writes:
> >Hey, guys. I'm just following up because I'm curious about the final
> >disposition of the nfslock code. Did you add a function to correspond to
> >nfsunlock? I hope the rest of my comments were helpful.
>
> Actually, we haven't :( It dropped off my radar, unfortunately.
>
> I'm thinking we should take a look at that before 3.0.0 release, and
You *really* should.
> probably we should also add a *non*-NFS-safe locking function too for
> hosts where NFS is not involved -- as I think we could cut down
> lock overhead quite a lot that way.
Absoultely. NFSlock is at least an order of magnitude more expensive than
using OS-supported locking schemes.
/a
Re: [alexis@panix.com: Fwd: Reminder: SpamAssassin needs your help!]
Posted by Kelsey Cummings <kg...@sonic.net>.
On Mon, Apr 05, 2004 at 12:28:00PM -0700, Justin Mason wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kelsey Cummings writes:
> > And, for that matter, at this point most (all?) NFS implementations
> > implement locking anyway. It'd be fairly easy to add this to the tests.
>
> Yes, but do they implement it *correctly*? ;) as far as I know that's
> the problem.
True that. Do you think that file locking tests in the make procedure
would be able to properly test implementation? In any case, it'd be nice
to see selectable locking code. Most installations can use flock on local
disks without any problem and would probably gain some performance. People
on NFS (I imagine a small number) could use whichever they felt comfortable
with.
--
Kelsey Cummings - kgc@sonic.net sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
Re: [alexis@panix.com: Fwd: Reminder: SpamAssassin needs your help!]
Posted by Kelsey Cummings <kg...@sonic.net>.
On Mon, Apr 05, 2004 at 05:37:11PM -0400, Alexis Rosen wrote:
> On Sun, Apr 04, 2004 at 05:40:35PM -0700, Kelsey Cummings said:
> > And, for that matter, at this point most (all?) NFS implementations
> > implement locking anyway. It'd be fairly easy to add this to the tests.
>
> Yes, but be cautious. Locking over NFS has been claimed to work successfully
> for many years, and yet odd failures would pop up again and again. I'm
> thinking back to the SunOS 4 days, of course, but I'm still skeptical. IIRC,
> someone wrote a well-received paper many years ago (12? 15?) that proved
> mathematically that nfs locking was impossible to do correctly 100% of the
> time. Best to offer people the choice. This is mail and users/customers tend
> to get bent out of shape when it gets lost...
We were always cautious of nfslocking, which is why we contributed the
existing code as a safe method. However, since then, we've proven that
flock works for us just fine. This would be NFSv3 with linux clients and
NetApp filers.
As you say, YMMV.
--
Kelsey Cummings - kgc@sonic.net sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
Re: [alexis@panix.com: Fwd: Reminder: SpamAssassin needs your help!]
Posted by Alexis Rosen <al...@panix.com>.
On Sun, Apr 04, 2004 at 05:40:35PM -0700, Kelsey Cummings said:
> And, for that matter, at this point most (all?) NFS implementations
> implement locking anyway. It'd be fairly easy to add this to the tests.
Yes, but be cautious. Locking over NFS has been claimed to work successfully
for many years, and yet odd failures would pop up again and again. I'm
thinking back to the SunOS 4 days, of course, but I'm still skeptical. IIRC,
someone wrote a well-received paper many years ago (12? 15?) that proved
mathematically that nfs locking was impossible to do correctly 100% of the
time. Best to offer people the choice. This is mail and users/customers tend
to get bent out of shape when it gets lost...
(BTW, I have no idea if the same issues exist in NFSv4. I would be unsurprised
either way.)
/a
Re: [alexis@panix.com: Fwd: Reminder: SpamAssassin needs your help!]
Posted by Kelsey Cummings <kg...@sonic.net>.
On Sun, Apr 04, 2004 at 05:00:55PM -0400, Alexis Rosen wrote:
> On Fri, Apr 02, 2004 at 04:13:05PM -0800, Justin Mason said:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > Alexis Rosen writes:
> > >Hey, guys. I'm just following up because I'm curious about the final
> > >disposition of the nfslock code. Did you add a function to correspond to
> > >nfsunlock? I hope the rest of my comments were helpful.
> >
> > Actually, we haven't :( It dropped off my radar, unfortunately.
> >
> > I'm thinking we should take a look at that before 3.0.0 release, and
>
> You *really* should.
>
> > probably we should also add a *non*-NFS-safe locking function too for
> > hosts where NFS is not involved -- as I think we could cut down
> > lock overhead quite a lot that way.
>
> Absoultely. NFSlock is at least an order of magnitude more expensive than
> using OS-supported locking schemes.
And, for that matter, at this point most (all?) NFS implementations
implement locking anyway. It'd be fairly easy to add this to the tests.
--
Kelsey Cummings - kgc@sonic.net sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896