[EMAIL PROTECTED] wrote:
--- Eric Anderson <[EMAIL PROTECTED]> ha scritto:
...
ZFS surely is cool, but I'm not sure how much it benefits FreeBSD
compared to something like journaling, or adding features to our
existing filesystem, or even write support for one of the already ported
read-on
Hello;
--- Michael Vince <[EMAIL PROTECTED]> ha scritto:
(I forgot to mention Apple is interested in it too)
> Since this is a project that would benefit just about anyone using
> FreeBSD, it would be good to see a project like this get funding or do a
> fund raise.
> As a summer of code pro
On Wed, 31 May 2006, Attilio Rao wrote:
2006/5/31, Suleiman Souhlal <[EMAIL PROTECTED]>:
Nice work. Any chance you could also port it to amd64? :-)
Not in the near future, I think. :P
It is not useful for amd64. An amd64 has enough instruction bandwidth
to saturate the L1 cache using 64-bi
Michael Vince wrote:
[EMAIL PROTECTED] wrote:
Hello;
DragonFly and NetBSD are interested, I'm sure there's interest in
FreeBSD too,
but AFAICT no one has started.
Here is an interesting link:
http://www.opensolaris.org/os/community/zfs/porting/
cheers,
Pedro.
---
Since this is a pro
[EMAIL PROTECTED] wrote:
Hello;
DragonFly and NetBSD are interested, I'm sure there's interest in FreeBSD too,
but AFAICT no one has started.
Here is an interesting link:
http://www.opensolaris.org/os/community/zfs/porting/
cheers,
Pedro.
---
Since this is a project that would benefit
On Wednesday, 31 May 2006 at 8:05:21 -0700, Eugene M. Kim wrote:
> While watching the output of iostat -dxz -w10 -n100 to monitor the
> progress/performance of a dump(8) process straight to a tape, I found
> out something interesting and disappointing at the same time: The disk
> read throughput w
2006/6/1, Bruce Evans <[EMAIL PROTECTED]>:
>> Does that mean it won't work with SMP and PREEMPTION?
>
> Yes it will work (even if I think it needs more testing) but maybe
> would give lesser performances on SMP|PREEMPTION due to too much
> traffic on memory/cache. For this I was planing to use n
In <[EMAIL PROTECTED]>, Avleen Vig <[EMAIL PROTECTED]> typed:
> On Tue, May 30, 2006 at 04:42:12PM -0400, Mike Meyer wrote:
> > Well, it makes the throughput closer to symmetric when I'm pushing
> > traffic both ways - but at around 7MB/sec. If I only run traffic in
> > one direction, I get the pre
2006/5/31, Suleiman Souhlal <[EMAIL PROTECTED]>:
Hello Attilio,
Hello Suleiman,
Nice work. Any chance you could also port it to amd64? :-)
Not in the near future, I think. :P
Does that mean it won't work with SMP and PREEMPTION?
Yes it will work (even if I think it needs more testing) b
> Mostly off-topic, but couldn't you simplify the logic here slightly:
Definitely! I was originally going to compare jail IDs, but realized
I could just compare the jail pointers. Evidently my fingers were
still thinking about how to implement it the other way. ;-)
David.
Hello Attilio,
Attilio Rao wrote:
Hi,
this is the last release which is rather finished and complete for the
project.
I tested for consistency for a long time and the FPU handling
mechanism seems very robust so as copyin/copyout do.
Nice work. Any chance you could also port it to amd64? :-)
Sorry, but I unforgot one thing so, please, redownload the patch now.
Attilio
2006/5/31, Attilio Rao <[EMAIL PROTECTED]>:
Hi,
this is the last release which is rather finished and complete for the project.
I tested for consistency for a long time and the FPU handling
mechanism seems very robus
On Sunday 28 May 2006 11:25, David Malone wrote:
> On Sun, May 28, 2006 at 03:46:06PM +0200, Anatoli Klassen wrote:
> > if security.bsd.see_other_uids is set to 0, users from the main system
> > can still see processes from jails if they have (by accident) the save
uid.
> >
> > For me it's wrong
On Wed, 2006-May-31 08:05:21 -0700, Eugene M. Kim wrote:
>While watching the output of iostat -dxz -w10 -n100 to monitor the
>progress/performance of a dump(8) process straight to a tape, I found
>out something interesting and disappointing at the same time: The disk
>read throughput was exactly tw
On 5/31/06, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
If everyone is happy with the current patchset (if the man-page is
still missing, we may agree that it can be delivered at a later time),
I can try to get time to do it at the weekend (but feel free to beat
me in committing it).
Hello,
Hi,
this is the last release which is rather finished and complete for the project.
I tested for consistency for a long time and the FPU handling
mechanism seems very robust so as copyin/copyout do.
What I'm looking for, at this point, are testers for peroformances.
What is proposed in the patch
Dan Nelson wrote:
Are you using the -C option to dump? I would expact that to help more
in the "dumping directories" step, but it might help later phases too.
Yep, -C32.
Eugene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/ma
In the last episode (May 31), Eugene M. Kim said:
> While watching the output of iostat -dxz -w10 -n100 to monitor the
> progress/performance of a dump(8) process straight to a tape, I found
> out something interesting and disappointing at the same time: The
> disk read throughput was exactly twice
On Wed, 31 May 2006, Eugene M. Kim wrote:
read throughput was exactly twice as high as the tape write throughput,
throughout the entire dump phases 4 and 5, i.e. dumping actual inodes.
Disappointing, because the tape drive utilization (%busy) was lingering
around 35%-50% for most of the time; I
While watching the output of iostat -dxz -w10 -n100 to monitor the
progress/performance of a dump(8) process straight to a tape, I found
out something interesting and disappointing at the same time: The disk
read throughput was exactly twice as high as the tape write throughput,
throughout the ent
Quoting Wilko Bulte <[EMAIL PROTECTED]> (from Wed, 31 May 2006
13:53:47 +0200):
On Wed, May 31, 2006 at 01:48:09PM +0200, Dag-Erling Sm?rgrav wrote..
[cc: list trimmed a bit]
Alexander Leidinger <[EMAIL PROTECTED]> writes:
> He's not a src-committer and he prefers to let a src-committer do
>
Quoting Dag-Erling Smørgrav <[EMAIL PROTECTED]> (from Wed, 31 May 2006
11:57:35 +0200):
Daichi GOTO <[EMAIL PROTECTED]> writes:
It is my pleasure and honor to announce the availability of
the unionfs patchset-13.
Will you commit it already? :)
He's not a src-committer and he prefers to l
Daichi GOTO <[EMAIL PROTECTED]> writes:
> It is my pleasure and honor to announce the availability of
> the unionfs patchset-13.
Will you commit it already? :)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
On Wed, May 31, 2006 at 01:48:09PM +0200, Dag-Erling Sm?rgrav wrote..
> [cc: list trimmed a bit]
>
> Alexander Leidinger <[EMAIL PROTECTED]> writes:
> > He's not a src-committer and he prefers to let a src-committer do
> > it. I offered to commit it, but so far either the man-page was
> > missing
[cc: list trimmed a bit]
Alexander Leidinger <[EMAIL PROTECTED]> writes:
> He's not a src-committer and he prefers to let a src-committer do
> it. I offered to commit it, but so far either the man-page was
> missing (what's the status of this?) or a bug showed up.
>
> If everyone is happy with th
On Tue, May 30, 2006 at 07:17:45PM -0500, Rick C. Petty wrote:
> On Fri, May 26, 2006 at 10:59:18PM +0200, Ulf Lilleengen wrote:
> >
> > I've been looking through the kernel code the past few days, but I have not
> > found
> > what I'm looking for, which is a way to format "struct timeval" for ou
Hello!
I'm getting pretty repeatable abnormal termination of clamd
(ports/security/clamav) compiled with libunrar support on signal 4
(4.11-RELEASE/i386). I've built both clamd and libunrar with debugging info:
CFLAGS+= -g
LDFLAGS+= -g
STRIP=
and got the core. However I'm not sure how to i
27 matches
Mail list logo
