From nobody Tue Feb 07 01:23:34 2023 X-Original-To: freebsd-current@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 4P9ll90vNHz3nhSl for ; Tue, 7 Feb 2023 01:23:49 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 4P9ll80lXzz3KKp; Tue, 7 Feb 2023 01:23:48 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=UvmhBwuW; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-x531.google.com with SMTP id 7so9453749pgh.7; Mon, 06 Feb 2023 17:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=08vxF+TJkIKz13WBpu+qyg8OCT72rdtsePf7ShAyMMY=; b=UvmhBwuWyMNHAhYsRANzxT+cbSHO7c+Eu7FkxWwPEvWlM6iVzAt7KHUAkWimwrizS+ 4gGnPNon4GLDLxNwfAzSO1c+r9FbMOrGmS1RrBoHyac937O6KeXF4Hdf6H3oyfa6FKxy CLLTPb5PzXiPzoiRxxpe5pPD/d2BMiSQjOTueMuLTWzipDEA2K8hDIrxLGp+nO4P2Jhu mF6GL4B49Ko2EuiPo7Og/CMnCOACl1MGN0iCrf7qXNN+WMQ3cW+G3PpVleqBNjR8DzE7 MANU1q9DLDEwDE90XPKLMwLKWFTMHd5VTCraST9m+P14Xqc4rMVjbQUdMIUd1m/BNLI9 bwWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=08vxF+TJkIKz13WBpu+qyg8OCT72rdtsePf7ShAyMMY=; b=6rS6bqeMNokiavudfCBSIjRlpE6Va7aysj9EjWCm8pkICs6L3FmSQNcSPlXoYCYtVq 61Ia0OTFF/dku2+05BhIx4TAikbRJS0X8m0We6PqutIEBJl0DEfAsPbqwrOy+sZqW3On 8pt8dRPWTLIi6u1hIvTWzB/qI0+34hpcianVDze2N6HGpQjZCFl8oRIfAqjdG3ocww/A 5UTx4D+6zYM6Ar7rbNYCzGOgnf7SN7fcwQUqTtkEpLNDL3yKO5r5bmT5nDGEMICBche5 4M1WeR4pb9kcvtn3WdNGRv2f/opxlRAY2F2FGPHCh6sqMQn4YhlVjYDgmX5pDMshlaMe iLmw== X-Gm-Message-State: AO0yUKX9p6ad22BWJ0TCFTsYm33CrzcBjUIqtELqVRA+HfTe+nwILWHo skHzMSuqZy1pxZFphJbc1Sw3cx1CEboY64J1BzH2H9Ou2Q== X-Google-Smtp-Source: AK7set8CyWNb5IT3Vfy0U6YaYqIIzmAK9beb2j1S0mRPsD3KCR3jMspC95dJJIEkkhkiPlByMjxPsx4oFg7B4FML+ZI= X-Received: by 2002:aa7:8bdc:0:b0:592:5ee5:8826 with SMTP id s28-20020aa78bdc000000b005925ee58826mr323486pfd.20.1675733025954; Mon, 06 Feb 2023 17:23:45 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Rick Macklem Date: Mon, 6 Feb 2023 17:23:34 -0800 Message-ID: Subject: RFC: Should fspacectl() commit changes to stable storage? To: FreeBSD CURRENT Cc: Konstantin Belousov , Alan Somers Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::531:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P9ll80lXzz3KKp X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N PR#269328 reports an issue related to fspacectl() being mixed with mmap'd I/O. When working on a fix for this for the NFS client, I realized that "man fspacectl" does not clarify if the deallocation should commit changes to stable storage before returning success. vop_stddeallocate() currently does not do this so, if a machine crashes immediately after fspacectl() returns success, the hole may not be there when the machine reboots. For POSIX writes, it is clear that recently written data may be lost when a machine crashes/reboots and fsync(2) is used to ensure the data is on stable storage and won't be lost when a crash/reboot occurs. The question is "Should fsync(2) be required to ensure a hole punched by fspacectl(2) is not lost or should it be guaranteed to not be lost when fspacectl(2) returns? Since fspacectl(2) is FreeBSD specific and there is no standard, it could be defined either way. So, what do you think? rick