:No, this problem was fixed in -current with this commit (you looked at
:the wrong file, fix was in route.h):
:
:revision 1.30
:date: 1999/06/30 23:11:15; author: msmith; state: Exp; lines: +2 -3
:Increase the size of the route reference count from 15 bits to 31 bits.
:
:This doesn't change the
[CC: to peter, could you MFC this??]
[Charset X-UNKNOWN unsupported, skipping...]
ARGHH
> Hmmm. Judging from the last CVS log entry for route.c (See r1.59), this
> problem can manifest itself in -current as well. I´m cross posting on the
> initial send, but please, when replying, redirect
Hmmm. Judging from the last CVS log entry for route.c (See r1.59), this
problem can manifest itself in -current as well. I´m cross posting on the
initial send, but please, when replying, redirect to [single, truly]
appropriate list.
It *appears* that rtfree() is puking because the rnh point
* Wes Peters <[EMAIL PROTECTED]> [000207 15:02] wrote:
> Alfred Perlstein wrote:
> >
> > I asked this question because of a problem that Postgresql has,
> > basically multiple processes will be updating a file, they may do
> > scattered IO to multiple offsets into the file, at the end of a
> > tr
Alfred Perlstein wrote:
>
> I asked this question because of a problem that Postgresql has,
> basically multiple processes will be updating a file, they may do
> scattered IO to multiple offsets into the file, at the end of a
> transaction they want to sync the data... fsync(). ow. This causes
:I think two kinds of behavior are needed, ordered range fsync and
:unordered async fsync.
:
:The ordered range could be taken care of easily by your implementation,
:however for maximum effectiveness you'd want to allow for unordered
:async fsync and notification.
:
:The simplest way I can think
* Matthew Dillon <[EMAIL PROTECTED]> [000207 12:05] wrote:
>
> :Is it possible to submit several offsets of a file to be synced
> :rather than calling fsync or mmap'ing over the file and calling
> :msync()?
> :
> :The only way I can think of doing this is queuing write requests
> :backed by a O_F
:Is it possible to submit several offsets of a file to be synced
:rather than calling fsync or mmap'ing over the file and calling
:msync()?
:
:The only way I can think of doing this is queuing write requests
:backed by a O_FSYNC fd to an aiod.
:
:Even then the desired result isn't really achived
> I suspect that "gcc" isn't the standard FreeBSD C compiler in your
> case. Try "which gcc" and find out. It works fine for me on both
> -stable and -current with "cc":
It is an older one indeed.
> blake$ cc -v -nostdlib hello.c
> Using builtin specs.
> gcc version 2.95.2 19991024 (release)
>
Is it possible to submit several offsets of a file to be synced
rather than calling fsync or mmap'ing over the file and calling
msync()?
The only way I can think of doing this is queuing write requests
backed by a O_FSYNC fd to an aiod.
Even then the desired result isn't really achived as instea
> I'm planning to work on enhancing pkg_install tools following
> after NetBSD's effort. Seems they've been making some remarkable
> improvements over FreeBSD's original work since 1997. For example:
As the author of these tools, I would welcome those sorts of enhancements.
- Jordan
To U
In article <[EMAIL PROTECTED]>,
Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> I finished the syscalls, so now I moved on the initialisation code.
>
> To test that I try to create an empty binary, which doesn't link to libc:
>
> I've put in an hour effort, and wrote the following C file:
>
Hi, there.
I'm planning to work on enhancing pkg_install tools following
after NetBSD's effort. Seems they've been making some remarkable
improvements over FreeBSD's original work since 1997. For example:
- pkg_add/pkg_info to speak HTTP as well as FTP
- pkg_info/pkg_delete t
Zhihui Zhang <[EMAIL PROTECTED]> writes:
> The RX part seems to deal with RPC. I do not see the reason why it
> can improve performance.
Eh, what do you think is moving the bits to and from your fileserver?
For cached (non-network) accesses, arla is just slighly slower than
FFS.
/Johan
To Un
On 7 Feb 2000, Johan Danielsson wrote:
> Zhihui Zhang <[EMAIL PROTECTED]> writes:
>
> > If the daemon can somehow reside entirely inside the kernel, like
> > NFS daemon, we can save those crossings.
>
> Yes, but the whole point of having the daemon in userspace is that
> it's *so* much easier
(This is pobably inapproprate for -hackers. Reply to me alone or move it
to -questions, I guess)
On Mon, Feb 07, 2000 at 01:29:33PM +0100, Christoph Kukulies wrote:
[ntop]
> While building it I found that configure said:
>
> ...
>
> checking whether time.h and sys/time.h may both be included.
Look at /usr/ports/sysutils/lsof
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I've been advised by someone to try to use 'ntop', an network
analysis tool. Found it in the FreeBSD ports
collection.
While building it I found that configure said:
...
checking whether time.h and sys/time.h may both be included... yes
checking for lsof... no
WARNING: unable to locate lsof.
Zhihui Zhang <[EMAIL PROTECTED]> writes:
> If the daemon can somehow reside entirely inside the kernel, like
> NFS daemon, we can save those crossings.
Yes, but the whole point of having the daemon in userspace is that
it's *so* much easier to maintain. If you want to work on performance,
I sugg
> >grep exit *.o
> >
> >in /usr/lib doesn't find me that label.
> >
> >What am I missing?
>
> Try this instead:
>
> nm /usr/lib/libc.a | grep exit
I'm aware of that! That is libc which I'm trying to avoid here!
(see man gcc, search for -nostdlib)
I was referering to excuting gcc with -
20 matches
Mail list logo
