Re: quotas an essential feature? (was: svn commit: r218953 - stable/8/usr.sbin/sysinstall)
On Fri, Feb 25, 2011 at 11:25:00PM -0800, Tim Kientzle wrote: On Feb 25, 2011, at 3:46 PM, Steven Hartland wrote: While I can understand some may want its not something we use on any of our machines, and I suspect that's the case for many others. Given adding it means the kernel will be doing extra work and hence a drop in performance... Does anyone have benchmark results to measure the performance hit? I imagine there wouldn't be any (or extremely negligible) unless you used quotaon(8). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
Hello, I updated a system from 8.1-RELEASE to 8.2-RELEASE today and now I'm having issues with gpart and gmirror. In the past I had two non-identical disks (one 250gb and one 750gb), which I wanted to create a mirror for them, so to do this, I gpart'ed them to equal sizes and then gmirror'ed them, without any issues. Of course that means that the rest 500gb of the bigger disk is not mirrored, but that wasn't a problem, since I was keeping non-important data there. Now I've got a second 750gb disk and updated to 8.2-RELEASE, and I wanted to create a full mirror of the two disks and the problems popped up. Hope you can help me a bit here. What I did is: 1. Backed up my system 2. Booted from FixIt image 3. Removed all previous partitions for gpart. 4. Did a gmirror for ad0 Fixit# gmirror label -vb round-robin gm0 /dev/ad0 5. gpart'ed the gm0 device, so I have gm0pN partitions 6. Restored everything from the backup to the gmirror'ed partitions 7. Reboot After a reboot I get this right before the FreeBSD bootloader starts: gptboot: invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. I still have another option, and that is to create partitions on the disks and then gmirror them, just like a did before without issues, and my explanation for this would be that gpart would use the last sectors of ad0 and ad1, while gmirror would use the last sectors of the partitions - ad0pN. That way I don't get any issues, but why when I want to create mirror of the whole disks I get this? Shouldn't gmirror and gpart store it's data on different sectors in that case? What would happen if I try to glabel the disks first, then gmirror and then gpart them? I guess I would mess up everything again. Should I go back to my previous setup with mirroring partitions, instead of disks? gpart now supports a `backup' option, so inserting a new disk in case of disk crash is just as simple as putting the new disk, restoring GPT tables from backup and putting the partitions in a mirror. Thanks for any feedback. Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
/dev/dsp mmap question
Guys, if we the following on FreeBSD (pseudo-code): fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); This won't work entirely correctly, right? I base my question on some observations of how a particular program behaves on FreeBSD and on the following comment in sys/dev/sound/pcm/dsp.c: /* * XXX The linux api uses the nprot to select read/write buffer * our vm system doesn't allow this, so force write buffer. * * This is just a quack to fool full-duplex mmap, so that at * least playback _or_ recording works. If you really got the * urge to make _both_ work at the same time, avoid O_RDWR. * Just open each direction separately and mmap() it. * * Failure is not an option due to INVARIANTS check within * device_pager.c, which means, we have to give up one over * another. */ P.S. is this something that can easily fixed or not? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: After a reboot I get this right before the FreeBSD bootloader starts: gptboot: invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? No. Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
2011/2/26 Andrey V. Elsukov bu7c...@yandex.ru: On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: After a reboot I get this right before the FreeBSD bootloader starts: gptboot: invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? No. Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? No, no other issues noticed. Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. Would do that, but unfortunately as mentioned I was running a Fixit image locally, so the only thing I got was a lit of paper and a pen to write down the messages :) Anyway, I've switched back to partition mirroring, which is good enough for me. Redundancy is still present in case of a disk failure since the second disk also contains bootcode and it boots up normally. Thanks for the feedback. Regards, Marin -- WBR, Andrey V. Elsukov -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] improve accuracy and speed of tanh[f] for x in [0:1)
The patch that follows my signature improves both the
accuracy and speed of tanhf and tanh in the interval
[0,1). The testing was done on an Intel Core2 Duo CPU
T7250 and everything is compiled with gcc. The
improvements are accomplished by using a trancated
continued fraction instead of relying on expm1[f] and
a rewritten definition of tanh(x). The results can
be summarized by
| fdlibm | Con. frac.
---
| ulp time | ulp time
tanhf | 1.66 1.36 | 0.56 1.31
tanh | 2.16 5.65 | 1.53 5.33
tanhl | 2.36 4.72 | 1.53 5.12
ulp in the above table is the maximum ulp observed for
2 million evenly distributed values with the interval.
The timing for tanhf is for 5 million calls and the
timing for tanh is for 20 million calls, where again the
values are evenly distributed across the interval. The
timings are the total time in seconds for a tight loop.
For those paying attention, yes, the last entry is for
tanhl, which libm does not currently implement. I have
an implementation that uses expm1l and fdlibm's simple
rewritten tanh(x) definition. I, of course, have a
truncated continued fraction implementation as well.
Now for those that are really paying attention, libm
does not contain an expm1l. :)
--
Steve
Index: src/s_tanh.c
===
--- src/s_tanh.c(revision 219046)
+++ src/s_tanh.c(working copy)
@@ -66,8 +66,33 @@
t = expm1(two*fabs(x));
z = one - two/(t+two);
} else {
+#if 0
+ /*
+* In the interval, one has a max ulp of 2.156 for 2M
+* evenly distributed values. For timing, 20M call
+* gives 5.65 s.
+*/
t = expm1(-two*fabs(x));
z= -t/(t+two);
+#else
+ /*
+* This is a continued fraction representation that
+* was truncated at the 10th level and then refractored
+* to get rid of the divisions. In the interval, one
+* has a max ulp of 1.532 for 2M evenly distributed
+* values. For timing, 20M calls give 5.33 s.
+*/
+ double x2, t1, t2, t3, t4, t5;
+ x2 = x * x;
+ t1 = 399 + 20 * x2;
+ t3 = 17 * t1 + (21 + x2) * x2;
+ t4 = 15 * t3 + t1 * x2;
+ t5 = 13 * t4 + t3 * x2;
+ t2 = 99 * t5 + (9 * t4 + t5) * x2;
+ t3 = 7 * t2 + (11 * t5 + t4 * x2) * x2;
+ z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2)));
+ return (z);
+#endif
}
/* |x| = 22, return +-1 */
} else {
Index: src/s_tanhf.c
===
--- src/s_tanhf.c (revision 219046)
+++ src/s_tanhf.c (working copy)
@@ -44,8 +44,29 @@
t = expm1f(two*fabsf(x));
z = one - two/(t+two);
} else {
+#if 0
+ /*
+* In the interval, one has a max ulp of 1.66 for 2M
+* evenly distributed values. For timing, 5M calls
+* give 1.36 s.
+*/
t = expm1f(-two*fabsf(x));
z= -t/(t+two);
+#else
+ /*
+* This is a continued fraction representation that
+* was truncated at the 6th level and then refractored
+* to get rid of the divisions. In the interval, one
+* has a max ulp of 0.559 for 2M evenly distributed
+* values. For timing, 5M calls give 1.306 s.
+*/
+ float x2, t1, t2, t3;
+ x2 = x * x;
+ t1 = 11 + x2;
+ t2 = 9 * t1 + x2;
+ t3 = 7 * t2 + t1 * x2;
+ z = x / (1 + x2 / (3 + t3 * x2 / (5 * t3 + t2 * x2 )));
+#endif
}
/* |x| = 9, return +-1 */
} else {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
libdispatch don't build on 8.2-RELEASE amd64
Hi guys, Anyone know what's going on? PS: with clang-devel libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -fPIC -DPIC -o .libs/time.o libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -fPIC -MT time.lo -MD -MP -MF .deps/time.Tpo -c shims/time.c -o time.o /dev/null 21 mv -f .deps/time.Tpo .deps/time.Plo /bin/sh ../libtool --tag=CC--mode=link clang -fPIC-o libshims.la mach.lo time.lo -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: ar cru .libs/libshims.a .libs/mach.o .libs/time.o libtool: link: ranlib .libs/libshims.a libtool: link: ( cd .libs rm -f libshims.la ln -s ../libshims.la libshims.la ) /bin/sh ../libtool --tag=CC--mode=link clang -Wall -fblocks -fPIC -o libdispatch.la -rpath /usr/local/lib libdispatch_la-apply.lo libdispatch_la-benchmark.lo libdispatch_la-object.lo libdispatch_la-once.lo libdispatch_la-queue.lo libdispatch_la-queue_kevent.lo libdispatch_la-semaphore.lo libdispatch_la-source.lo libdispatch_la-source_kevent.lo libdispatch_la-time.lo libshims.la -lpthread -L/usr/local/lib -lBlocksRuntime libtool: link: clang -shared .libs/libdispatch_la-apply.o .libs/libdispatch_la-benchmark.o .libs/libdispatch_la-object.o .libs/libdispatch_la-once.o .libs/libdispatch_la-queue.o .libs/libdispatch_la-queue_kevent.o .libs/libdispatch_la-semaphore.o .libs/libdispatch_la-source.o .libs/libdispatch_la-source_kevent.o .libs/libdispatch_la-time.o -Wl,--whole-archive ./.libs/libshims.a -Wl,--no-whole-archive -L/usr/local/lib -lpthread -lBlocksRuntime -Wl,-soname -Wl,libdispatch.so.0 -o .libs/libdispatch.so.0 /usr/local/bin/ld: .libs/libdispatch_la-apply.o: relocation R_X86_64_PC32 against symbol `_dispatch_hw_config' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174/src. *** Error code 1 Stop in /usr/ports/devel/libdispatch/work/libdispatch-r174. *** Error code 1 Stop in /usr/ports/devel/libdispatch. *** Error code 1 Stop in /usr/ports/devel/libdispatch. -- Danilo Egêa Gondolfo http://daniloegea.wordpress.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
