2nd Edition Plan 9 had a neat program, games/road, which
provided a map of the US with data on roads and the like.
Among other neat features was the ability to highlight
just requested features. For example, you could have the
map show just I-80 and US-22.
I've got a project (not related to Plan 9
On Thu Apr 18 12:10:28 EDT 2013, n...@lsub.org wrote:
> yes, except that the whole thing
> got worse because one of our servers
> had a lot of memory used due to
> those and we put back the bind for
> tmp.
ramfs -l 10m
(the 9atom version of ramfs does proper accounting to
make this work.)
als
yes, except that the whole thing
got worse because one of our servers
had a lot of memory used due to
those and we put back the bind for
tmp.
On Apr 18, 2013, at 5:33 PM, Charles Forsyth wrote:
>
> On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
>> if one has one problem, it can lock ever
> On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
>
>> if one has one problem, it can lock everyone else using /mail/tmp.
>
>
> I use a private ramfs, which is also faster.
Obvious, when one points it out!
++L
On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
> if one has one problem, it can lock everyone else using /mail/tmp.
I use a private ramfs, which is also faster.
Yes, perhaps we should stop using that.
Nevertheless, the problem I was trying to address is that
everyone is sharing /mail/tmp (see the scripts in /mail/lib,
although I'm sure you know them from memory :) ), and thus
if one has one problem, it can lock everyone else using /mail/tmp.
I'll take a l
> The problem was that we had quite a number of upas/fs's and scanmails
> running and it was because one of them had a problem and kept a
> /mail/tmp/L.mbox file locked. All other ones kept waiting for that
> (although all of them were using different "mboxes" created by the
> piped script at /mail
Yes, I noticed the comment, but I thought it was wrong.
The problem was that we had quite a number of upas/fs's and scanmails
running and it was because one of them had a problem and kept a
/mail/tmp/L.mbox file locked. All other ones kept waiting for that
(although all of them were using differen
> Looking into, we found that in upas/common/libsys.c the
> function generating the lock file name returns always "L.mbox"
> but not .../L. as it seems it should.
i think the comment above the function is important
"we use one lock per directory". it's been a long time since
i worked on nupas, so
Hi,
we found recently that we had a problem with /mail/tmp/L.mbox
used by upasfs to lock.
Looking into, we found that in upas/common/libsys.c the
function generating the lock file name returns always "L.mbox"
but not .../L. as it seems it should.
Also, the function doing the actual lock hides th
10 matches
Mail list logo
