Freebsd 11.0 - system freeze on intensive I/O
Mark Millard
markmi at dsl-only.net
Wed Aug 9 14:13:57 UTC 2017
On 2017-Aug-9, at 6:45 AM, Gleb Popov <6yearold at gmail.com> wrote:
> On Wed, Aug 9, 2017 at 12:52 PM, Eugene Grosbein <eugen at grosbein.net> wrote:
>
>> 09.08.2017 14:11, Gautam пишет:
>>> Hi,
>>>
>>> I raised this topic on freebsd-questions where I suspect a bug caused due
>>> to swapfile usage on FreeBSD.
>>>
>>> You could read details in the below thread, but summary is that with
>> using
>>> a swapfile (not a swap partition) the system freezes on some single
>> process
>>> intensive I/O. This is 100% reproducible.
>>>
>>> http://marc.info/?l=freebsd-questions&m=150088763825675&w=2
>>>
>>> I raised a PR - 220971 ; but there are no backtraces / logs etc. that
>> could
>>> possibly help.
>>>
>>> I would like to help narrow this down, but do not know how. Any
>> suggestions
>>> on how to debug a system freeze and what I need to do ? I could then try
>> to
>>> reproduce this and collect the needed information - traces etc.
>>
>> Swapfile is definitely broken in supported FreeBSD releases, it hangs the
>> system.
>> The only known workaround (to me) is not using it.
>
> I'm using swap on ZFS, and still see the problem, so this might not be tied
> to swapfile.
Swap files on ZFS are also known to have the problem.
Quoting bugzilla 206048's comment #7 (which is quoting an older
list message):
On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com> wrote
on the freebsd-arm list:
. . .
swapfile write requires the write request to come through the filesystem
write path, which might require the filesystem to allocate more memory
and read some data. E.g. it is known that any ZFS write request
allocates memory, and that write request on large UFS file might require
allocating and reading an indirect block buffer to find the block number
of the written block, if the indirect block was not yet read.
As result, swapfile swapping is more prone to the trivial and unavoidable
deadlocks where the pagedaemon thread, which produces free memory, needs
more free memory to make a progress. Swap write on the raw partition over
simple partitioning scheme directly over HBA are usually safe, while e.g.
zfs over geli over umass is the worst construction.
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-hackers
mailing list