FS hang when creating snapshots on a UFS SU+J setup
I have a RELENG_9 machine that hangs when a snapshot is created on the
root fs (UFS, with SU+J). More accurately, all the processes show a
state of "suspfs" (with ^T) and no fs activity is completed from then
on. A hard reboot (power cycle) was the only way to proceed.
Here's some reference info - let me know what else I should provide.
$uname -a
FreeBSD xxx.xxx.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec
25 05:04:37 UTC 2011 r...@xxx.xxx.net:/usr/obj/usr/src/sys/GENERIC
amd64
csup was run just before build[world|kernel] so you have reference on
the version information.
$mount
/dev/gpt/root on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
linprocfs on /compat/linux/proc (linprocfs, local)
{ zfs info removed }
$df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/root 454G 9.1G 409G 2% /
devfs 1.0k 1.0k 0B 100% /dev
linprocfs 4.0k 4.0k 0B 100% /compat/linux/proc
{ zfs info removed }
After the hard reset, there was a snapshot file listed in /.snap and
it was ~465 GB, iirc. Unfortunately, I needed to get things going
again so I was not able to debug or diagnose further. I may be able
to schedule a time that I could recreate the issue and diagnose
better, but I wanted to get your input on what data points and/or
command you would be interested in.
Thanks in advance,
Bryce
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
atkbc not loaded with ACPI enabled in 9.0
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the functionality I want with one major exception, when I enable ACPI my integrated keyboard drivers aren't loaded. Without ACPI I can use my keyboard as atkbdc and atkbd get loaded, (not psm though), but I have problems with shutdown, time settings, power settings and usb controllers. I have tried various ways of tackling this including: 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and installing >> no effect 2a. including "debug.acpi.disabled="pci" " >> can't mount file system2b. including "debug.acpi.disabled="bus" " >> can't mount file system 2c. including "debug.acpi.disabled="children" " >> can't mount file system2d. including "debug.acpi.disabled="hostres" " >> no effect 3. making the edit in r228961, rebuilding the kernel and installing >> no effect I have the latest bios (v3.x), but it features very few changeable options. Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's the output of my devinfo -ur Any suggestions would be greatly appreciated. Best regards,Adrian Connolly ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
atkbc not loaded with ACPI enabled in 9.0
I am running 9.0-RC3 on an Acer Aspire One D255E netbook. I have most of the functionality I want with one major exception, when I enable ACPI my integrated keyboard drivers aren't loaded. Without ACPI I can use my keyboard as atkbdc and atkbd get loaded, (not psm though), but I have problems with shutdown, time settings, power settings and usb controllers. I have tried various ways of tackling this including: 1. including "nooptions NEW_PCIB" in kernel configuration, rebuilding and installing >> no effect 2a. including "debug.acpi.disabled="pci" " >> can't mount file system2b. including "debug.acpi.disabled="bus" " >> can't mount file system 2c. including "debug.acpi.disabled="children" " >> can't mount file system2d. including "debug.acpi.disabled="hostres" " >> no effect 3. making the edit in r228961, rebuilding the kernel and installing >> no effect I have the latest bios (v3.x), but it features very few changeable options. Here's the output of my dmesg -aHere's the output of my devinfo -vrHere's the output of my devinfo -ur Any suggestions would be greatly appreciated. Best regards,Adrian Connolly ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
On 2 Jan, Don Lewis wrote: > On 2 Jan, Florian Smeets wrote: >> This does not make a difference. I tried on 32K/4K with/without journal >> and on 16K/2K all exhibit the same problem. At some point during the >> cvs2svn conversion the sycer starts to use 100% CPU. The whole process >> hangs at that point sometimes for hours, from time to time it does >> continue doing some work, but really really slow. It's usually between >> revision 21 and 22, when the resulting svn file gets bigger than >> about 11-12Gb. At that point an ls in the target dir hangs in state ufs. >> >> I broke into ddb and ran all commands which i thought could be useful. >> The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt > > Tracing command syncer pid 9 tid 100183 td 0xfe00120e9000 > cpustop_handler() at cpustop_handler+0x2b > ipi_nmi_handler() at ipi_nmi_handler+0x50 > trap() at trap+0x1a8 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0x8082ba43, rsp = 0xff8000270fe0, rbp = > 0xff88c97829a0 --- > _mtx_assert() at _mtx_assert+0x13 > pmap_remove_write() at pmap_remove_write+0x38 > vm_object_page_remove_write() at vm_object_page_remove_write+0x1f > vm_object_page_clean() at vm_object_page_clean+0x14d > vfs_msync() at vfs_msync+0xf1 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff88c9782d00, rbp = 0 --- > > I thinks this explains why the r228838 patch seems to help the problem. > Instead of an application call to msync(), you're getting bitten by the > syncer doing the equivalent. I don't know why the syncer is CPU bound, > though. From my understanding of the patch it only optimizes the I/O. > Without the patch, I would expect that the syncer would just spend a lot > of time waiting on I/O. My guess is that this is actually a vm problem. > There are nested loops in vm_object_page_clean() and > vm_object_page_remove_write(), so you could be doing something that's > causing lots of looping in that code. Does the machine recover if you suspend cvs2svn? I think what is happening is that cvs2svn is continuing to dirty pages while the syncer is trying to sync the file. From my limited understanding of this code, it looks to me like every time cvs2svn dirties a page, it will trigger a call to vm_object_set_writeable_dirty(), which will increment object->generation. Whenever vm_object_page_clean() detects a change in the generation count, it restarts its scan of the pages associated with the object. This is probably not optimal ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 4:03 PM, Kevin Oberman wrote: > On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb < > bzeeb-li...@lists.zabbadoz.net> wrote: > >> Hi, >> >> why do we send all these empty headings for periodic emails or given there >> is >> no output to this one can we >> >> 1) suppress the empty sections (to me that sounds a bit like a wrong >> return code or something maybe?), and >> 2) add an option to suppress "empty" periodic emails entirely? >> >> Sample: >> --- >> Removing stale files from /var/preserve: >> >> Cleaning out old system announcements: >> >> Removing stale files from /var/rwho: >> >> Backup passwd and group files: >> >> Verifying group file syntax: >> /etc/group is fine >> >> Security check: >> (output mailed separately) >> >> Checking for denied zone transfers (AXFR and IXFR): >> >> -- End of daily output -- >> --- >> >> >> I'd also like to get the hostname out of the headings of the security >> emails >> if possible. It's in the Subject:. There's no need to have each section >> header >> starting differently. I understand that it would be a POLA problem given >> a lot >> of people parse these emails automatically so adding an option for that >> would be >> ok with me as well. >> >> Any takers? > > Please don't! The headers with no entries confirm that the check has been > run. > > I really don't care about the hostnames, but the POLA issue makes me > seriously question whther it is worth doing. (Based on followup emails) No one's suggesting that the defaults be changed. We're just trying to make sure that things are made more sane if empty. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > Hi, > > why do we send all these empty headings for periodic emails or given there > is > no output to this one can we > > 1) suppress the empty sections (to me that sounds a bit like a wrong > return code or something maybe?), and > 2) add an option to suppress "empty" periodic emails entirely? > > Sample: > --- > Removing stale files from /var/preserve: > > Cleaning out old system announcements: > > Removing stale files from /var/rwho: > > Backup passwd and group files: > > Verifying group file syntax: > /etc/group is fine > > Security check: > (output mailed separately) > > Checking for denied zone transfers (AXFR and IXFR): > > -- End of daily output -- > --- > > > I'd also like to get the hostname out of the headings of the security > emails > if possible. It's in the Subject:. There's no need to have each section > header > starting differently. I understand that it would be a POLA problem given > a lot > of people parse these emails automatically so adding an option for that > would be > ok with me as well. > > Any takers? > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Please don't! The headers with no entries confirm that the check has been run. I really don't care about the hostnames, but the POLA issue makes me seriously question whther it is worth doing. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 2. Jan 2012, at 23:09 , Doug Barton wrote: > On 01/02/2012 15:01, Bjoern A. Zeeb wrote: >> Looking at periodic(8) it says: >> >> Each script is required to exit with one of the following values: >> >> 0 The script has produced nothing notable in its output. The >> _show_success variable controls the masking of this out- >> put. >> >> 1 The script has produced some notable information in its output. >> The _show_info variable controls the masking of this out- >> put. >> >> 2 The script has produced some warnings due to invalid configuration >> settings. The _show_badconfig variable controls the mask- >> ing of this output. >> >>> 2The script has produced output that must not be masked. >> >> >> Could it even be that if setting the correct "*_show_*" config option >> could do the right thing for me already? I have no clue how that "masking" >> is >> done and in which category "has not produced any output but the heading" >> would fall into and if other things would possibly be hidden as well? > > I'm not sure which problem you're trying to solve. Are you trying to > solve the problem of "scripts that are enabled but don't have any output > other than the header should not output anything at all?" If so, then > yes, then *_show_success="NO" is likely what you're after. > > I assumed from your OP that you were trying to solve a different > problem, but it's starting to seem like I read it wrong. Can you clarify? How did you read it? The follow-up thing is "if the email is empty, don't send it". The problem I have with the description is that "nothing notable" != "nothing" or "nothing but the header" in my view. I read it as "there was output beyond the heading". /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 01/02/2012 15:10, Garrett Cooper wrote: > Looking at the scripts, there are bugs where all of the > beforementioned scripts would always be mute (because rc=0 is > explicitly set at the bottom), unless _show_success was set to YES. Take a look at /etc/defaults/periodic.conf -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 3:09 PM, Doug Barton wrote: > On 01/02/2012 15:01, Bjoern A. Zeeb wrote: >> Looking at periodic(8) it says: >> >> Each script is required to exit with one of the following values: >> >> 0 The script has produced nothing notable in its output. The >> _show_success variable controls the masking of this out- >> put. >> >> 1 The script has produced some notable information in its output. >> The _show_info variable controls the masking of this out- >> put. >> >> 2 The script has produced some warnings due to invalid configuration >> settings. The _show_badconfig variable controls the >> mask- >> ing of this output. >> >> >2 The script has produced output that must not be masked. >> >> >> Could it even be that if setting the correct "*_show_*" config option >> could do the right thing for me already? I have no clue how that "masking" >> is >> done and in which category "has not produced any output but the heading" >> would fall into and if other things would possibly be hidden as well? > > I'm not sure which problem you're trying to solve. Are you trying to > solve the problem of "scripts that are enabled but don't have any output > other than the header should not output anything at all?" If so, then > yes, then *_show_success="NO" is likely what you're after. > > I assumed from your OP that you were trying to solve a different > problem, but it's starting to seem like I read it wrong. Can you clarify? Looking at the scripts, there are bugs where all of the beforementioned scripts would always be mute (because rc=0 is explicitly set at the bottom), unless _show_success was set to YES. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 01/02/2012 15:01, Bjoern A. Zeeb wrote: > Looking at periodic(8) it says: > > Each script is required to exit with one of the following values: > > 0 The script has produced nothing notable in its output. The >_show_success variable controls the masking of this out- >put. > > 1 The script has produced some notable information in its output. >The _show_info variable controls the masking of this out- >put. > > 2 The script has produced some warnings due to invalid configuration >settings. The _show_badconfig variable controls the mask- >ing of this output. > > >2The script has produced output that must not be masked. > > > Could it even be that if setting the correct "*_show_*" config option > could do the right thing for me already? I have no clue how that "masking" is > done and in which category "has not produced any output but the heading" > would fall into and if other things would possibly be hidden as well? I'm not sure which problem you're trying to solve. Are you trying to solve the problem of "scripts that are enabled but don't have any output other than the header should not output anything at all?" If so, then yes, then *_show_success="NO" is likely what you're after. I assumed from your OP that you were trying to solve a different problem, but it's starting to seem like I read it wrong. Can you clarify? Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 2. Jan 2012, at 21:56 , Holger Kipp wrote: > Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" > : > >> why do we send all these empty headings for periodic emails > > It contains the info what has been done, so you know that the jobs have been > performed correctly. If it does not contain the section headings, the jobs > might not have been run at all. > > I like it the way it is... exactly for this reason Yeah, that's why I asked for "knobs". I don't want these daily emails. I am fine if in that case I'll get the weekly summary or something long these lines. I always assume that on error cron or the scripts will spam me anyway. But I don't need the electrons wasted to handle the email, the TLS, and delivery, the storage and the time to skip them every day if they have nothing to say;-) /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 2. Jan 2012, at 22:51 , Doug Barton wrote: > On 01/02/2012 14:49, Garrett Cooper wrote: >> On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: >>> On 01/02/2012 14:14, Garrett Cooper wrote: >>> How does this look for starters? The attached patch's goal is to provide a generic, rc(5)-like infrastructure that would quiet down the periodic emails for 120.clean-preserve . >>> >>> The periodic scripts are badly in need of attention, so effort in that >>> area is much appreciated. >>> >>> Regarding your patch, rather than copying functions from rc.subr, why >>> not just source it? Yes, you will get more than you need, but I think >>> that the virtue of not having to maintain the same code in 2 places far >>> outweighs that minor drawback. >> >>That works too, assuming that rc.subr isn't too rc(5) centric. > > Well of course it's rc-centric, but that's not the point. :) If you're > going to be using the exact same code from rc.subr, you might as well > just source it. The things that you'll get by doing that which are only > relevant to rc you just ignore. > >> Thanks for the feedback! > > Glad to help. While the checkyesno code for sure is great to handle all these options everywhere and doing some serious cleanup sweep. I am all in favour of this. But isn't the real problem here deferring the output of the header depending on the other output or even just the correct exit code? Looking at periodic(8) it says: Each script is required to exit with one of the following values: 0 The script has produced nothing notable in its output. The _show_success variable controls the masking of this out- put. 1 The script has produced some notable information in its output. The _show_info variable controls the masking of this out- put. 2 The script has produced some warnings due to invalid configuration settings. The _show_badconfig variable controls the mask- ing of this output. >2The script has produced output that must not be masked. Could it even be that if setting the correct "*_show_*" config option could do the right thing for me already? I have no clue how that "masking" is done and in which category "has not produced any output but the heading" would fall into and if other things would possibly be hidden as well? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 01/02/2012 14:49, Garrett Cooper wrote: > On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: >> On 01/02/2012 14:14, Garrett Cooper wrote: >> >>> How does this look for starters? The attached patch's goal is to >>> provide a generic, rc(5)-like infrastructure that would quiet down the >>> periodic emails for 120.clean-preserve . >> >> The periodic scripts are badly in need of attention, so effort in that >> area is much appreciated. >> >> Regarding your patch, rather than copying functions from rc.subr, why >> not just source it? Yes, you will get more than you need, but I think >> that the virtue of not having to maintain the same code in 2 places far >> outweighs that minor drawback. > > That works too, assuming that rc.subr isn't too rc(5) centric. Well of course it's rc-centric, but that's not the point. :) If you're going to be using the exact same code from rc.subr, you might as well just source it. The things that you'll get by doing that which are only relevant to rc you just ignore. > Thanks for the feedback! Glad to help. -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton wrote: > On 01/02/2012 14:14, Garrett Cooper wrote: > >> How does this look for starters? The attached patch's goal is to >> provide a generic, rc(5)-like infrastructure that would quiet down the >> periodic emails for 120.clean-preserve . > > The periodic scripts are badly in need of attention, so effort in that > area is much appreciated. > > Regarding your patch, rather than copying functions from rc.subr, why > not just source it? Yes, you will get more than you need, but I think > that the virtue of not having to maintain the same code in 2 places far > outweighs that minor drawback. That works too, assuming that rc.subr isn't too rc(5) centric. Thanks for the feedback! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On 01/02/2012 14:14, Garrett Cooper wrote: > How does this look for starters? The attached patch's goal is to > provide a generic, rc(5)-like infrastructure that would quiet down the > periodic emails for 120.clean-preserve . The periodic scripts are badly in need of attention, so effort in that area is much appreciated. Regarding your patch, rather than copying functions from rc.subr, why not just source it? Yes, you will get more than you need, but I think that the virtue of not having to maintain the same code in 2 places far outweighs that minor drawback. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 1:56 PM, Holger Kipp wrote: > Hi, > > Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" > : > >> why do we send all these empty headings for periodic emails > > It contains the info what has been done, so you know that the jobs have been > performed correctly. If it does not contain the section headings, the jobs > might not have been run at all. > > I like it the way it is... exactly for this reason Perhaps, and that's fine as the default, but the problem is that the periodic scripts aren't completely honoring the _verbose flags assigned to them. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
On Mon, Jan 2, 2012 at 1:29 PM, Bjoern A. Zeeb wrote: > Hi, > > why do we send all these empty headings for periodic emails or given there is > no output to this one can we > > 1) suppress the empty sections (to me that sounds a bit like a wrong > return code or something maybe?), and > 2) add an option to suppress "empty" periodic emails entirely? > > Sample: > --- > Removing stale files from /var/preserve: > > Cleaning out old system announcements: > > Removing stale files from /var/rwho: > > Backup passwd and group files: > > Verifying group file syntax: > /etc/group is fine > > Security check: > (output mailed separately) > > Checking for denied zone transfers (AXFR and IXFR): > > -- End of daily output -- > --- > > > I'd also like to get the hostname out of the headings of the security emails > if possible. It's in the Subject:. There's no need to have each section > header > starting differently. I understand that it would be a POLA problem given a > lot > of people parse these emails automatically so adding an option for that would > be > ok with me as well. > > Any takers? How does this look for starters? The attached patch's goal is to provide a generic, rc(5)-like infrastructure that would quiet down the periodic emails for 120.clean-preserve . Thanks, -Garrett quiet-periodic-mail-noise-v01.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: periodic emails
Hi, Am 02.01.2012 um 22:33 schrieb "Bjoern A. Zeeb" : > why do we send all these empty headings for periodic emails It contains the info what has been done, so you know that the jobs have been performed correctly. If it does not contain the section headings, the jobs might not have been run at all. I like it the way it is... exactly for this reason Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
On Mon, Jan 02, 2012 at 12:47:03PM -0800, Don Lewis wrote: > On 2 Jan, Florian Smeets wrote: > > On 29.12.11 01:04, Kirk McKusick wrote: > >> Rather than changing BKVASIZE, I would try running the cvs2svn > >> conversion on a 16K/2K filesystem and see if that sorts out the > >> problem. If it does, it tells us that doubling the main block > >> size and reducing the number of buffers by half is the problem. > >> If that is the problem, then we will have to increase the KVM > >> allocated to the buffer cache. > >> > > > > This does not make a difference. I tried on 32K/4K with/without journal > > and on 16K/2K all exhibit the same problem. At some point during the > > cvs2svn conversion the sycer starts to use 100% CPU. The whole process > > hangs at that point sometimes for hours, from time to time it does > > continue doing some work, but really really slow. It's usually between > > revision 21 and 22, when the resulting svn file gets bigger than > > about 11-12Gb. At that point an ls in the target dir hangs in state ufs. > > > > I broke into ddb and ran all commands which i thought could be useful. > > The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt > > Tracing command syncer pid 9 tid 100183 td 0xfe00120e9000 > cpustop_handler() at cpustop_handler+0x2b > ipi_nmi_handler() at ipi_nmi_handler+0x50 > trap() at trap+0x1a8 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0x8082ba43, rsp = 0xff8000270fe0, rbp = > 0xff88c97829a0 --- > _mtx_assert() at _mtx_assert+0x13 > pmap_remove_write() at pmap_remove_write+0x38 > vm_object_page_remove_write() at vm_object_page_remove_write+0x1f > vm_object_page_clean() at vm_object_page_clean+0x14d > vfs_msync() at vfs_msync+0xf1 > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff88c9782d00, rbp = 0 --- > > I thinks this explains why the r228838 patch seems to help the problem. > Instead of an application call to msync(), you're getting bitten by the > syncer doing the equivalent. I don't know why the syncer is CPU bound, > though. From my understanding of the patch it only optimizes the I/O. > Without the patch, I would expect that the syncer would just spend a lot > of time waiting on I/O. My guess is that this is actually a vm problem. > There are nested loops in vm_object_page_clean() and > vm_object_page_remove_write(), so you could be doing something that's > causing lots of looping in that code. r228838 allows the system to skip 50-70% of the code when initiating a write of the UFS file page, due to async clustering. The system has to maintain 75% less amount of writes in progress. > I think that ls is hanging because it's stumbling across the vnode that > the syncer has locked. This is the only reasonable explanation. Low-tech profile is to periodically break out into ddb and do backtrace for the syncer thread. More advanced techniques is to use dtrace or normal profiling. pgpqweDffT9HY.pgp Description: PGP signature
periodic emails
Hi, why do we send all these empty headings for periodic emails or given there is no output to this one can we 1) suppress the empty sections (to me that sounds a bit like a wrong return code or something maybe?), and 2) add an option to suppress "empty" periodic emails entirely? Sample: --- Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Security check: (output mailed separately) Checking for denied zone transfers (AXFR and IXFR): -- End of daily output -- --- I'd also like to get the hostname out of the headings of the security emails if possible. It's in the Subject:. There's no need to have each section header starting differently. I understand that it would be a POLA problem given a lot of people parse these emails automatically so adding an option for that would be ok with me as well. Any takers? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
On 2 Jan, Florian Smeets wrote: > On 29.12.11 01:04, Kirk McKusick wrote: >> Rather than changing BKVASIZE, I would try running the cvs2svn >> conversion on a 16K/2K filesystem and see if that sorts out the >> problem. If it does, it tells us that doubling the main block >> size and reducing the number of buffers by half is the problem. >> If that is the problem, then we will have to increase the KVM >> allocated to the buffer cache. >> > > This does not make a difference. I tried on 32K/4K with/without journal > and on 16K/2K all exhibit the same problem. At some point during the > cvs2svn conversion the sycer starts to use 100% CPU. The whole process > hangs at that point sometimes for hours, from time to time it does > continue doing some work, but really really slow. It's usually between > revision 21 and 22, when the resulting svn file gets bigger than > about 11-12Gb. At that point an ls in the target dir hangs in state ufs. > > I broke into ddb and ran all commands which i thought could be useful. > The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt Tracing command syncer pid 9 tid 100183 td 0xfe00120e9000 cpustop_handler() at cpustop_handler+0x2b ipi_nmi_handler() at ipi_nmi_handler+0x50 trap() at trap+0x1a8 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x8082ba43, rsp = 0xff8000270fe0, rbp = 0xff88c97829a0 --- _mtx_assert() at _mtx_assert+0x13 pmap_remove_write() at pmap_remove_write+0x38 vm_object_page_remove_write() at vm_object_page_remove_write+0x1f vm_object_page_clean() at vm_object_page_clean+0x14d vfs_msync() at vfs_msync+0xf1 sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff88c9782d00, rbp = 0 --- I thinks this explains why the r228838 patch seems to help the problem. Instead of an application call to msync(), you're getting bitten by the syncer doing the equivalent. I don't know why the syncer is CPU bound, though. From my understanding of the patch it only optimizes the I/O. Without the patch, I would expect that the syncer would just spend a lot of time waiting on I/O. My guess is that this is actually a vm problem. There are nested loops in vm_object_page_clean() and vm_object_page_remove_write(), so you could be doing something that's causing lots of looping in that code. I think that ls is hanging because it's stumbling across the vnode that the syncer has locked. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
On 29.12.11 01:04, Kirk McKusick wrote: > Rather than changing BKVASIZE, I would try running the cvs2svn > conversion on a 16K/2K filesystem and see if that sorts out the > problem. If it does, it tells us that doubling the main block > size and reducing the number of buffers by half is the problem. > If that is the problem, then we will have to increase the KVM > allocated to the buffer cache. > This does not make a difference. I tried on 32K/4K with/without journal and on 16K/2K all exhibit the same problem. At some point during the cvs2svn conversion the sycer starts to use 100% CPU. The whole process hangs at that point sometimes for hours, from time to time it does continue doing some work, but really really slow. It's usually between revision 21 and 22, when the resulting svn file gets bigger than about 11-12Gb. At that point an ls in the target dir hangs in state ufs. I broke into ddb and ran all commands which i thought could be useful. The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt The machine is still in ddb and i could run any additional commands, the kernel is from Attilio's vmcontention branch, which was MFCed yesterday, and updated after the MFC. The same problem happens on 9.0-RC3. If i run the same test on a zfs filesystem i don't see any problems. Florian signature.asc Description: OpenPGP digital signature
