From nobody Wed Jan 19 08:44:34 2022 X-Original-To: freebsd-fs@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 582B0197126A for ; Wed, 19 Jan 2022 08:44:52 +0000 (UTC) (envelope-from florent@rivoire.fr) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdzjH5D4Qz4vf0 for ; Wed, 19 Jan 2022 08:44:51 +0000 (UTC) (envelope-from florent@rivoire.fr) Received: by mail-yb1-xb2a.google.com with SMTP id m1so5242954ybo.5 for ; Wed, 19 Jan 2022 00:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivoire.fr; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RC7DXZ4m1b7MbXlFekh1/fKP9fKF8XU+YA9nGbKhpL8=; b=TppGPqqdg4TaHXGai5QZ5v9bOCcumVHmlApxGr5qDLow5ewHZ7LEvaP5CWJYACRz5/ mDzuHTAAZDndkRBkTpnHqw7jJyAgSo7IKTiivROt25+SnxmP2Uq/S/TRYtnMoz6cwxIz 3Ao8GQwWqFJWJfagPzyca5AvLNw6Gn7HkIG7RSpMpUAQ9LhFqPz+kmMUQEmL0Erq4g0J +XgDjI9eQ5q6Fme0i5NB5enHEZyQ1Sd75/X/FJFWZzwMVJlaEsyZKnD3P5HrWeCx4x1+ 9/vI+NL0T/LBMEKE+gFF/GRkJO2wH/+UcOFWnjqJc/9vlr3bw+9vnJ0QVayKSG9u+GdB xR1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RC7DXZ4m1b7MbXlFekh1/fKP9fKF8XU+YA9nGbKhpL8=; b=UHt3h0eAbvuvjYVAciMi/rQjvpkVVIYkrQtqwveXzzkvcRZpMJawivAGyDgSdMIvEh HrXW5gl8rPoqpveefB6/PIcRiAmx91SnR9mWUTj/Qltq+m/8iMTvTKIgSSCcdFYwaAJ9 zMQTbiteCFcimBFuAt56Biq7Jd+zJdP1RhZS4eunZimwTEcZaBDvhmC/i9M7+3KsksHu CvgsITJZ0qfwEc5VrvGRzXOFLTTzH7+Tto3AY+qrZ7+X5kwadfVebb4flLbeLjPzAyG6 mbneOLu5zdoiwiMhPwinCLB2NVM8/IJSqYi4rDBZOXE5/rJMCmIUqnAS0us4ARxBEVzC l9+g== X-Gm-Message-State: AOAM531t5t7rIPMtyjkkBBBaBYPlqF/v0FtyYOV1TdZiDN84ELbooGv/ uJdaAX6yDxwiYujVtmO/HiHij0PhWxBu5MrSJgkHL33f8HokVg== X-Google-Smtp-Source: ABdhPJxQ7JcaBDndLERVN2mg8dBXPgCXhLPiHrDjHc3slN5PJi1QRHb/QIkBKQqQoVq6dUPELMFbDf70PUcswMC8lHQ= X-Received: by 2002:a25:d608:: with SMTP id n8mr9988683ybg.591.1642581885068; Wed, 19 Jan 2022 00:44:45 -0800 (PST) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Florent Rivoire Date: Wed, 19 Jan 2022 09:44:34 +0100 Message-ID: Subject: Re: [zfs] recordsize: unexpected increase of disk usage when increasing it To: Rich Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JdzjH5D4Qz4vf0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rivoire.fr header.s=google header.b=TppGPqqd; dmarc=none; spf=pass (mx1.freebsd.org: domain of florent@rivoire.fr designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=florent@rivoire.fr X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[rivoire.fr:s=google]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[rivoire.fr]; NEURAL_SPAM_MEDIUM(0.40)[0.404]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[rivoire.fr:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2a:from]; MLMMJ_DEST(0.00)[freebsd-fs]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 18, 2022 at 3:23 PM Florent Rivoire wrote: > I didn't think at all about compression (which I know exists and > usually has very positive impact) during my tests... > and it's indeed disabled in my tests (I'm only seeing it now): I did my tests again: exactly the same procedure as my initial email, just adding `-O compression=lz4` in zpool create. And now, the allocated size of disks (shown by zpool list) is the same in both cases (128K & 1M recordsize): 224G. So, good news :) Note: we can still see a difference in the "logicalused": 226G vs 232G (those are the allocated sizes that I had with no compression): recordsize 128K: ----------------------- # zfs get all bench |egrep "(used|referenced|written)" bench used 224G - bench referenced 224G - bench usedbysnapshots 0B - bench usedbydataset 224G - bench usedbychildren 1.83M - bench usedbyrefreservation 0B - bench written 224G - bench logicalused 226G - bench logicalreferenced 226G - recordsize 1M: ----------------------- # zfs get all bench |egrep "(used|referenced|written)" bench used 224G - bench referenced 224G - bench usedbysnapshots 0B - bench usedbydataset 224G - bench usedbychildren 1.88M - bench usedbyrefreservation 0B - bench written 224G - bench logicalused 232G - bench logicalreferenced 232G - -- Florent