Summary: | gjournal: kernel: panic: Journal overflow | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Paul <spy> | ||||||
Component: | kern | Assignee: | freebsd-geom (Nobody) <geom> | ||||||
Status: | Open --- | ||||||||
Severity: | Affects Some People | CC: | fs, lwhsu, yyv83 | ||||||
Priority: | --- | Keywords: | crash, needs-qa | ||||||
Version: | 12.1-RELEASE | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Paul
2020-03-09 00:36:03 UTC
(In reply to Paul from comment #0) sorry, but it seems I was hastened to conclusions. right now, have caught a reboot with vfs.write_behind=1 @Paul Could you provide additional information including: - /var/run/dmesg.boot output (as an attachment) - pciconf -lv output as an attachment Also, - So you see any panic messages on screen prior to the reboot? You can try setting kern.panic_reboot_wait_time=-1 as a sysctl or loader tunable - Are there any relevant error messages in dmesg or /var/log/messages you can include? You can also try debug.debugger_on_panic=1 if not already set Created attachment 212271 [details]
dmesg output
Created attachment 212272 [details]
`pciconf -lv` oputput
(In reply to Kubilay Kocak from comment #2) Sorry, but I have no access to console. It is remote server. Usually, there are no messages in /var/log/messages Only twice I've found a message like this: Mar 9 01:44:12 test kernel: panic: Journal overflow (id = 617901877 joffset=450395648 active=260258304 inactive=447780864) with vfs.write_behind=1 it seems work mostly ok, but I reproduce a crash easy, just when I try to overwrite the same file: cp /src/60gb /dst/ # done ok cp /src/60gb /dst/ # rebooted after 5 seconds And... I tried to reproduce this case with the same file, but using nvme disk of same size with gjournal log of the same size as destination. with vfs.write_behind=1 I repeated `cp /src/60gb /fast/` several times, and all is ok. but with vfs.write_behind=0, it works more stable, but at least once I've seen a reboot. Good afternoon. I also faced a similar problem. Dealing with this question, I considered the following directives of the kernel: kern.geom.journal.cache.limit kern.geom.journal.switch_time Fact is that variable "kern.geom.journal.cache.limit" sets size of buffer for logging, and it seems that default size is very large. Second Directive is "kern.geom.journal.switch_time" specifies frequency at which the journal will be switched. I tried to disable this option altogether, because the log switching is also controlled by parameter "kern.geom.parameter.journal.force_switch" As a result I use following values of the directives described above: kern.geom.journal.cache.limit=134217728 kern.geom.journal.switch_time=0 |