7,166
edits
FreeBSD Tips: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
D30041 は MFC。13.1は適用 | D30041 は MFC。13.1は適用 | ||
https://reviews.freebsd.org/D30041 | |||
<syntaxhighlight lang="text" enclose="div"> | |||
mckusick added a comment.May 17 2021, 6:43 PM | |||
I have been working with folks on these two bug reports which I suspect are caused by this problem: | |||
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255473 | |||
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255799 | |||
The problem may be solved by simply having a bigger journal. | |||
The size of the journal should be based on the number of operations that are expected to be done on it in a one-minute period. Unfortunately, tunefs has no direct way to compute this operation count since it knows neither how fast the disk can do transactions nor the capabilities of the system on which it will run. Tunefs is reduced to using the size of the filesystem as an indicator of how big to make the journal. | |||
The journal size ranges from 4Mb (SUJ_MIN) to 32Mb (SUJ_MAX) where the maximum is hit for filesystems of 4Gb and above. The maximum journal size was set more than a decade ago and was based on the number of operations expected to be done in a one-minute period on systems of that era. By my estimates it needs to be about 10x larger to meet that criterion today. | |||
The easiest way to test this theory would be to bump up SUJ_MAX to 350Mb in sys/ufs/ffs/fs.h and then recompile tunefs. Using the recompiled tunefs, disable journaled soft updates, remove the old .sujournal, then reenable journaled soft updates to get a bigger journal. | |||
</syntaxhighlight> | |||