Re: ZFS regimen: scrub, scrub, scrub and scrub again.
here is my real world production example of users mail as well as documents. /dev/mirror/home1.eli 2788 1545 1243 55% 1941057 20981181 8% /home Not the same data, I imagine. A mix. 90% Mailboxes and user data (documents, pictures), rest are some .tar.gz backups. At other places i have similar situation. one or more gmirror sets, 1-3TB each depends on drives. For those who puts 1000 of mailboxes i recommend dovecot with mdbox storage backend I was dealing with the actual byte counts ... that figure is going to be in whole blocks. ___ 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: IBM blade server abysmal disk write performances
Hi,
Quick follow up on this. As I mentioned in a previous email we have
moved to SATA drives and the SAS drives have been shelved for now. The
current project will be using those so further tests on SAS have been
postponed to an undefined date.
Thanks,
Karim.
PS: I'll keep the SAS tests in my back pocket so I get a head start when
we get around SAS testing again.
On 18/01/2013 6:32 PM, Karim Fodil-Lemelin wrote:
On 18/01/2013 5:42 PM, Matthew Jacob wrote:
This is all turning into a bikeshed discussion. As far as I can tell,
the basic original question was why a *SAS* (not a SATA) drive was
not performing as well as expected based upon experiences with Linux.
I still don't know whether reads or writes were being used for dd.
This morning, I ran a fio test with a single threaded read component
and a multithreaded write component to see if there were differences.
All I had connected to my MPT system were ATA drives (Seagate 500GBs)
and I'm remote now and won't be back until Sunday to put one of my
'good' SAS drives (140 GB Seagates, i.e., real SAS 15K RPM drives,
not fat SATA bs drives).
The numbers were pretty much the same for both FreeBSD and Linux. In
fact, FreeBSD was slightly faster. I won't report the exact numbers
right now, but only mention this as a piece of information that at
least in my case the differences between the OS platform involved is
negligible. This would, at least in my case, rule out issues based
upon different platform access methods and different drivers.
All of this other discussion, about WCE and what not is nice, but for
all intents and purposes it serves could be moved to *-advocacy.
Thanks for the clarifications!
I did mention at some point those were write speeds and reads were
just fine and those were either writes to the filesystem or direct
access (only on SAS again).
Here is what I am planning to do next week when I get the chance:
0) I plan on focusing on the SAS driver tests _only_ since SATA is
working as expected so nothing to report there.
1) Look carefully at how the drives are physically connected. Although
it feels like if the SATA works fine the SAS should also but I'll
check anyway.
2) Boot verbose with boot -v and send the dmesg output. mpt driver
might give us a clue.
3) Run gstat -abc in a loop for the test duration. Although I would
think ctlstat(8) might be more interesting here so I'll run it too for
good measure :).
Please note that in all tests write caching was enabled as I think
this is the default with FBSD 9.1 GENERIC but I'll confirm this with
camcontrol(8).
I've also seen quite a lot of 'quirks' for tagged command queuing in
the source code (/sys/cam/scsi/scps_xtp.c) but a particular one got my
attention (thanks to whomever writes good comments in source code :) :
/*
* Slow when tagged queueing is enabled. Write
performance
* steadily drops off with more and more concurrent
* transactions. Best sequential write performance with
* tagged queueing turned off and write caching turned
on.
*
* PR: kern/10398
* Submitted by: Hideaki Okada hok...@isl.melco.co.jp
* Drive: DCAS-34330 w/ S65A firmware.
*
* The drive with the problem had the S65A firmware
* revision, and has also been reported (by Stephen J.
* Roznowski s...@home.net) for a drive with the S61A
* firmware revision.
*
* Although no one has reported problems with the 2 gig
* version of the DCAS drive, the assumption is that it
* has the same problems as the 4 gig version. Therefore
* this quirk entries disables tagged queueing for all
* DCAS drives.
*/
{ T_DIRECT, SIP_MEDIA_FIXED, IBM, DCAS*, * },
/*quirks*/0, /*mintags*/0, /*maxtags*/0
So I looked at the kern/10398 pr and got some feeling of 'deja vu'
although the original problem was on FreeBSD 3.1 so its most likely
not that but I though I would mention it. The issue described is
awfully familiar. Basically the SAS drive (scsi back then) is slow on
writes but fast on reads with dd. Could be a coincidence or a ghost
from the past who knows...
Cheers,
Karim.
___
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: libprocstat(3): retrieve process command line args and environment
On 24 Jan 2013, at 16:20, John Baldwin wrote: Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is that a goal someday? That is one current consumer of kvm_getargv/envv. That might be fine if we want to make more tools use libprocstat instead of using libkvm directly. I didn't have any plans for ps(1) :-) That is why I wrote about new code. But if you think it is good to do I might look at it one day... I'm mostly hoping Robert chimes in to see if that was his intention for libprocstat. :) If we can ultimately replace all uses of kvm_get*v() with calls to procstat_get*v*() then I'm fine with some code duplication in the interim. Originally there was just proctstat(1), but it made sense to begin re-encapsulating it in a libprocstat(3) because the code there is potentially extremely reusable. This conflicts a bit with libkvm(3), which mysteriously knows about sysctlbyname(3) despite a name suggesting otherwise. You can imagine various approaches to fixing this, but indeed, making libprocstat(3) the first-class citizen and preferring it for both kvm and sysctl methods sounds like the way to go. I actually want to make libprocstat also support snmp, but I've never actually found the time to investigate doing that. One of my main unmet goals for procstat(1) was to introduce an extremely machine-readable output format for it -- e.g., something XML-based or similar. I'd still love to see that happen. Robert ___ 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
Calling ustack(); from DTrace script crashes the user process
I am calling ustack(); from the 'ioctl' handler called by Xorg process. My intention is to see the user stack. On the first few instances I got this error: dtrace: ERROR: open failed: No such file or directory -- no file name is mentioned, double-space is printed in the message After a while the same exact script began to crash Xorg process. Before crashes occurred I was able to get the truss log, showing that multiple dev-files failed to open: 5191: open(/dev/dtrace/dtrace,O_RDONLY,00)= 3 (0x3) 5191: open(/dev/dtrace/io,O_RDONLY,00)ERR#2 'No such file or directory' 5191: open(/dev/dtrace/dtmalloc,O_RDONLY,00) = 4 (0x4) 5191: open(/dev/dtrace/nfscl,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/nfsclient,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/fbt,O_RDONLY,00) = 5 (0x5) 5191: open(/dev/dtrace/lockstat,O_RDONLY,00) = 6 (0x6) 5191: open(/dev/dtrace/priv,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/sched,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/mac,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/mac_framework,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/cbb,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/sctp,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/callout_execute,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/vfs,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/proc,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/syscall,O_RDONLY,00) ERR#2 'No such file or directory' 5191: open(/dev/dtrace/syscall,O_RDONLY,00) ERR#2 'No such file or directory' I satisfied all conditions mentioned in https://wiki.freebsd.org/DTrace on how to run DTrace on 9.0 (I am on 9.1-STABLE). kernel modules are loaded, see below. So: * Why/How ustack kills the user process? (amazing this is even possible) * Why files like /dev/dtrace/io don't exist? Maybe some extra-options are required for ustack() to work? If this is the case this should be mentioned in wiki. Yuri # kldstat Id Refs AddressSize Name 3 16 0x81861000 84c0 opensolaris.ko 44 0x8186a000 53a00linux.ko 101 0x82612000 9e50 linprocfs.ko 121 0x82627000 25b linux_adobe.ko 132 0x82628000 baa dtraceall.ko 141 0x82629000 4eca profile.ko 153 0x8262e000 4005 cyclic.ko 16 12 0x82633000 23baaf dtrace.ko 171 0x8286f000 fae8 systrace_freebsd32.ko 181 0x8287f000 109a5systrace.ko 191 0x8289 45a8 sdt.ko 201 0x82895000 4938 lockstat.ko 211 0x8289a000 be09 fasttrap.ko 221 0x828a6000 65e2 fbt.ko 231 0x828ad000 4ee4 dtnfsclient.ko 241 0x828b2000 1dbebnfsclient.ko 251 0x828d 47da nfs_common.ko 261 0x828d5000 55ec dtnfscl.ko 271 0x828db000 4597 dtmalloc.ko 281 0x828e 44fd dtio.ko 291 0x828e5000 2466 dtrace_test.ko ___ 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: libprocstat(3): retrieve process command line args and environment
On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote: On 24 Jan 2013, at 16:20, John Baldwin wrote: Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is that a goal someday? That is one current consumer of kvm_getargv/envv. That might be fine if we want to make more tools use libprocstat instead of using libkvm directly. I didn't have any plans for ps(1) :-) That is why I wrote about new code. But if you think it is good to do I might look at it one day... I'm mostly hoping Robert chimes in to see if that was his intention for libprocstat. :) If we can ultimately replace all uses of kvm_get*v() with calls to procstat_get*v*() then I'm fine with some code duplication in the interim. Originally there was just proctstat(1), but it made sense to begin re- encapsulating it in a libprocstat(3) because the code there is potentially extremely reusable. This conflicts a bit with libkvm(3), which mysteriously knows about sysctlbyname(3) despite a name suggesting otherwise. You can imagine various approaches to fixing this, but indeed, making libprocstat(3) the first-class citizen and preferring it for both kvm and sysctl methods sounds like the way to go. I actually want to make libprocstat also support snmp, but I've never actually found the time to investigate doing that. One of my main unmet goals for procstat(1) was to introduce an extremely machine- readable output format for it -- e.g., something XML-based or similar. I'd still love to see that happen. BTW, one off-ball thought I have is that I would like to have a mode where libprocstat operates on a core file (of a process, not a kernel crash dump), so it could list the threads from a core dump, and possibly file descriptor info (if PR kern/173723 is implemented). We certainly could have a 'raw' mode where it spat out name: value or XML of the entire kinfo_proc perhaps. -- John Baldwin ___ 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: libprocstat(3): retrieve process command line args and environment
On Fri, 25 Jan 2013 15:31:43 -0500 John Baldwin j...@freebsd.org mentioned: On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote: On 24 Jan 2013, at 16:20, John Baldwin wrote: Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is that a goal someday? That is one current consumer of kvm_getargv/envv. That might be fine if we want to make more tools use libprocstat instead of using libkvm directly. I didn't have any plans for ps(1) :-) That is why I wrote about new code. But if you think it is good to do I might look at it one day... I'm mostly hoping Robert chimes in to see if that was his intention for libprocstat. :) If we can ultimately replace all uses of kvm_get*v() with calls to procstat_get*v*() then I'm fine with some code duplication in the interim. Originally there was just proctstat(1), but it made sense to begin re- encapsulating it in a libprocstat(3) because the code there is potentially extremely reusable. This conflicts a bit with libkvm(3), which mysteriously knows about sysctlbyname(3) despite a name suggesting otherwise. You can imagine various approaches to fixing this, but indeed, making libprocstat(3) the first-class citizen and preferring it for both kvm and sysctl methods sounds like the way to go. I actually want to make libprocstat also support snmp, but I've never actually found the time to investigate doing that. One of my main unmet goals for procstat(1) was to introduce an extremely machine- readable output format for it -- e.g., something XML-based or similar. I'd still love to see that happen. BTW, one off-ball thought I have is that I would like to have a mode where libprocstat operates on a core file (of a process, not a kernel crash dump), so it could list the threads from a core dump, and possibly file descriptor info (if PR kern/173723 is implemented). That's actually a good idea. I was thinking about the same for some time. AFAIK Solaris' pfiles can do that, and maybe some other tools as well. I have not had time to look into yet, though. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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
