Re: ZFS memory management
2012/11/27 Freddie Cash : > Read any ZFS tuning manual on the web, including the ones direct from > SUN/Oracle, and they all list: > - if you are running processes that need a lot of memory, then limit the > ARC to allow the apps to have access to that memory Or you could have at least a little swap (good practice) to allow ARC take the time to evict some memory when under pressure. > > :) > > > On Tue, Nov 27, 2012 at 12:10 PM, Nikolay Denev wrote: > >> Hello list, >> >> I have the following question : I have several machines with 196G of RAM >> that are using >> RELENG_9 with ZFS, and are running a very memory intensive java >> applications - ElasticSearch >> The machines are without swap configured and have "vm.swap_enabled=0" in >> /etc/sysctl.conf. >> The ElasticSearch processes are using mlockall(2) to pin down their memory >> (configured at 40G). >> And at this point I thought that there would be no problems, but from time >> to time, when the machine grows it's >> ARC memory and there are some other running processes like nginx with >> passenger and uwsgi the ElasticSearch >> process would get killed by the kernel OOM killer with reason "no swap >> space available" >> >> Of course, I've now tuned down arc_max in /boot/loader.conf, but isn't >> this supposed to work automatically? Like >> ZFS releasing some memory when there is a pressure, instead of the OOM >> killer going postal? (at the moment when >> the process was killed the ZFS ARC was 132G). >> >> I understand that this might be problematic as AFAIK ZFS releases memory >> asynchronously when the arc_reclaim_thread() is run, >> which might take some time to be scheduled and complete. >> >> Cheers, >> Nikolay >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > > > -- > Freddie Cash > fjwc...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest for buildworld + clang + ccache
2012/11/23 Beeblebrox :
> I think I made a mistake:
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [tblgen] Error code 1
> 1 error
> *** [bootstrap-tools] Error code 2
> 1 error
> *** [_bootstrap-tools] Error code 2
> 1 error
> *** [buildworld] Error code 2
>
> in /urs/local/buildflags.conf I have:
> /usr/src | /usr/src/*{
> CC= clang
> CPP=clang
> CXX=clang
Two mistakes in fact ! Use clang++ and clang-cpp :)
> USE_CCACHE
> USE_CCACHE_CPP2 }
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org- against HTML email & vCards X
www: http://www.gid0.org- against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest for buildworld + clang + ccache
Hello, 2012/11/23 Beeblebrox : > 9.1-PRERELEASE #2 r242867: When will buildworld + clang + ccache be > functional? > I think I read somewhere that buildworld + clang - ccache was working fine > now. Any info on date ccache will work with clang and when to try? Can't comment on this. > Also, clang users - do you see any speed advantage for kernel / world / > ports built with clang? It's not really noticeable but some benchmarks were published on the lists (maybe current@ ?) some days / a few weeks ago, and I remember that buildworld is ~= 10% faster with a clang-compiled kernel + world than with a stock (old 4.2) gcc-compiled kernel+world. I'm not speaking of the compiler speed but really the speed of the same build when run under a clang- or a gcc-compiled base system. Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel panic caused by zfs/sa.c
2012/7/19 Greg Bonett :
> Hello,
>
> I'm experiencing a kernel panic that appears to be caused by zfs.
>
> No errors are making it into /var/log/messages, but here is the error
> message that appears on my screen after panic (transcribed):
>
> panic solaris assert BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC,
> file:
> /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c,
> line 1262
>
> I can reproduce this by running "cd /usr/ports/www/webkit-ghtk2; make
> clean"
If that's some sort of filesystem corruption, and you use portsnap, do
you still have a panic after "portsnap extract www/webkit-gtk2 && cd
/usr/ports/www/webkit-gtk2 && make clean" ?
> I looked at line 1262 in sa.c and it's part of a bit of code that checks
> if byte swapping is necessary. The code starting at line 1260:
>
>
> if (IS_SA_BONUSTYPE(bonustype) && sa_hdr_phys->sa_magic != SA_MAGIC &&
> sa_hdr_phys->sa_magic != 0) {
> VERIFY(BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC);
> sa_byteswap(hdl, buftype);
> }
>
> As far as I can tell, my source is up to date and this code is the same
> as what is in 9-STABLE.
>
> I'm not sure what's causing the panic, does anyone have a suggestion?
>
> Thanks for the help.
>
> --Greg
>
>
> _______
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org- against HTML email & vCards X
www: http://www.gid0.org- against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: buildworld fails with clang
2012/7/3 Dimitry Andric : > Yep, that is the culprit. Unfortunately I didn't quite follow the > commit rush before code freeze, and this problem was introduced. > > I've committed a fix to head (r238071), but it may take some time to MFC > to stable/9, since we've just entered code freeze. > > Meanwhile, you can apply this patch: > > http://svnweb.freebsd.org/base/head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c?view=patch&r1=238071&r2=238070&pathrev=238071 Thanks for the reply and the fix ! Just to be clear, it may take some time to MFC, but will it be done for releng/9.1 so that 9.1-RELEASE users can simply buildworld with clang ? Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
buildworld fails with clang
Hello, 9-STABLE fails to build with clang and *without* "NO_WERROR=" and "WERROR=" in /etc/make.conf. It used to work not long before : FreeBSD zozo.afpicl.lan 9.0-STABLE FreeBSD 9.0-STABLE #0 r237222M: Mon Jun 18 10:18:54 CEST 2012 r...@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 # svnversion 238067M # make NOCLEAN=yes NO_CLEAN=yes buildworld [...] ===> cddl/lib (obj,depend,all,install) ===> cddl/lib/drti (obj) ===> cddl/lib/libavl (obj) ===> cddl/lib/libctf (obj) ===> cddl/lib/libdtrace (obj) ===> cddl/lib/libnvpair (obj) ===> cddl/lib/libumem (obj) ===> cddl/lib/libuutil (obj) ===> cddl/lib/libzfs (obj) ===> cddl/lib/libzpool (obj) ===> cddl/lib/drti (depend) ===> cddl/lib/libavl (depend) ===> cddl/lib/libctf (depend) ===> cddl/lib/libdtrace (depend) ===> cddl/lib/libnvpair (depend) ===> cddl/lib/libumem (depend) ===> cddl/lib/libuutil (depend) ===> cddl/lib/libzfs (depend) ===> cddl/lib/libzpool (depend) ===> cddl/lib/drti (all) ===> cddl/lib/libavl (all) ===> cddl/lib/libctf (all) ===> cddl/lib/libdtrace (all) clang -O2 -pipe -march=corei7 -fomit-frame-pointer -I/usr/obj/usr/src/cddl/lib/libdtrace -I/usr/src/cddl/lib/libdtrace -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/amd64 -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DDIS_MEM -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -Wno-unknown-pragmas -c /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c -o dt_consume.o /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c:799:40: error: format specifies type 'long long' but the argument has type 'int64_t' (aka 'long') [-Werror,-Wformat] (void) snprintf(c, sizeof (c), ">= %lld", value); ~~~^ ~ %ld 1 error generated. *** [dt_consume.o] Error code 1 Stop in /usr/src/cddl/lib/libdtrace. *** [all] Error code 1 I used NOCLEAN and NO_CLEAN to see the error because I was compiling with -j8 before, but yes, my /usr/obj/ was clean at the time I attempted to buildworld. This may be the culprit ? # svn log -l 1 /usr/src/cddl/contrib/opensolaris/lib/libdtrace/ r237870 | pfg | 2012-07-01 06:15:14 +0200 (dim 01 jul 2012) | 8 lignes MFC r237624, r237714, r237716, r237860: Bring llquantize support into Dtrace. Bryan Cantrill implemented the equivalent of semi-log graph paper for Dtrace so llquantize will use one logarithmic and one linear scale. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How can I boot the second hard drive without proper BIOS or boot manager ?
Hello list, I was a happy user of boot0cfg and the boot0 boot manager until I converted my MBR+UFS disks to GPT+ZFS. Now I use gptzfsboot but sometimes I'd like to boot the second hard drive, and my crappy BIOS won't allow me to do that, it only allows to boot from the first hard drive (sic...). I'd like to avoid installing a full boot manager like grub2 (and I don't know if the FreeBSD port supports ZFS). Is there anything I can do at the "boot:" prompt to "chainload" the 2nd hard drive boot block ? Or can I use the boot0 boot manager and boot0cfg to boot the "freebsd-boot" GPT partition if it's mirrored in the protective MBR, like I used to do on my old MBR layout ? Thanks -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Different features on different CPU cores?!
2012/5/30 Zhihao Yuan : > OK... I see what happened: > > ~> cc a.c > ~> gcc46 a.c > In file included from a.c:1:0: > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd8.3/4.6.3/include/pmmintrin.h:32:3: > error: #error "SSE3 instruction set not enabled" > ~> clang a.c > In file included from a.c:1: > /usr/local/bin/../lib/clang/3.1/include/pmmintrin.h:28:2: error: "SSE3 > instruction set not enabled" > #error "SSE3 instruction set not enabled" > ^ > 1 error generated. > ~> gcc46 -msse3 a.c > ~> clang -msse3 a.c > ~> > > So the chromium port does not define -msse3/-mssse3 explicitly, so it > does not work with gcc46/clang. Isn't it /usr/share/mk/bsd.cpu.mk's job ? # make -V CPUTYPE core2 # make -V MACHINE_CPU ssse3 sse3 amd64 sse2 sse mmx I don't know if that's for the base system solely or if it works for ports too, but at least on this computer I can compile chromium 19.0.1084.52. Maybe you use CPUTYPE?=native, which is unsupported by bsd.cpu.mk. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UDP Port Open - Shorewall
2012/5/16 Shiv. NK : > Dear List Members, > > i trust anyone of you would have experience with Shorewall Firewall. I > have the following rule in rule file that is "/etc/shorewall/rules". > Traffic is not passing through. > > ACCEPT net loc:72.211.25.74 udp 123 > > This rule is working alright. i have problem understanding why udp has > problem > ACCEPT net loc:72.211.25.74 tcp 25 I don't see this question as related to FreeBSD -STABLE. But maybe you should explicitely accept udp packet returns. Your firewall (which I don't know) surely keeps states of TCP connections and implicitely accepts packets returns. Cheers. > > Thanks / Regards > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd and increase in energy need
2012/3/21 Kevin Oberman : > If you are trying to reduce power consumption, why are you limiting Cx > states to C2 (which save little) and not C3 (which will save a LOT of > power when the CPU is not heavily loaded). Jumping up on this but I don't know if that's related to his reasons to not use C3. Mine are simple : # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 39,0C dev.cpu.1.temperature: 40,0C dev.cpu.2.temperature: 36,0C dev.cpu.3.temperature: 36,0C dev.cpu.4.temperature: 41,0C dev.cpu.5.temperature: 41,0C dev.cpu.6.temperature: 36,0C dev.cpu.7.temperature: 36,0C # sysctl hw.acpi.cpu.cx_lowest=C3 hw.acpi.cpu.cx_lowest: C2 -> C3 # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 44,0C dev.cpu.1.temperature: 44,0C dev.cpu.2.temperature: 40,0C dev.cpu.3.temperature: 40,0C dev.cpu.4.temperature: 46,0C dev.cpu.5.temperature: 46,0C dev.cpu.6.temperature: 41,0C dev.cpu.7.temperature: 41,0C # sysctl hw.acpi.cpu.cx_lowest=C2 hw.acpi.cpu.cx_lowest: C3 -> C2 # sysctl dev.cpu | grep temperature dev.cpu.0.temperature: 40,0C dev.cpu.1.temperature: 40,0C dev.cpu.2.temperature: 36,0C dev.cpu.3.temperature: 36,0C dev.cpu.4.temperature: 42,0C dev.cpu.5.temperature: 42,0C dev.cpu.6.temperature: 36,0C dev.cpu.7.temperature: 36,0C Only 1-2 seconds between each command, no current load. As you can see, when I engage C3 states, the CPU temperature increases by 4-5°C. I expected it to drop. This is with : # sysctl dev.cpu | grep freq dev.cpu.0.freq: 2933 dev.cpu.0.freq_levels: 2933/95 2799/95 2266/75 1733/56 1199/39 # grep perf /etc/rc.conf performance_cx_lowest="C2" performance_cpu_freq="HIGH" # grep hint /boot/loader.conf hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 # dmesg | head -n 13 | tail -n 9 FreeBSD 9.0-STABLE #0 r233000M: Thu Mar 15 12:30:27 CET 2012 r...@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64 CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2793.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics I tried with and without powerd and there's no noticeable difference, so I don't use it. I also tried with and without performance_cpu_freq="HIGH" in /etc/rc.conf (without, dev.cpu.0.freq is 2799 so I don't think TurboBoost is enabled in this case). > If it is due to the system hanging, it is almost certainly because you > have throttling enabled. Throttling, either by the use of TCC (also > called P4TCC) or the older, externally implemented throttling > mechanism, is a BAD BAD THING! I have complained for years about it > being the default. It is intended for thermal control, not power > management. The power savings will be negligible and, in combination > with deep sleep modes (Cx > 2) can and do result in the CPU going into > deep sleep and never waking up. > > You can (and should) disable them in /boot/loader.conf with: > # Disable CPU throttling > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > This should greatly reduce the large number of "frequencies" > available, but they will be the ones provided by EST.which really do > reduce power consumption. (I put frequencies in quotation marks > because throttling does not really change the clock speed. It simply > skips 'N' of every 8 clock cycles. Still, compared to C3 and higher, > EST is a minor power savings. > > Just following the recommendations on the power management web page is > the way to go. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS: i/o error - all block copies unavailable on large disk number machines
Le lundi 23 janvier 2012, Matthew Seaman a écrit : > On 23/01/2012 19:29, Steven Hartland wrote: >> Initially the zpool was just the first raidz2. Only after install >> was the second raidz2 added to increase capacity. >> >> So what I believe has happened is the new kernel when installed >> happens to have data be located on the second raidz2 which >> consists of disks not available to the BIOS and hence results in >> "all block copies unavailable" from the boot code. > > Exactly what happened to me. You can run into this in a nasty way -- > insert the drives, and expand the zpool on-line, and everything will > carry on quite happily. Until you next reboot, when it just won't come > back. And you can't undo the expansion of the pool: due to the > copy-on-write behaviour of ZFS even overwriting a file in-place stands a > 50% chance of being written to the new vdev. > > In my case, I fixed it by having a separate /boot on some USB sticks -- > this was only ever accessed to read the kernel, kernel modules and > bootloader at boot time, so no worries over performance. Have you tried using a separate /boot on a zfs with copies=2 (or the number of vdevs composing the pool) ? >Cheers, > >Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matt...@infracaninophile.co.uk Kent, CT11 9PW > > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: "log_sysevent: type 19 is not implemented" messages during boot
2011/6/17 Rolf Nielsen : > 2011-06-17 16:29, Artem Belevich skrev: > <...> >>> >>> Are you sure that it's harmless? It appeared for me as an evidence of >>> pool >>> breakage. I had these messages when I ran any zpool command on broken >>> pool. >>> I do't havesingle one after pool is fixed. Here's my thread on freebsd-fs >>> : >>> http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011639.html >> >> Indeed. Same story here. Last week I've got my pool corrupted due to a >> bad memory stick. Then I've got tons of thse "log_sysevent: type >> 19..." messages. After re-importing the pool with -F the messages went >> away. So, from where I stand, those messages do seem to correlate with >> a problem and should not be hushed by default. >> >> Instead, they should probably be converted to something easier to >> understand by humans. Something like "Oops. I do hope you had a backup >> of this pool." should do the trick. >> >> --Artem >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> >> > > I haven't had any problems at all. In the daily script I get "all pools are > healthy", and I have, AFAIK, experienced no data loss (and yes, I do daily > backups). Seems to me it's a useless message, if it sometimes, but not > always, signals a problem. On mine, it pops up at boot on the console if the cache device is inaccessible (usb key). No real problem on the pool, but an information with more meaning would be useful. > > /Rolf > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE won't boot with ZFSv28
2011/6/1 Lystopad Olexandr : > Hello, Holger Kipp! > > On Wed, Jun 01, 2011 at 08:23:19AM + > holger.k...@alogis.com wrote about "8-STABLE won't boot with ZFSv28": >> Hi all, >> I have a very irritating problem with 8-STABLE and ZFSv28 >> >> I upgraded to 8-STABLE as of yesterday (31.05.2011), >> downloaded stable-8-zfsv28-20110521.patch.xz >> and applied the patch using >> >> cd /usr/src >> patch -E -p0 < /path/to/patchfile >> make buildworld >> make buildkernel KERNCONF=foo >> make installkernel KERNCONF=foo >> make installworld >> mergemaster > > Looks like you forgot to update your bootcode. gpart bootcode Only necessary if the pool is upgraded, which was not the case. > >> which all went smoothly. >> >> After reboot, I only got >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 >> all the time, and then after an hour or so (wasn't on site), >> system gave >> Fatal trap 12: page fault while in kernel mode >> cupid - 0; apic id = 00 >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0x80252301 >> stack poiner = 0x28:0xff8a7ac0 >> frame pointer = 0x28:0xff8a7b00 >> code segment = base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres1, long 1, def32 >> 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (thread taskq)trap number = 12 >> panic: page fault >> cpuid = 0 >> Uptime: 1h0m13s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> >> Needless to say the system did not reboot. Had to powercycle. >> >> Then always got the >> unknown: WARNING - ATAPI_IDENTITFY requeued due to channel reset LBA=0 >> error about once per second. >> >> Have now used a fixit-disk to change back to the old kernel: >> FreeBSD 8.2-STABLE #12: Mon Apr 18 12:48:56 CEST 2011 >> and rebootet. >> Now zfs claims to be v28, current storage pool is at 15.I'd love to >> try ZFSv28, but with the old kernel I don't think >> this is a good idea - but with the new kernel it seems I can't >> even boot properly. Don't upgrade the pool for now, you have problems to solve first. Then, you'll be able to upgrade the pool, and don't forget to also update the zfs boot code before rebooting (see UPDATING). Don't forget you won't be able to import your (upgraded) v28 pool with a 8.2-RELEASE if you have problems with 8-STABLE ! Also, you can use mfsbsd if you shoot yourself in the foot. >> Any suggestions as to how to proceed? > > -- > Lystopad Olexandr > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ZFSv28]gtpzfsboot fails to boot ZFSv28 0511
2011/6/1 Jeremy Chadwick : > On Tue, May 31, 2011 at 08:15:35PM -0500, Zhihao Yuan wrote: >> I met this problem, which is serious. I need some help to recovered >> the system, after that I'll show the photos about the error screen. >> >> I used the ZFSv28 patch maintained by mm@ before, and I have a >> backuped working kernel. I need a LiveCD/memstick to boot the system >> and recover it. But after I burned the 9.0-current image to memstick, >> I found that it keeps giving me kernel panic when booting! How can I >> find a LiveFS with ZFSv28 support? Thanks. > > The closest thing I can think of is this: > > http://mfsbsd.vx.sk/ I had a problem with latest gptzfsboot under 9-CURRENT with my v28 pool, and restored the old gptzfsboot I had on a snapshot with "gpart bootcode" thanks to mfsbsd. > Except: > > 1) The ISOs there don't claim to be "LiveFS"; I don't know if they are. > 2) There's no memory stick image available, only ISOs, > 3) They're 8.2-RELEASE with ZFSv28 patches, not 9.0-CURRENT. I don't > know the implications of this. > > Best to ask mm@. > > -- > | 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-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel memory leak in 8.2-PRERELEASE?
2011/4/2 Boris Kochergin : > pid 59630 (httpd), uid 80, was killed: out of swap space > pid 59341 (find), uid 0, was killed: out of swap space > pid 23134 (irssi), uid 1001, was killed: out of swap space > pid 49332 (sshd), uid 1001, was killed: out of swap space > pid 69074 (httpd), uid 0, was killed: out of swap space > pid 11879 (eggdrop-1.6.19), uid 1001, was killed: out of swap space Like others, I'll also suggest adding at least a little swap. If you don't have disk space outside of the ZFS pool (recommended way to create a swap), you can create one inside, with a zvol : zfs create -V 2G -o org.freebsd:swap=on -o primarycache=none -o secondarycache=none -o tank/swap I sometimes use "-b 8K" and "-o checksum=off" for the swap, but haven't stress tested this under 9-CURRENT and ZFS v28. > # zpool status > pool: home > state: DEGRADED > status: One or more devices could not be used because the label is missing > or > invalid. Sufficient replicas exist for the pool to continue > functioning in a degraded state. > action: Replace the device using 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-4J > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > home DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > ada0 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada5 UNAVAIL 0 85 11 experienced I/O failures > > errors: No known data errors Like others, I'll also *strongly* suggest fixing that ada5 problem. Try to run smartctl on the disk to see the problem. If the disk is bad, replace it ! Don't wait "for a few months" if you don't want to definitely loose your data. Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS with compression causes deadlock
2011/4/5 Andrey Zonov : > loader.conf: > ahci_load="YES" > zfs_load="YES" > vfs.zfs.arc_max="2G" > vfs.zfs.cache_flush_disable="1" # default: 0 Are you absolutely sure of what you're doing with the vfs.zfs.cache_flush_disable tunable ? Since you have SATA disks, I assume you don't have a controller with memory-backed write cache or NVRAM. > vfs.zfs.prefetch_disable="1" # default: 0 > vfs.zfs.txg.timeout="5" # default: 30 > vfs.zfs.zio.use_uma="0" # default: 0 (earlier was 1) -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Constant rebooting after power loss
2011/4/2 Matthew Dillon : > The core of the issue here comes down to two things: > > First, a power loss to the drive will cause the drive's dirty write cache > to be lost, that data will not make it to disk. Nor do you really want > to turn of write caching on the physical drive. Well, you CAN turn it > off, but if you do performance will become so bad that there's no point. > So turning off the write caching is really a non-starter. > > The solution to this first item is for the OS/filesystem to issue a > disk flush command to the drive at appropriate times. If I recall the > ZFS implementation in FreeBSD *DOES* do this for transaction groups, > which guarantees that a prior transaction group is fully synced before > a new ones starts running (HAMMER in DragonFly also does this). > (Just getting an 'ack' from the write transaction over the SATA bus only > means the data made it to the drive's cache, not that it made it to > the platter). Amen ! > I'm not sure about UFS vis-a-vie the recent UFS logging features... > it might be an option but I don't know if it is a default. Perhaps > someone can comment on that. > > One last note here. Many modern drives have very large ram caches. > OCZ's SSDs have something like 256MB write caches and many modern HDs > now come with 32MB and 64MB caches. Aged drives with lots of relocated > sectors and bit errors can also take a very long time to perform writes > on certain sectors. So these large caches take time to drain and one > can't really assume that an acknowledged write to disk will actually > make it to the disk under adverse circumstances any more. All sorts > of bad things can happen. > > Finally, the drives don't order their writes to the platter (you can > set a bit to tell them to, but like many similar bits in the past there > is no real guarantee that the drives will honor it). So if two > transactions do not have a disk flush command inbetween them it is > possible for data from the second transaction to commit to the platter > before all the data from the first transaction commits to the platter. > Or worse, for the non-transactional data to update out of order relative > to the transactional data which was supposed to commit first. > > Hence IMHO the OS/filesystem must use the disk flush command in such > situations for good reliability. > > -- > > The second problem is that a physical loss of power to the drive can > cause the drive to physically lose one or more sectors, and can even > effectively destroy the drive (even with the fancy auto-park)... if the > drive happens to be in the middle of a track write-back when power is > lost it is possible to lose far more than a single sector, including > sectors unrelated to recent filesystem operations. > > The only solution to #2 is to make sure your machines (or at least the > drives if they happen to be in external enclosures) are connected to > a UPS and that the machines are communicating with the UPS via > something like the "apcupsd" port. AND also that you test to make > sure the machines properly shut themselves down when AC is lost before > the UPS itself runs out of battery time. After all, a UPS won't help > if the machines don't at least idle their drives before power is lost!!! > > I learned this lesson the hard way about 3 years ago. I had something > like a dozen drives in two raid arrays doing heavy write activity and > lost physical power and several of the drives were totally destroyed, > with thousands of sector errors. Not just one or two... thousands. > > (It is unclear how SSDs react to physical loss of power during heavy > writing activity. Theoretically while they will certainly lose their > write cache they shouldn't wind up with any read errors). > > -Matt > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: genassym.c:1: error: CPU you selected does not support x86-64 instruction set
2011/3/18 Randy Bush : > FreeBSD rip0.psg.com 8.2-RC3 FreeBSD 8.2-RC3 #0: Sun Jan 30 06:28:31 UTC 2011 > r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > CPU: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (1999.78-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 > Features=0xfe3fbff > Features2=0x80082201> > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > > it is on a vm under vmware esxi 4.1 > > fresh csup and generic kernel in amd64 > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=i686 -std=c99 > -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 > --param inline-unit-growth=100 --param large-function-growth=1000 > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse > -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > /usr/src/sys/amd64/amd64/genassy > m.c > /usr/src/sys/amd64/amd64/genassym.c:1: error: CPU you selected does not > support x86-64 instruction set > *** Error code 1 Where does the -march=i686 come from ? What's your /etc/make.conf ? -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /sbin/reboot
2010/12/10 Garrett Wollman : > In article , > amvandem...@gmail.com writes: > >>For the correct order, "shutdown -r" calls reboot which calls init which >>calls rc.shutdown. > > No. shutdown(8) sends a SIGINT to init(8), which runs rc.shutdown and > then calls reboot(2) as its last act. > > reboot(8) freezes init(8), then sends a SIGTERM to anything left > running, then sends a SIGKILL to anything left running, then calls > reboot(2) as its last act. Thanks for clarifying this for Adam Vande More and all the persons he may have confused. Don's use reboot(8), even on a single user system (I'm not speaking of single user mode). The reboot command does not work like on most GNU/Linux systems ! An other thread on the same subject (quoting des@) :: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=419569+0+archive/2009/freebsd-current/20091004.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2010/freebsd-current/20100110.freebsd-current Something related : https://bugs.kde.org/show_bug.cgi?id=250989 >>Doing a shutdown -r is the same as a reboot without the warning to logged in >>users and shutdown handles the logging instead of reboot. Another no... > Not even close. > > -GAWollman > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: patch for topology detection of Intel CPUs
2010/9/6 Andriy Gapon : > on 06/09/2010 19:22 Jeremy Chadwick said the following: >> On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: >>> on 06/09/2010 16:12 Jeremy Chadwick said the following: >>>> Great, thanks! I'll be testing this out on two separate systems, both >>>> RELENG_8: >>>> >>>> - Supermicro X7SBA + Intel C2D E8400 (stepping 10) >>>> - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) >>>> >>>> I'll make sure to provide what the topology looks like before and after. >>>> Is CPU-relevant dmesg output sufficient? >>> >>> If you mean something like the below, then yes. Thanks! >>> [...] >> >> All done. Good news (I think): there's no difference in the CPU-related >> topology on either system with your patch, aside from kernel build date. >> The topologies are still detected correctly. In case you want them: >> > > Thanks a lot for the test! Here is mine : no difference before and after the patch : FreeBSD 8.1-STABLE #0 r212258M: Mon Sep 6 18:36:00 CEST 2010 r...@q.gid0.org:/usr/obj/usr/src/sys/QUAD amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2999.87-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Family = 6 Model = 17 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2029350912 (1935 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 The only thing I noticed is this, after the patch : ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from zfs:tank/freebsd Before the patch, all the "SMP: AP CPU #X Launched!" were correctly displayed, with carriage returns. Yes, I use "options PRINTF_BUFR_SIZE=128". And I don't know if that's related to the patch. Cheers, Olivier > > [test results snipped] > >> All other systems I have are C2D and C2Q-based, but I can't easily test >> on those given their production roles. If there's a particular Intel >> processor family/model you're interested in, let me know and I can dig >> around to see if I have access to one. > > No particular models in mind. > If you have systems with more complex topologies, like multiple physical > packages > or HTT enabled, I will be interested in seeing test results for those. > Thanks again. > -- > Andriy Gapon > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS performance question
2010/8/20 Heinrich Rebehn : > Hi all, > > After setting up our new server (Intel Q9550 CPU, 8GB RAM, 4 x ST31000340NS) > i did a bonnie++ benchmark on the zfs raidz that i created on 4 partitions on > the 4 disks. > > r...@antsrv4 [/data/nocompression] # bonnie++ -u root -d . > Using uid:0, gid:0. > Writing a byte at a time...done > Writing intelligently...done > Rewriting...done > Reading a byte at a time...done > Reading intelligently...done > start 'em...done...done...done...done...done... > Create files in sequential order...done. > Stat files in sequential order...done. > Delete files in sequential order...done. > Create files in random order...done. > Stat files in random order...done. > Delete files in random order...done. > Version 1.96 --Sequential Output-- --Sequential Input- > --Random- > Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec > %CP > antsrv4.ant.uni 16G 94 81 151823 39 100780 27 303 99 239853 30 > 148.3 4 > Latency 4733ms 6051ms 8173ms 37504us 917ms 1030ms > Version 1.96 --Sequential Create-- Random > Create > antsrv4.ant.uni-bre -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > 16 24183 97 + +++ 21715 98 17209 98 + +++ 21291 97 > Latency 19779us 128us 162us 39671us 38us 77us > 1.96,1.96,antsrv4.ant.uni-bremen.de,1,1282303232,16G,,94,81,151823,39,100780,27,303,99,239853,30,148.3,4,16,24183,97,+,+++,21715,98,17209,98,+,+++,21291,97, > > 733ms,6051ms,8173ms,37504us,917ms,1030ms,19779us,128us,162us,39671us,38us,77us > > > I am somewhat concerned about the numbers for per-char-output and > per-char-input. In fact, i have never before seen that low numbers in a > bonnie test. Using a single disk with UFS yields about 6 times as much. > > > I know that this is not crucial for a normal file server, but i want to rule > out any configuration errors. > > Is this normal for ZFS?. Disks are accessed using ahci. I did not attempt any > tuning yet. Can you try without AHCI ? http://www.phoronix.com/scan.php?page=article&item=freebsd_zfs_cam&num=5 > BTW: Running OpenSolaris on the same hardware yields 110306 for > per-char-write and 94698 for per-char-read. > > --Heinrich > > > Heinrich Rebehn > > University of Bremen > Physics / Electrical and Electronics Engineering > - Department of Telecommunications - > > Phone : +49/421/218-62394 > Fax : -3341 > > > > > > _______ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [HEADSUP]: ports feature freeze now in effect
2010/2/15 Steven Friedrich : > On Monday 15 February 2010 12:19:01 pm Erwin Lansing wrote: >> In preparation for 7.3-RELEASE, the ports tree is now in feature freeze. >> >> Normal upgrade, new ports, and changes that only affect other branches >> are allowed without prior approval but with the extra >> Feature safe: yes tag in the commit message. Any commit that is >> sweeping, i.e. touches a large number of ports, infrastructural changes, >> commts to ports with unusually high number of dependent ports, and any >> other commit that requires the rebuilding of many packages is not allowed >> without prior explicit approval from portmgr after that date. >> >> When in doubt, please do not hesitate to contact portmgr. >> >> -erwin >> > I suspect this means we won't get KDE 4.4 for quite some time... http://miwi.bsdcrew.de/2010/02/cft-kde-sc-4-4-0-for-freebsd/ > ___ > freebsd-po...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pack of CAM improvements
2010/1/22 Harald Schmalzbauer : > Alexander Motin schrieb am 19.01.2010 17:12 (localtime): > ... >> >> Patch can be found here: >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> >> Feedback as always welcome. > > Again, thanks a lot for your ongoing great work! > The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't > care. Since r202799 it applies cleanly to 8-STABLE. > Otherwise I couldn't find any problems. > The system detects reinserted SATA drives on ICH9 fine. > > This was tested on a zfs backup server which went to the backbone yesterday, > so I can't physically remove any devices any more for testing... > > But I had some questions about zfs raidz states. I think that isn't a matter > of atacam but if I removed one disk, zpool status still showed me the ada3 > device "online". > After reinserting (and proper detection/initialisazion with cam, ada3 was > present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O > errors. > I coudn't get the device into the pool again, no matter what I tried. > Only rebooting the machine helped. Then I could clean and scrub. > > What are the needed steps to provide a reinsterted hard disk to geom? With > the latest patches I don't need to issue any reset/rescan comman, right? > So it's a zfs problem, right? My mistake in understanding? > > Thanks, > > -Harry > > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS-UP: Shared Library Versions bumped...
2009/7/19 Thomas Backman : > On Jul 19, 2009, at 20:16, Ken Smith wrote: >> >> The problem is that as of the next time you update a machine that had >> been running -current you are best off reinstalling all ports or other >> applications you have on the machine. When you reboot after doing the >> update to the base system everything you have installed will still work >> because the old shared library versions will still be there. However >> anything you build on the machine after its base system gets updated >> would be linked against the newer base system shared libraries but any >> libraries that are part of ports or other applications (e.g. the Xorg >> libraries) would have been linked against the older library versions. >> You really don't want to leave things that way. > > So, to be clear: a fresh ports tree and "portupgrade -af" after building and > installing r195767+ should be enough to solve any problems? (installkernel, > installworld, reboot, portupgrade -af) But there won't be any problem until you do a "make delete-old-libs" in /usr/src/, right ? Olivier > > Regards, > Thomas > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
