Re: Is anyone working on a port of ZFS to FreeBSD
[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-only filesystems we have (like XFS, or reiserfs). I'm afraid adding write support to XFS or reiserfs is not easy, and then there's the license issue. ZFS might not have the best license either but we can work with it. Apple's updated HFS license is also something that could be worked with but Apple is interested in ZFS too so it must have something interesting ;-). I realize how hard getting write support for one of those is, for certain.You'd still have to go through the labor with ZFS though, unless you are talking about read-only support for it. I don't know much about licensing stuff... NetBSD has a Journalling Google SoC, definitely interesting if they get far. Pedro. We did too last year, but it didn't complete. I think Scott Long is back looking at it again (I've seen some hints of life in the p4 repo). Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is anyone working on a port of ZFS to FreeBSD
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 project I would assume this would be to difficult of > a project to for anyone but those of a fair amount of experience? > > Mike > Back in the days when IBM released their JFS for Linux, there was a written petition asking IBM to relax the license so that it would be ported to the BSDs. IBM didn't accept but it was really nice to see all the BSDs together on this. Porting it to one BSD will help the others, but maybe (and this is mere speculation) it would be easier for FreeBSD once Dtrace is finished/imported and we get some extra OpenSolaris compatibility in the headers. FWIW, I'd also like to see libumem ported. That said, these projects usually pick up only when someone takes the flag and starts on it's own, making it easier for an interested expert to continue and polish the initial effort. Pedro. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Adding optimized kernel copying support - Part III
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-bit accesses although not using 32-bit accesses. An amd64 has 64-bit integer registers which can be accesses without the huge setup overheads and code complications for MMX/XMM registers. It already uses 64-bit registers or 64-bit movs for copying and zeroing of course. Perhaps it should use prefetches and nontemporal writes more than it already does, but these don't require using SSE2 instructions like nontemporal writes do for 32-bit CPUs. 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 non-temporal instructions (obviously benchmarks would be very appreciate). Er, isn't its main point to fix some !SMP assumptions made in the old copying-through-the-FPU code? (The old code is messy due to its avoidance of global changes. It wants to preserve the FPU state on the stack, but this doesn't quite work so it does extra things (still mostly locally) that only work in the !SMP && (!SMPng even with UP) case. Patching this approach to work with SMP || SMPng cases would make it messier.) The new code wouldn't behave much differently under SMP. It just might be a smaller optimization because more memory pressure for SMP causes more cache misses for everything and there are no benefits from copying through MMX/XMM unless nontemporal writes are used. All (?) CPUs with MMX or SSE* can saturate main memory using 32-bit instructions. On 32-bit CPUs, the benefits of using MMX/XMM come from being able to saturate the L1 cache on some CPUs (mainly Athlons and not P[2-4]), and from being able to use nontemporal writes on some CPUs (at least AthlonXP via SSE extensions all CPUs with SSE2). Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is anyone working on a port of ZFS to FreeBSD
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 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 project I would assume this would be to difficult of a project to for anyone but those of a fair amount of experience? Mike 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-only filesystems we have (like XFS, or reiserfs). Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is anyone working on a port of ZFS to FreeBSD
[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 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 project I would assume this would be to difficult of a project to for anyone but those of a fair amount of experience? Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
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 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 didn't expect the disk would be > the bottleneck. :p > > I want to believe that this indicates a bug in dump(8) which causes each > disk block to be read twice, but being no UFS expert in any sense, I > wonder: Could this behavior be by design, and would there be any room > for improvement? Without looking at the code, this seems unlikely. But you might get more information by attaching a ktrace to the dump process for a short period of time (find the pid, then ktrace -p to start trace, ktrace -p -C to stop again). If you do that, let me see no more than 30 lines of repetitive trace. Greg -- See complete headers for address and phone numbers. pgpbFLHhXJTNg.pgp Description: PGP signature
Re: [patch] Adding optimized kernel copying support - Part III
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 non-temporal > instructions > (obviously benchmarks would be very appreciate). Er, isn't its main point to fix some !SMP assumptions made in the old copying-through-the-FPU code? (The old code is messy due to its avoidance of global changes. It wants to preserve the FPU state on the stack, but this doesn't quite work so it does extra things (still mostly locally) that only work in the !SMP && (!SMPng even with UP) case. Patching this approach to work with SMP || SMPng cases would make it messier.) The new code wouldn't behave much differently under SMP. It just might be a smaller optimization because more memory pressure for SMP causes more cache misses for everything and there are no benefits from copying through MMX/XMM unless nontemporal writes are used. All (?) CPUs with MMX or SSE* can saturate main memory using 32-bit instructions. On 32-bit CPUs, the benefits of using MMX/XMM come from being able to saturate the L1 cache on some CPUs (mainly Athlons and not P[2-4]), and from being able to use nontemporal writes on some CPUs (at least AthlonXP via SSE extensions all CPUs with SSE2). I was just speaking about the copying routine itself and not about the SSE2 environment preserving mechanism. It remains untouched in SMP case. However I need to say you were right when you suggested me to merge anything in support.s since it has a more coherent design. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Asymmetric ethernet throughput?
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 previous behavior. > I might like to suggest that the problem is your RealTek NIC. > Those NICs so utterly suck (I have 2, before anyone thinks I'm bashing > without cause :). Nope, that's not it. I get the same behavior from an Intel PRO/1000. And if that were the problem, I'd see it no matter what hosts I connect to, but if I make the other end a FreeBSD 6.1 box, I get a near-full pipe in both direction. > They're fine for light home use (and well priced for that). Never expect > consistancy or line speed from them though. This one came on the motherboard. I was using the intel until I needed to bridge it, and the rl bridging code worked where the em code didn't. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Adding optimized kernel copying support - Part III
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) but maybe would give lesser performances on SMP|PREEMPTION due to too much traffic on memory/cache. For this I was planing to use non-temporal instructions (obviously benchmarks would be very appreciate). What kind of performance improvements did you see in your benchmarks? I'm sorry but I didn't benchmarked on P4 (with xmm instructions). On P3, using integer copies, with dd and time I measured about 2% increasing, I hope more on P4 (and you might add xmm usage too). I wonder if we could get rid of the memcpy_vector (copyin/copyout_vector before this patch), bzero_vector and bcopy_vector function pointers and do boot-time patching of the callers to the right version Mmm, please note that on i386, at boot time (I've never studied that code) it seems requiring of vectorized version of bcopy/bzero. memcpy_vector that I introduced is used in slightly a different way from the other so I don't think it's so simple applying your idea to these. I have a linux-inspired proof-of-concept demo of this boot-time patching at http://people.freebsd.org/~ssouhlal/testing/bootpatch-20060527.diff. It prefetches the next element in the *_FOREACH() macros in sys/queue.h. The patching that it does is to use PREFETCH instruction instead of PREFETCHNTA if the cpu is found to support SSE2. It would be very appreciate to have it MI (yes, I mean MD + MI structure :PP) Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: security.bsd.see_other_uids for jails
> 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Adding optimized kernel copying support - Part III
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? :-) What I'm looking for, at this point, are testers for peroformances. What is proposed in the patch is one of the better solutions for UP archs (not running with PREEMPTION) but more general cases might be handled with time. Does that mean it won't work with SMP and PREEMPTION? I hope that somebody wants to play with him, giving suggestions and doing different benchmarks. What kind of performance improvements did you see in your benchmarks? The code can be found here: http://users.gufi.org/~rookie/works/patches/xmmcopy_6_1.diff and is for RELEASE_6_1 in order to have a wider range of testers (a diff against HEAD will be available ASAP). Please keep in mind that this is not a complete rip of DflyBSD code beacause it is different in a lot of parts. For any kind of tecnical questions, please mail me. I wonder if we could get rid of the memcpy_vector (copyin/copyout_vector before this patch), bzero_vector and bcopy_vector function pointers and do boot-time patching of the callers to the right version. I have a linux-inspired proof-of-concept demo of this boot-time patching at http://people.freebsd.org/~ssouhlal/testing/bootpatch-20060527.diff. It prefetches the next element in the *_FOREACH() macros in sys/queue.h. The patching that it does is to use PREFETCH instruction instead of PREFETCHNTA if the cpu is found to support SSE2. -- Suleiman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Adding optimized kernel copying support - Part III
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 robust so as copyin/copyout do. What I'm looking for, at this point, are testers for peroformances. What is proposed in the patch is one of the better solutions for UP archs (not running with PREEMPTION) but more general cases might be handled with time. I hope that somebody wants to play with him, giving suggestions and doing different benchmarks. The code can be found here: http://users.gufi.org/~rookie/works/patches/xmmcopy_6_1.diff and is for RELEASE_6_1 in order to have a wider range of testers (a diff against HEAD will be available ASAP). Please keep in mind that this is not a complete rip of DflyBSD code beacause it is different in a lot of parts. For any kind of tecnical questions, please mail me. Attilio PS: a particular thanks goes to Bruce Evans for his benchmarks and feedbacks about code structure -- Peace can only be achieved by understanding - A. Einstein -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: security.bsd.see_other_uids for jails
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 behavior because the main system and the jail are two
> > different systems where uids are independent.
>
> You could try the following (untested) patch to the MAC seeotheruid
> module. You'd need to compile a kernel with the MAC option and then:
>
> kldload mac_seeotheruids
> sysctl security.mac.seeotheruids.enabled=1
> sysctl security.mac.seeotheruids.jail_match=1
>
> and I think it will do what you want. The module is very simple, so
> if it doesn't quite do what you want, then you may be able to tweak
> it to get what you want.
>
> David.
>
>
> Index: sys/security/mac_seeotheruids/mac_seeotheruids.c
> ===
> +static int
> +mac_seeotheruids_prison_check(struct ucred *u1, struct ucred *u2) {
> +
> + if (!jail_match)
> + return (0);
> +
> + if (u1->cr_prison == NULL && u2->cr_prison == NULL)
> + return (0);
> +
> + if (u1->cr_prison != NULL && u1->cr_prison == u2->cr_prison)
> + return (0);
> +
> + return (ESRCH);
> +}
Mostly off-topic, but couldn't you simplify the logic here slightly:
{
if (!jail_match)
return (0);
if (u1->cr_prison == u2->cr_prison)
return (0);
return (ESRCH);
}
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
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 twice as high as the tape write throughput, >throughout the entire dump phases 4 and 5, i.e. dumping actual inodes. I looked into dump performance many years ago (as part of a thread which resulted in Matt Dillon adding the existing caching code) but can't find my notes right now. From memory, the main problems were that dump would re-read the inode multiple times and the physical read sizes were (pretty much) limited to the filesystem blocksize. The caching code increases the read blocksize but this also means that data read from the disk may not be needed. Dumping small files is the worst case. If you remove the '-C' parameter, you'll probably find that your disk throughput drops to only slightly more than the tape throughput, though the tape utilisation will probably drop further. If your concern is tape drive utilisation (because you want it for other tasks) or the tape drive dropping out of streaming mode, your only real solution is staging to disk. I wrote a tool similar to ports/misc/buffer that supported hysteresis to minimise the number of start/stop cycles but it only marginally speeds up the total dump time (sometimes dump runs faster than the tape and so a buffer helps here). There probably is more scope for enhancing dump throughput. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
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, I haven't been able to test whether the new patchset handles the bug I reported to Mr. Daichi Goto but so far haven't received a reply. Perhaps my message got lost somewhere, so I thought it would be a good idea to report this bug again. I diff'ed -p11 against -p12 (not yet against -p13) but haven't been able to determine myself if this bug got fixed. To foreign a code for me to understand as I have no background on the inner workings of FreeBSD's VFS, so I can't realy tell if the differences were sufficient to fix the bug. Here's a reprint of my bug report when -p11 was the newest available version. A post scriptum to the original message: The buggy behaviour won't affect the host system, but the jail could well be compromised. I also have this feeling that ACLs also aren't respected inside jails or can be overwritten as easily as shown below Thanks, André -- 8< -- Hi, Once again, thank you for your patch. I believe I have found a bug: If a file or directory has non-default flags and this directory is mounted below a target point, the resulting union will not preserve the directory flags. Worse, it will appear as if the file flags are preserved, but they are not and as soon as a file that should not be modified gets modified, the flags are reset to the default state on the union mount. This could pose a *serious* security breach for people running jails rooted on unionfs mounts, like I intended to. Test case: (discrepancies are marked by a line containing " NOTICE" and aligned to fixed-length font display) # cd /tmp # mkdir -p test/a test/b/bb test/b/cc # touch test/b/cc/dd # chflags schg test/b/bb/ # chflags uappnd test/b/cc/dd # ls -Rlo total 2 drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 test ./test: total 4 drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 a drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 b ./test/a: total 0 ./test/b: total 4 drwxr-xr-x 2 root wheel schg 512 Apr 29 08:12 bb NOTICE 1a drwxr-xr-x 2 root wheel -512 Apr 29 08:12 cc ./test/b/bb: total 0 ./test/b/cc: total 0 -rw-r--r-- 1 root wheel uappnd 0 Apr 29 08:12 dd NOTICE 2a ^^ # echo ee >test/b/cc/dd test/b/cc/dd: Operation not permitted. # echo ee >> test/b/cc/dd NOTICE: this is the intended behavior for the 'uappnd' flag # cat test/b/cc/dd ee # # mount_unionfs -c transparent -b test/b test/a # ls -Rlo total 2 drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 test ./test: total 4 drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 a drwxr-xr-x 4 root wheel - 512 Apr 29 08:12 b ./test/a: total 4 drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 bb NOTICE 1b^^^ drwxr-xr-x 2 root wheel - 512 Apr 29 08:12 cc ./test/a/bb: total 0 ./test/a/cc: total 2 -rw-r--r-- 1 root wheel uappnd 3 Apr 29 08:15 dd NOTICE 2b (LOOKS OK) ^^ ./test/b: total 4 drwxr-xr-x 2 root wheel schg 512 Apr 29 08:12 bb drwxr-xr-x 2 root wheel -512 Apr 29 08:12 cc ./test/b/bb: total 0 ./test/b/cc: total 2 -rw-r--r-- 1 root wheel uappnd 3 Apr 29 08:15 dd # echo ff > test/a/cc/dd # cat test/a/cc/dd ff NOTICE: very wrong behavior for the 'uappnd' flag! # ls -lo test/a/cc/dd -rw-r--r-- 1 root wheel - 3 Apr 29 08:20 test/a/cc/dd NOTICE 2c (NO FLAG!) ^^^ # echo gg >test/b/cc/hh # chflags schg test/b/cc/hh # rm test/b/cc/hh override rw-r--r-- root/wheel schg for test/b/cc/hh? yes rm: test/b/cc/hh: Operation not permitted NOTICE 3a^^^ # ls -lo test/a/cc/hh -rw-r--r-- 1 root wheel schg 3 Apr 29 08:24 test/a/cc/hh NOTICE 3b # rm test/a/cc/hh override rw-r--r-- root/wheel schg for test/a/cc/hh? yes NOTICE 3c (NO ERROR!) # ls -lo test/a/cc/ total 2 -rw-r--r-- 1 root wheel - 3 Apr 29 08:20 dd NOTICE 3d (the file is gone despite immutable flags seemingly set!) End of test case It makes no difference to specify '-c tradicional'. I skimmed over the patch code and have noticed no file flags or director[y flags] are indeed [ever] copied to the shadow files. [Edit: spelling] I'd really appreciate if you could fix that for the patch version 12. Thank you very much! André ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] Adding optimized kernel copying support - Part III
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 is one of the better solutions for UP archs (not running with PREEMPTION) but more general cases might be handled with time. I hope that somebody wants to play with him, giving suggestions and doing different benchmarks. The code can be found here: http://users.gufi.org/~rookie/works/patches/xmmcopy_6_1.diff and is for RELEASE_6_1 in order to have a wider range of testers (a diff against HEAD will be available ASAP). Please keep in mind that this is not a complete rip of DflyBSD code beacause it is different in a lot of parts. For any kind of tecnical questions, please mail me. Attilio PS: a particular thanks goes to Bruce Evans for his benchmarks and feedbacks about code structure -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
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/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
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 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 didn't > expect the disk would be the bottleneck. :p > > I want to believe that this indicates a bug in dump(8) which causes > each disk block to be read twice, but being no UFS expert in any > sense, I wonder: Could this behavior be by design, and would there be > any room for improvement? 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. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
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 didn't expect the disk would be the bottleneck. :p I had a similar experience when dumping my mailserver. In addition I noticed that for a user with >30 files (spam mails) in one directory it caused dump to sit back and think for half an hour before proceeding. I always resolved to look into the code to find something O(x^n) but didn't have the real urge. DID someone here look into that? Regards erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dump(8) performance
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 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 didn't expect the disk would be the bottleneck. :p I want to believe that this indicates a bug in dump(8) which causes each disk block to be read twice, but being no UFS expert in any sense, I wonder: Could this behavior be by design, and would there be any room for improvement? Puzzled, Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
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 > 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 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). I have an even better suggestion: sponsor him for a commit bit. He obviously has the required skills. If someone wants to volunteer as mentor, by all means send a request to core. AFAIK Daichi is working as a proxy for is co-worker who wrote the code but relies on the english skills of Daichi to communicate with us. Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
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 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 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). Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
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 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
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 (what's the status of this?) or a bug showed up. > > > > 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). > > I have an even better suggestion: sponsor him for a commit bit. He > obviously has the required skills. If someone wants to volunteer as mentor, by all means send a request to core. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-13 release
[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 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). I have an even better suggestion: sponsor him for a commit bit. He obviously has the required skills. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Formatting time in kernel
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 output > > in the same matter as the ctime(3) in the standard libc. I keep thinking > > how this part of the code > > should not be in kernel because of this, but things will be vastly more > > complicated if not because of the whole gvinum structure. (This is for use > > in > > the gvinum dumpconfig option I'm working on, and I'm not sure if it's > > really that important > > showing the creation time, but that's a different discussion). > > Why can't you just pass the struct timeval up to the userland tool and have > gvinum call ctime? Or at the very least pass up a time_t. Maybe go the > other route and pass up the whole gv_label (I'm assuming this is the > structure you're talking about).. /sbin/gvinum already has to include > vinum/geom_vinum_var.h so it's not like it's very kernel-specific (e.g. > #ifdef KERNEL). I personally feel that stuff like this belongs in userland > not kernel, parsing or converting times, etc. I agree, but currently the output list, printconfig and those are heavily formatted in the kernel, so I was just looking for the easy way out as a temporate solution. However, I intend to pass the whole configuration to userland, not just the label, and let the tools format it there, as I see to this point see no reason for it to be in the kernel. -- Mvh Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
clamd+libunrar signal 4: how to debug?
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 interpret gdb output: GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf Core was generated by `clamd'. Program terminated with signal 4, Illegal instruction. Reading symbols from /usr/local/lib/libclamav.so.1...done. Reading symbols from /usr/local/lib/libunrar.so...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/lib/libbz2.so.1...done. Reading symbols from /usr/local/lib/libgmp.so.7...done. Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/lib/libstdc++.so.3...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "", FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564 564 } (gdb) path /usr/ports/archivers/libunrar/work/unrar Executable and object file path: /usr/ports/archivers/libunrar/work/unrar:/home/root/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin Current language: auto; currently c++ (gdb) bt full #0 0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "", FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564 VolName = 0xbfad7c9c "" VolNumStart = Cannot access memory at address 0xbfac7ccc. --^^ Does this message suggest that program ran out of the stack? I doubt it, process stack limit is pretty high (268435456 bytes). However, application is multithreaded, so I'm not sure (maybe, thread runs out of it's stack)? (gdb) fr 0 #0 0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "", FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564 564 } (gdb) list 559 if (Truncate) 560 *VerTextW=0; 561 } 562 } 563 return(Version); 564 } 565 566 567 #ifndef SFX_MODULE 568 char* VolNameToFirstName(const char *VolName,char *FirstName,bool NewNumbering) Does this listing suggest that no code of VolNameToFirstName() has actually been executed yet? What other gdb commands can I use to narrow down the problem? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
