From nobody Sat Jan 04 18:47:16 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YQTvW4pKYz5j8rP for ; Sat, 04 Jan 2025 18:47:19 +0000 (UTC) (envelope-from SRS0=Nfm9=T4=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YQTvW2Kr1z45B4 for ; Sat, 4 Jan 2025 18:47:19 +0000 (UTC) (envelope-from SRS0=Nfm9=T4=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 905A0D7889; Sat, 4 Jan 2025 19:47:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1736016437; bh=tBlKlSArzVtChaA+bHumvr8D3Z1PAqC7j0lInHhEYiA=; h=Date:Subject:To:References:From:In-Reply-To; b=dS40MKUWrlKUtiEVVopdxmsTo74CrMLpoF2UQ22SDxodOzSfncNp4oA2BuIJNTAcg sutiaVYkdIhBjFX+/RyD1Thf+EMnd5JxnAH4hJFIL0jG0cRvK24WVSq7Mzu1f7aPzX UPbCR0giG6eOs01MdeETFTbBXAlz8gErDkr2mi/o= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B1F91D7884; Sat, 4 Jan 2025 19:47:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1736016436; bh=tBlKlSArzVtChaA+bHumvr8D3Z1PAqC7j0lInHhEYiA=; h=Date:Subject:To:References:From:In-Reply-To; b=h5Bf6znlOvqPKdV3juNl8fM4Bfh9/0N/3nlj3XXJ6F7auQGZCJCbTsMIBIHXOI783 CbXP1Ps5Y2y2oruTS06rodBwlN6W8lTDyGRT932Y89GsC52RhPKgb3wzF6rf+w6pBc HD7EIG0TFDkc14ojaIb7UcyXDPFF8Bn21FhYeyNM= Message-ID: <7276b34f-bba9-41a7-afd9-8505c83f8e08@quip.cz> Date: Sat, 4 Jan 2025 19:47:16 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: curious crashes when under memory pressure To: Karl Denninger , freebsd-hackers@freebsd.org References: <9e71d8eb-74c3-4bcb-89b1-90d4f9746168@quip.cz> <33db3282-25c4-42fb-8d97-1918d52fa9e2@denninger.net> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <33db3282-25c4-42fb-8d97-1918d52fa9e2@denninger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4YQTvW2Kr1z45B4 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] On 04/01/2025 18:36, Karl Denninger wrote: > > On 1/4/2025 12:30, Miroslav Lachman wrote: >> On 04/01/2025 17:27, Chris Torek wrote: >>> On Sat, Jan 4, 2025 at 7:01 AM Peter 'PMc' Much [..] >> Do you have swap on ZFS or not (in the first post you said "swapping >> to a zfs mirror")? If yes then it can cause the problems in memory >> pressure because system has no free memory but ZFS needs memory. >> If you want the swap on a mirror, then use separate partition on 2 >> disks and add gmirror on top of them. >> >> Kind regards >> Miroslav Lachman >> > What's the argument for swapping to a mirror in the first place? If the > issue is throughput IMHO the answer is to swap to multiple devices. Redundancy in case of disk failure. I've seen many disk failures over the years, and when you have a swap concatenated from partitions on 2 disks, the whole system mirrored on 2 disks, and 1 disk fails, the system crashes. That's why we've always used swap over gmirrored partitions. Then we can pull out one disk when system is running and replace it with a new disk. > Putting swap through a filesystem abstraction as noted above runs the > risk of requiring an allocation of RAM for the operation to complete > when you're desperately short on it in the first place resulting in > serious trouble. Kind regards Miroslav Lachman