Re: zfs: ru_inblock/ru_oublock accounting

2010-10-08 Thread Andriy Gapon
on 07/10/2010 20:33 Andriy Gapon said the following: > > A simple, probably incomplete and perhaps incorrect patch for > ru_inblock/ru_oublock accounting in zfs: > http://people.freebsd.org/~avg/zfs-ru.diff I've updated the patch at the same location. Thanks to "swell.k" for pointing out that the

[HEADSUP] changes to cam_get_device() and cam_open_device()

2010-10-08 Thread Andriy Gapon
As there was no objections, I am going to commit changes to cam_get_device() that remove the following features: - ignoring 'r' and 'n' at the start of device name - ignoring whitespace at end of device name - parsing and ignoring slice and partition names in a device name cam(3) manual page is

Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.

2010-10-08 Thread Daniel Gerzo
On 7.10.2010 15:42, Warren Block wrote: Consider also the docs that tell the user to echo 'something_enable="YES"' >> /etc/rc.conf which can produce duplicate and possibly differing entries. Or non-working entries if there was no ending \n present, or even a broken like forgetting to add two '

Re: Fix mfiutil compile with -DDEBUG

2010-10-08 Thread John Baldwin
On Sunday, October 03, 2010 10:33:17 pm Garrett Cooper wrote: > make -DDEBUG is broken in mfiutil: > > $ make -DDEBUG > cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona > -fno-builtin-strftime -DDEBUG -Wall -Wcast-align -Woverflow > -Wsign-compare -Wunused -std=gnu99 -fstack-protector

Re: panic_cpu should be volatile

2010-10-08 Thread John Baldwin
On Thursday, October 07, 2010 1:40:49 pm Andriy Gapon wrote: > > panic_cpu variable in kern_shutdown.c should be volatile otherwise it's > cached in > a register in the innermost while-loop in this code (observed on amd64 with > base > gcc and -O2): > if (panic_cpu != PCPU_GET(cpuid)) >

Re: Make mfiutil(8) more robust

2010-10-08 Thread John Baldwin
On Sunday, October 03, 2010 11:32:01 pm Garrett Cooper wrote: > On Sun, Oct 3, 2010 at 8:30 PM, Garrett Cooper wrote: > >As discussed offlist with some of the Yahoo! FreeBSD folks, > > mfiutil catches errors, but doesn't communicate it back up to the > > executing process. Examples follow... >