Re: [9fans] lnfs

Re: [9fans] lnfs

[Geoff Collyer]

I normally redirect mail in /mail/lib/rewrite rather than DNS:

# while our reverse DNS map isn't ours (PacBell's customer service for DNS is
# atrocious), forward via mail.pacbell.net for those sites that care.
([^!]+\.)?htdconnect\.com!.+ alias mail.pacbell.net!&

Re: [9fans] lnfs

[david presotto]

I'll fix lnfs for you, its a whole line to type but I'll go out of my way
just this once...

You can't override dns by changing ndb unless you own the domain, i.e.,
have a soa= in the record for the domain root.

A better solution might be to, as collyer suggests, change your rwrite rules
so that
you redirect the message to where you really would like it to go.
----- Original Message -----
From: <nigel@9fs.org>
To: <9fans@cse.psu.edu>
Sent: Wednesday, October 02, 2002 12:29 AM
Subject: Re: [9fans] lnfs


> > I'm not sure what you mean by flush, fprint is synchronous.
> > I could retry the write if you like, though there's not
> > much likelyhood that it would work the second time if
> > it didn't the first, there's no lock on .longnames,
> > it's append only, so a failure is probably the fs or
> > someone having removed the file.
> >
> > .longnames is also written before the file is created,
> > so the name should be there should you find the hashed
> > file when reading the dir.
> >
> I stupidly thought the open could fail if someone else had
> it open.
>
> > However, in rreaddir, I don't reread the file while
> > translating the short names to long ones.  Someone
> > could create a file while I'm busy converting the
> > dir.  There's plenty of window there for someone to
> > sneak through.
>
> I think this is the problem. I had a process running on the
> cpu server which walked the tree finding things to do, and
> another process on my terminal which added things to the
> tree. Perhaps I won't use lnfs after all...
>
> On another tack, how do I set up /lib/ndb/local so that
> mail to a particular site (vitanuova.com) is sent to a particular
> machine, in preference to what the public dns says?
> I tried
>
> dom=vitanuova.com mx=wibble pref=10
>
> but it doesn't show up in ndb/dnsquery.
>
>

Re: [9fans] lnfs

[david presotto]

It should, that was what I was implying.
----- Original Message -----
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Wednesday, October 02, 2002 1:08 AM
Subject: Re: [9fans] lnfs


> > > However, in rreaddir, I don't reread the file while
> > > translating the short names to long ones.  Someone
> > > could create a file while I'm busy converting the
> > > dir.  There's plenty of window there for someone to
> > > sneak through.
> >
> > I think this is the problem. I had a process running on the
> > cpu server which walked the tree finding things to do, and
> > another process on my terminal which added things to the
> > tree. Perhaps I won't use lnfs after all...
>
> Just put a readnames() call right after the dirreadall() call.
> The race goes away, no?
>
> Russ
>
>

Re: [9fans] lnfs

[Russ Cox]

> > However, in rreaddir, I don't reread the file while
> > translating the short names to long ones.  Someone
> > could create a file while I'm busy converting the
> > dir.  There's plenty of window there for someone to
> > sneak through.
>
> I think this is the problem. I had a process running on the
> cpu server which walked the tree finding things to do, and
> another process on my terminal which added things to the
> tree. Perhaps I won't use lnfs after all...

Just put a readnames() call right after the dirreadall() call.
The race goes away, no?

Russ

Re: [9fans] lnfs

[nigel]

> I'm not sure what you mean by flush, fprint is synchronous.
> I could retry the write if you like, though there's not
> much likelyhood that it would work the second time if
> it didn't the first, there's no lock on .longnames,
> it's append only, so a failure is probably the fs or
> someone having removed the file.
>
> .longnames is also written before the file is created,
> so the name should be there should you find the hashed
> file when reading the dir.
>
I stupidly thought the open could fail if someone else had
it open.

> However, in rreaddir, I don't reread the file while
> translating the short names to long ones.  Someone
> could create a file while I'm busy converting the
> dir.  There's plenty of window there for someone to
> sneak through.

I think this is the problem. I had a process running on the
cpu server which walked the tree finding things to do, and
another process on my terminal which added things to the
tree. Perhaps I won't use lnfs after all...

On another tack, how do I set up /lib/ndb/local so that
mail to a particular site (vitanuova.com) is sent to a particular
machine, in preference to what the public dns says?
I tried

dom=vitanuova.com mx=wibble pref=10

but it doesn't show up in ndb/dnsquery.

Re: [9fans] lnfs

[presotto]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

I'm not sure what you mean by flush, fprint is synchronous.
I could retry the write if you like, though there's not
much likelyhood that it would work the second time if
it didn't the first, there's no lock on .longnames,
it's append only, so a failure is probably the fs or
someone having removed the file.

.longnames is also written before the file is created,
so the name should be there should you find the hashed
file when reading the dir.

However, in rreaddir, I don't reread the file while
translating the short names to long ones.  Someone
could create a file while I'm busy converting the
dir.  There's plenty of window there for someone to
sneak through.

[-- Attachment #2: Type: message/rfc822, Size: 1727 bytes --]

From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: [9fans] lnfs
Date: Tue, 1 Oct 2002 09:18:49 +0100
Message-ID: <97967b679371324c95efff80d254b753@9fs.org>

Is it expected that lnfs can support several instances of it running
on the same file tree?

It looks that way in that it reloads the the name file before walks
and creates.

But there is no retry around the write of a new entry in newname().
So one instance might create a long named file, and fail to flush it
to .longnames.  Another instance would then not have a translation for
the base32 name it finds in the directory during a walk.

I accept that the windows are small, but I'm searching for an
explanation for some strange behaviour I saw yesterday.

[9fans] lnfs

[nigel]

Is it expected that lnfs can support several instances of it running
on the same file tree?

It looks that way in that it reloads the the name file before walks
and creates.

But there is no retry around the write of a new entry in newname().
So one instance might create a long named file, and fail to flush it
to .longnames.  Another instance would then not have a translation for
the base32 name it finds in the directory during a walk.

I accept that the windows are small, but I'm searching for an
explanation for some strange behaviour I saw yesterday.