Re: ZFS tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Feb 2010 16:56, freebsd@ wrote: On Wed, Feb 17, 2010 at 07:05:11AM +1100, Peter Jeremy wrote: Overall, Barry's script makes an excellent proof-of-concept - which is what he was offering. You know, I had a verbose in-line response typed up, agreeing with some points of yours and disagreeing with others (with perlfaq and other reference material), but decided... fuck it! :-) Lol, (anyway)... To all those involved in this. More up-to-date: arc_summary.pl r182 I have done some more minor formatting with the heading section. I have added some L2 ARC stats. Adjusted called binaries to have full paths for the moment until I get around to fixing it a little more. Not having the full path caused some frustrations with emailing the output while running from cron. If this will be a problem with anyone running it and you come across errors where something can not be executed please be patient as I will have this adjusted soon. arcstat.pl: Please update the WiKi with the missing URL, I uploaded the original FreeBSD modified copy of arcstat.pl script to the same location as arc_summary.pl in case anyone wants to grab that file for FreeBSD while they are their. I have also signed this file with my public key. I won't be making any mods to this script as I see it works as intended. I may be persuaded in the future to make adjustments to keep it working and small bug fixes. http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arcstat.pl MD5 (arc_summary.pl) = 6587be39266bd131ed5f4611f321c9e2 SHA256 (arc_summary.pl) = fea99963562e1caee01d6ccd9af1b592cb18fcfaf81308bd1ee21c546c8290ad SIZE (arc_summary.pl) = 12875 MD5 (arcstat.pl) = 9b7d7b4d52ba997c7c59bc0afaca8aa9 SHA256 (arcstat.pl) = b97fc59460468bb2bab6d53009e67f2de87fd5817e7b5656266ea4fd75079b2a SIZE (arcstat.pl) = 8172 Best regards. And watching for replies, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe6G9AAoJEJBXh4mJ2FR++mYIAJXgJ468WX65PErzYiNySmB/ Sliz5Qur7kpqeP/LHuJHXk/FG+JaaQJQbh/9vIsX2zoqnBK7gqyqTOdv2pw+sKff PNcwdhYbJXEYTnGorj4FXmEI4IkXfuYM281nEpytSVU1CLTnL8oeWU9YRFTw0Fhh Gtvcy2jSnOmjjARt/0Ot1PKfOE9/PTghBTjvmGJIUz11evKsacZmXEIpv1P3KnS9 XMmeDjARkMpXCqDsBPPWeD/YYWUW6SA3Iq+BP0CeVqk7ytQ/q2WI7wH5pC+EscTx dLczky3GR5TeeHrRVQCKWVzQGoxQFH85X2MGipgOae6viHHC+Nk2J1cKVWhLx5s= =zRvh -END PGP SIGNATURE- ___ 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: panic - sleeping thread on FreeBSD 8.0-stable / amd64
Another crash last night. In /var/log/messages: Feb 16 23:13:22 kg-f2 ntpd[2826]: time reset +1.780863 s Feb 16 23:16:42 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:16:42 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 0080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 0080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 0080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 007f Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd = 0080 Feb 16 23:20:39 kg-f2 kernel: ata6: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad6: WARNING - WRITE_DMA requeued due to channel reset LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ata3: FAILURE - already active DMA on this device Feb 16 23:20:39 kg-f2 kernel: ata3: setting up DMA failed Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - READ_DMA retrying (1 retry left) LBA=8389026 Feb 16 23:20:39 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd = 0080 Feb 16 23:20:39 kg-f2 kernel: ata5: hardware reset timeout Feb 16 23:20:39 kg-f2 kernel: ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=65614674 Feb 16 23:20:39 kg-f2 kernel: ad6: TIMEOUT - READ_DMA retrying (0 retries left) LBA=8389026 Feb 16 23:20:39 kg-f2 root: ZFS: vdev I/O failure, zpool=zroot path=/dev/gpt/disk1 offset=29299662848 size=4096 error=5 Feb 17 09:09:40 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel But ad4 and ad6 are the two disk mirrir (zfs) that I have built my root filesystem on. Hmm. -- Torfinn ___ 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: blank X screen with differnt cards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/02/2010 20:05, Christian Schramm wrote: I press Xorg -configure and X -config /root/xorg.conf.new but my CRT Screen is blank. I can switch in tty0 an kill Xorg with CTRL-C. This is actually perfectly normal nowadays. For reasons impenetrable to us poor mortals, the developers of Xorg have decreed that the default shall be that when testing X displays a blank, black screen impossible to distinguish from certain classes of things /going horribly wrong/(tm). If you want the old grey patterned screen, try: # X -config /root/xorg.conf -retro It's all documented in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt7prAACgkQ8Mjk52CukIwNHgCggXJOsPnYCxrk8NzYpTaYHhtL 0HYAn2CrOYCEQpaVO4QA/9uftqDhCWZt =Pven -END PGP SIGNATURE- ___ 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 tuning [was: hardware for home use large storage]
On 2010-02-17 08:58, jhell wrote: To all those involved in this. More up-to-date: arc_summary.pl r182 Best regards. And watching for replies, So here's my reply (last line seems most interesting ;) : # ./arc_summary.pl - System Summary śro 17 lut 2010 08:16:37 UTC FreeBSD 9.0-CURRENT #20: Fri Feb 12 19:21:34 CET 2010 ncpnc Kernel Version: 99 (osreldate) Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 14 Filesystem Version: 3 Physical RAM: 1523.41 MiB Kernel Memory Usage TEXT: 9782828, 9.33 MiB DATA: 216801280, 206.76 MiB TOTAL: 226584108, 216.09 MiB 9:16 up 4 days, 6:54, 1 user, load averages: 0,47 0,92 0,59 - ARC Summary Meta Limit: 120.00 MiB Meta Used: 135.00% 162.00 MiB Throttle Count: 0 ARC Size: Current Size: 190.03 MiB (arcsize) Target Size (Adaptive): 209.12 MiB (c) Min Size (Hard Limit): 60.00 MiB (arc_min) Max Size (Hard Limit): 480.00 MiB (arc_max) ARC Size Breakdown: Recently Used Cache Size: 16.00% 33.46 MiB (p) Frequently Used Cache Size: 84.00% 175.66 MiB (c-p) ARC Efficiency: Cache Access Total: 28459411 Cache Hit Ratio: 94.57% 26913166 Cache Miss Ratio: 5.43% 1546245 Actual Hit Ratio: 81.81% 23282481 Data Demand Efficiency: 99.48% Data Prefetch Efficiency: 54.15% CACHE HITS BY CACHE LIST: Anonymous: 11.07% 2978474 Most Recently Used: 16.42% 4419712 (mru) Most Frequently Used: 70.09% 18862769 (mfu) Most Recently Used Ghost: 0.98% 264205 (mru_ghost) Most Frequently Used Ghost: 1.44% 388006 (mfu_ghost) CACHE HITS BY DATA TYPE: Demand Data: 53.58% 14419664 Prefetch Data: 0.07% 20017 Demand Metadata: 32.68% 8794182 Prefetch Metadata: 13.67% 3679303 CACHE MISSES BY DATA TYPE: Demand Data: 4.88% 75410 Prefetch Data: 1.10% 16946 Demand Metadata: 59.18% 915133 Prefetch Metadata: 34.84% 538756 L2 ARC Summary Low Memory Aborts: 0 Bad Checksums: 0 IO Errors: 0 L2 ARC Size: Current Size: 0.00 MiB Header Size: 0.00 MiB L2 ARC Breakdown: L2 Access Total: 0 Illegal division by zero at ./arc_summary.pl line 242. -- Bartosz Stec ___ 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 tuning [was: hardware for home use large storage]
On Wed, 17 Feb 2010 09:19:49 +0100 Bartosz Stec bartosz.s...@it4pro.pl wrote: So here's my reply (last line seems most interesting ;) : [...snipped...] Illegal division by zero at ./arc_summary.pl line 242. FWIW, I also got this line when I ran this script on my idle zfs server. -- Torfinn ___ 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 tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 12:06, bp@ wrote:
On 2/15/10 7:49 PM, jhell wrote:
As I make final modifications to the script I will keep the below URLs
updated and welcome any bug reports or modification requests to me
personally.
Here is the URLs:
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Nice. How about including relevant lines from /boot/loader.conf, maybe
something like this tacked on the end of the script (excuse my Perl, I'm a
Python guy).
Loader Settings #
open(LOADER, '/boot/loader.conf');
print \n/boot/loader.conf settings:\n;
while (LOADER){
chomp;
if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
print \t$_\n;
}
}
Yes, it should more or less duplicate the sysctl values, but it may make it
more obvious where the settings are coming from, or if the user has bad or
ignored settings
Barry
Hi Barry,
This is a very nice idea so please do not get me wrong when I say
that I would rather stay away from having to open config files and start
comparing results. I don't feel that this is in the place of the script to
do this type of action and can lead to confusion upon the users behalf.
sysctl(8) is by far better off getting the values from a running system
rather than parsing values obtained from a file that does not change the
system except for after a reboot upon which the values outlined in
loader.conf can be obtained from sysctl mibs.
The latest version of the script that I have uploaded has the sysctl mibs
spilled out at the bottom. These are mibs that I felt were relevent to the
tuning of ZFS and FreeBSD obtained from various sources and memory recall
so I might have missed a few so if you or anyone else has a mib to be
added please forward them to me in a email and I will be sure to add it.
Regards, and thanks for the feedback.
--
jhell
___
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: blank X screen with differnt cards
On Tue, 16 Feb 2010 21:05:13 +0100 Christian Schramm christian.schr...@parative.org wrote: Hi at first this is my first message to a mailing list. Second sorry for my bad english. On Saturday i have installed 8-0-Release, after I build 8-stable include world an d kernel. After the build of stable I build some ports also xorg-minimal I press Xorg -configure and X -config /root/xorg.conf.new but my CRT Screen is blank. I can switch in tty0 an kill Xorg with CTRL-C. Take a look at this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html The next step is to test the existing configuration to verify that Xorg can work with the graphics hardware on the target system. In Xorg versions up to 7.3, type: # Xorg -config xorg.conf.new Starting with Xorg 7.4 and above, this test produces a black screen which may make it difficult to diagnose whether X11 is working properly. The older behavior is still available by using the retro option: # Xorg -config xorg.conf.new -retro Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 pgpRQWcnqXGD6.pgp Description: PGP signature
Re: ZFS tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 12:59, freebsd@ wrote:
On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote:
On 2/15/10 7:49 PM, jhell wrote:
As I make final modifications to the script I will keep the below URLs
updated and welcome any bug reports or modification requests to me
personally.
Here is the URLs:
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Nice. How about including relevant lines from /boot/loader.conf,
maybe something like this tacked on the end of the script (excuse my
Perl, I'm a Python guy).
Loader Settings #
open(LOADER, '/boot/loader.conf');
print \n/boot/loader.conf settings:\n;
while (LOADER){
chomp;
if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
print \t$_\n;
}
}
Yes, it should more or less duplicate the sysctl values, but it may
make it more obvious where the settings are coming from, or if the
user has bad or ignored settings
Major problems with the above code:
1) Opens /boot/loader.conf for rw access; should be read-only
2) Makes the assumption /boot/loader.conf exists
3) Does not close the fd
4) Excessively quotes variables for no justified reason
5) Makes some bad assumptions about the contents of the file (ex.
comments with the word zfs in them would match)
The code should really be something like what's below. This should
be much more manageable as well (@tunables that is), although I always
worry when using grep()...
Very nice!,
Ill keep this for reference later on. This might just come in handy at
some point.
But for the sake of arc_summary.pl I feel this is beyond the scope of what
its intended use is. See previous email in response to Barry.
Thanks Jeremy
--
jhell
___
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 tuning [was: hardware for home use large storage]
On 2010-02-17 09:32, Torfinn Ingolfsen wrote: On Wed, 17 Feb 2010 09:19:49 +0100 Bartosz Stecbartosz.s...@it4pro.pl wrote: So here's my reply (last line seems most interesting ;) : [...snipped...] Illegal division by zero at ./arc_summary.pl line 242. FWIW, I also got this line when I ran this script on my idle zfs server. I'm not a PERL programmer (or programmer at all ;), but what I see is script doesn't check if L2ARC is used at all, so it will always try compute these lines: printf(\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_hits / ( $l2_hits + $l2_misses )), $l2_hits ); printf(\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_misses / ( $l2_hits + $l2_misses )), $l2_misses ); printf(\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_feeds / ( $l2_hits + $l2_misses )), $l2_feeds ); Without active L2ARC it will always generate divide at zeo error, so it seems that additional check for usable L2ARC values is needed at first place. -- Bartosz Stec ___ 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
devd hang after upgrade to 8.0-STABLE
Just wondering if others have seen this too. Yesterday, after upgrading from 7.2-stable to 8.0-stable, my server would hang on startup on the Starting devd line. bootverbose did not get me any more information, and I had to manually hit ^C or ^\ to continue booting. Also, the reboot command will hang after killing syslogd. Only a reboot -q will actually reboot the system. Now, I've disabled devd in rc.conf, but this is not an ideal configuration for me. Any hints on how to further debug this? cheers, Ruben ___ 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 tuning [was: hardware for home use large storage]
On Wed, Feb 17, 2010 at 2:56 AM, Bartosz Stec bartosz.s...@it4pro.pl wrote: On 2010-02-17 09:32, Torfinn Ingolfsen wrote: On Wed, 17 Feb 2010 09:19:49 +0100 Bartosz Stecbartosz.s...@it4pro.pl wrote: So here's my reply (last line seems most interesting ;) : [...snipped...] Illegal division by zero at ./arc_summary.pl line 242. FWIW, I also got this line when I ran this script on my idle zfs server. I'm not a PERL programmer (or programmer at all ;), but what I see is script doesn't check if L2ARC is used at all, so it will always try compute these lines: printf(\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_hits / ( $l2_hits + $l2_misses )), $l2_hits ); printf(\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_misses / ( $l2_hits + $l2_misses )), $l2_misses ); printf(\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_feeds / ( $l2_hits + $l2_misses )), $l2_feeds ); Without active L2ARC it will always generate divide at zeo error, so it seems that additional check for usable L2ARC values is needed at first place. The attached patch fixes the divide by zero errors. Scot patch1 Description: Binary data ___ 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 13/02/2010 00:23, George Mamalakis wrote: On 12/2/2010 8:48 πμ, jhell wrote: This is a lot of information to consume. Lets start with this: All of the machines in question are of some form of FreeBSD 8. You enter gdb and very clearly it starts whining about a segfault libc.so.7 Did you happen to upgrade these clients server from FreeBSD 7 ? AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 If you upgraded and from source did you run make delete-old and make delete-old-libs after your make install and after your mergemaster ? Will wait here for results. Best wishes. Guys(?!), anybody having taken a look at the issue or has an opinion/workaround whatsoever? Thanks again. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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 tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Feb 2010 04:53, jhell@ wrote: PGP Command Output gpg: Signature made Wed Feb 17 04:53:27 2010 EST using RSA key ID 89D8547E gpg: Good signature from jhell jh...@dataix.net --- Begin PGP Signed Message Verified 2010-02-17 06:13:53 -- On Wed, 17 Feb 2010 03:56, bartosz.stec@ wrote: On 2010-02-17 09:32, Torfinn Ingolfsen wrote: On Wed, 17 Feb 2010 09:19:49 +0100 Bartosz Stecbartosz.s...@it4pro.pl wrote: So here's my reply (last line seems most interesting ;) : [...snipped...] Illegal division by zero at ./arc_summary.pl line 242. FWIW, I also got this line when I ran this script on my idle zfs server. I'm not a PERL programmer (or programmer at all ;), but what I see is script doesn't check if L2ARC is used at all, so it will always try compute these lines: printf(\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_hits / ( $l2_hits + $l2_misses )), $l2_hits ); printf(\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_misses / ( $l2_hits + $l2_misses )), $l2_misses ); printf(\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n, 100 * ( $l2_feeds / ( $l2_hits + $l2_misses )), $l2_feeds ); Without active L2ARC it will always generate divide at zeo error, so it seems that additional check for usable L2ARC values is needed at first place. Thanks for reporting this. As I am usually on a system that is using a L2ARC I wouldn't have noticed it. I should have this fixed in about 10 hours. But as I am writing this email I am heading off to bed, work calls in the morning. Check back tomorrow night for a updated version and adjust the current to your liking for the moment. ;) Thanks again. -- jhell End PGP Signed Message Verified 2010-02-17 06:13:53 --- I take that back. I just uploaded a modified version that I wrapped with a if statement to check and see if l2_hits = 0. If you don't have a L2ARC you will now get a message explaining why its not included in your summary. I couldn't sleep until I fixed this knowing that more people are probably going to come across this problem and email back. New rev: 184 MD5 (arc_summary.pl) = f47bac165e7bf707d5f81cfdd007c30a SHA256 (arc_summary.pl) = 794dce069ff649598d99204b362d141a19da47dcf60ec165b260d55a5c9d493f SIZE (arc_summary.pl) = 12695 http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arc_summary.pl.asc Now I can finally sleep ;) - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe9BrAAoJEJBXh4mJ2FR+0K8IAKA43hk95Kll9mLfMWj5bUPp ZLlDzZPPy30Ign6wfbSO0wImLW0UVa9wAL0EwWb78F9T/3AJ2fQZFgWrOp/t+eV4 iKG8rsEy6t6YDYYZ7G6XnSibiCO+M+L+b6eSWMbcl/Ak8n+1PZUQisFevq/K0cCu 31ktjNxC6eqK1s0rKn/CgyXKO/rga60U12OHG9SLInM8J1dtHSGAp6kBO0B6C9+m uzEKOkUxXlYZpo+vlR9alByPWfiG9JqkgiYcOeXcgo0kb405cVT5jwBrOY9UnTb8 phxY6RXUViGP/quX2P+tGIYO47gDvBiGY/XRyTO1bmM+O0nPTnnKHpJg9NBvZ/g= =OFDn -END PGP SIGNATURE- ___ 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 tuning [was: hardware for home use large storage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to the nature of this thread and its current list involvement I am going to be starting a new thread in freebsd-filesystems@ just for arc_summary.pl tomorrow night with the subject below. [arc_summary.pl] Adjustments, PR Requests I would appreciate if you would join me there for any response or problems that may arise for the use of this script. I don't feel that this list is any longer the correct place to hold this discussion as it is more ZFS centric than stable@ was meant for. If someone would like to start the subject off before I get to it please feel free. Thanks in advance. - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLe9OTAAoJEJBXh4mJ2FR+LdwH/0cCwnsWogtHfGyU4PJcu1fG PV/PxpgMKQsTIfckGI8ef/UPCG7lki6FD9+bPrsOrFy2ZuvGhK+jfxXsa+99Rt4h ovi6qopLjfHde9Ztd87E3Ds88kR0KEszdnDvbg7mr/xAz9V7hFrLWvmIqxaedg06 I+j932tUfFmA2xiExBWVjtHfdYD2YaO671SET0nPSGz0b6yRlfedOvTZvheI+l05 fB1pXQNwve1en6oDtBBb0pgoODI9HgrZyrQbJzTFH/hXremdO5Dv5AUULI/XKwNA KSSWRMRKYODdX7cDIDbS2+7GjLj1V85gdBc10usR4AqpSFl8aGmTIUfK187y+qs= =7QZB -END PGP SIGNATURE- ___ 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: ntpd struggling to keep up - how to fix?
On Fri, 12 Feb 2010 17:44:52 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: On Fri, 12 Feb 2010 05:11:17 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote: Please try doing this: - stop ntpd - rm /var/db/ntpd.drift - sysctl kern.timecounter.hardware=ACPI-safe - start ntpd Thanks, I'm currently testing that. Results in 72 hours (or less) :-) Well, using ACPI-safe only get a small improvement, here are the lines from /var/log/messages: Feb 17 17:16:47 kg-f2 ntpd[912]: time reset +1.785920 s Feb 17 17:32:39 kg-f2 ntpd[912]: time reset +1.836376 s Feb 17 17:48:18 kg-f2 ntpd[912]: time reset +1.811593 s Feb 17 18:04:12 kg-f2 ntpd[912]: time reset +1.840545 s Feb 17 18:19:19 kg-f2 ntpd[912]: time reset +1.751837 s Feb 17 18:35:19 kg-f2 ntpd[912]: time reset +1.852328 s Feb 17 18:51:18 kg-f2 ntpd[912]: time reset +1.850928 s Feb 17 19:06:50 kg-f2 ntpd[912]: time reset +1.798706 s Feb 17 19:22:35 kg-f2 ntpd[912]: time reset +1.823697 s Feb 17 19:37:56 kg-f2 ntpd[912]: time reset +1.777376 s Unfortunately, it isn't enough to keep the machine in sync all the time. But it is better than HPET so I'll keep it. -- Torfinn ___ 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: best practice to watch TCP parms of established sockets
Hi-- On Feb 17, 2010, at 8:03 AM, Harald Schmalzbauer wrote: while doing some ZFS tests with RELENG_8 I recognized a mysterious performace drop after an hour uptime. Now my first idea is to compare MSS and windows sizes before and after the performance drop. How do I best capture them? tdpcump? It's GbE linkspeed... It seems more likely that ZFS is running into slowdowns from resource contention, memory fragmentation, etc than your network would suddenly drop out, but tcpdump -w outfile.pcap is a good method of looking Regards, -- -Chuck ___ 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: ntpd struggling to keep up - how to fix?
On Wed, 17 Feb 2010 19:49:27 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Unfortunately, it isn't enough to keep the machine in sync all the time. But it is better than HPET so I'll keep it. This thread is interesting: http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html Is there a way in FreeBSD to perform adjustmenst like adjtimex? 'apropos adjtime' only gives me a system call, the man pages for hz(9) and hardclock(9) doesn't exist on 8.0-stable (or on 7.2-stable). -- Torfinn ___ 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: best practice to watch TCP parms of established sockets
Am 17.02.2010 19:56, schrieb Chuck Swiger: Hi-- On Feb 17, 2010, at 8:03 AM, Harald Schmalzbauer wrote: while doing some ZFS tests with RELENG_8 I recognized a mysterious performace drop after an hour uptime. Now my first idea is to compare MSS and windows sizes before and after the performance drop. How do I best capture them? tdpcump? It's GbE linkspeed... It seems more likely that ZFS is running into slowdowns from resource contention, memory fragmentation, etc than your network would suddenly drop out, but tcpdump -w outfile.pcap is a good method of looking Thanks, but fisrt tests showed that ZFS is not causing the slowdown. I noticed that disabling window scaling (rfc1323) speeds up the transfer rate by factor 1.5 (rsync transfers start at 75MB/s, settling down at 55MB/s, while rfc1323 enabled leads to half the windows size (8k) and rsync transfers start with 50MB/s and go down to 38MB/s). Now I'm going through internet core protocols becaus it's been a long time ago I had such a deep look into TCP/IP and I don't have all the TCP sequences and options in memory. Not falsified yet, but as soon as I open a second high data rate transfer, simultanious to the rsync, (a smb transfer of a large file for example) the shared speed will stay at that level, even if the second transfer has finbished. Meaning: I can rsync with 50MB/s. If I simultaniously transfer another file via samba, I have two 25MB/s transfers. From that moment on I can never get more that 25MB/s per transfer until I reboot the machine. Like mentioned eralier, I first have to refresh some networking basics, but expect some more results soon. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: netboot issues, 8.0, mfsroot mount failure
On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote: Footnote: This is why I tell folks to zero out the first 8192 bytes of any disk they've previously installed FreeBSD on (even if the disk has no filesystems/slices on it). The way FreeBSD determines the size of the disk differs in RELENG_8; I believe GEOM figures it out on its own now, while previous releases relied on the c slice. The method I've recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. Is it also advisable to blot out any old glabel stuff at the end of the disk? What's the math to get that? Get a sector count for the whole disk, set bs to 512 and skip to (sector count - 1)? I don't think the glabel data (which goes at the end of the disk) is relevant to the above problem I described. You can erase it if you want, but I doubt it's responsible for warnings like Disk geometry does not match label! or situations where a user is re-using a disk (that had its slices created on RELENG_7) on RELENG_8 and experiences problems. An alternative to the dd method might be to try gpart destroy; I haven't tried to see if relieves the problem. As far as how to erase the glabel metadata -- glabel clear is supposed to do this for you. What I don't know is whether or not addition of a glabel decreases what GEOM thinks the total size of the disk is, so I can't say for certain doing some math + zeroing the last sector of the disk would actually work. -- | 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
Re: ntpd struggling to keep up - how to fix?
On Wed, Feb 17, 2010 at 08:03:22PM +0100, Torfinn Ingolfsen wrote: On Wed, 17 Feb 2010 19:49:27 +0100 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Unfortunately, it isn't enough to keep the machine in sync all the time. But it is better than HPET so I'll keep it. This thread is interesting: http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/01356.html Is there a way in FreeBSD to perform adjustmenst like adjtimex? 'apropos adjtime' only gives me a system call, the man pages for hz(9) and hardclock(9) doesn't exist on 8.0-stable (or on 7.2-stable). You can set the timecounter frequency with sysctl. On my one time server I have these lines in /etc/sysctl.conf machdep.tsc_freq=132658584 kern.timecounter.hardware=TSC John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ 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 compile failure
On Monday 15 February 2010 8:55:13 am Larry Rosenman wrote: For the record, it appears that cvsup17.us.freebsd.org is serving outdated files. Try sending an e-mail to h...@. The last time cvsup17 had issues the owner fixed them after seeing an e-mail to h...@. -- John Baldwin ___ 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 compile failure
Already done on Monday at 08:12am US/Central (GMT-6). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Wednesday, February 17, 2010 3:42 PM To: freebsd-stable@freebsd.org Cc: Larry Rosenman; 'Alexander Motin'; 'Jeremy Chadwick' Subject: Re: kernel compile failure On Monday 15 February 2010 8:55:13 am Larry Rosenman wrote: For the record, it appears that cvsup17.us.freebsd.org is serving outdated files. Try sending an e-mail to h...@. The last time cvsup17 had issues the owner fixed them after seeing an e-mail to h...@. -- John Baldwin ___ 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: netboot issues, 8.0, mfsroot mount failure
On Thu, Feb 18, 2010 at 6:22 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote: Footnote: This is why I tell folks to zero out the first 8192 bytes of any disk they've previously installed FreeBSD on (even if the disk has no filesystems/slices on it). The way FreeBSD determines the size of the disk differs in RELENG_8; I believe GEOM figures it out on its own now, while previous releases relied on the c slice. The method I've recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. Is it also advisable to blot out any old glabel stuff at the end of the disk? What's the math to get that? Get a sector count for the whole disk, set bs to 512 and skip to (sector count - 1)? I don't think the glabel data (which goes at the end of the disk) is relevant to the above problem I described. You can erase it if you want, but I doubt it's responsible for warnings like Disk geometry does not match label! or situations where a user is re-using a disk (that had its slices created on RELENG_7) on RELENG_8 and experiences problems. An alternative to the dd method might be to try gpart destroy; I haven't tried to see if relieves the problem. As far as how to erase the glabel metadata -- glabel clear is supposed to do this for you. What I don't know is whether or not addition of a glabel decreases what GEOM thinks the total size of the disk is, so I can't say for certain doing some math + zeroing the last sector of the disk would actually work. I have recently been using the following snippet in an install script to zero out any existing gmirror/etc metadata before the install proceeds (and potentially reconfigures a new gmirror etc): # Specify the disk device to clear diskdev=da0 # Clear metadata from the last sector on the drive echo Clearing any GEOM metadata on drive... diskinfo=`diskinfo /dev/$diskdev` sector_size=`echo $diskinfo | cut -f2 -d\ ` size_in_sectors=`echo $diskinfo | cut -f4 -d\ ` geom_offset=$(($size_in_sectors-1)) dd if=/dev/zero of=/dev/$diskdev bs=$sector_size oseek=$geom_offset count=1 2 /dev/null In preliminary testing it seems to do the job... -- Antony ___ 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
