From nobody Tue Feb 07 03:47:30 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 4P9px70gv2z3nqXF for ; Tue, 7 Feb 2023 03:47:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P9px63vSwz3nfs; Tue, 7 Feb 2023 03:47:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 3173lUJ6035343 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 7 Feb 2023 05:47:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3173lUJ6035343 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 3173lU8L035342; Tue, 7 Feb 2023 05:47:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Feb 2023 05:47:30 +0200 From: Konstantin Belousov To: Alan Somers Cc: Rick Macklem , FreeBSD CURRENT Subject: Re: RFC: Should fspacectl() commit changes to stable storage? Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4P9px63vSwz3nfs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Feb 06, 2023 at 06:59:59PM -0700, Alan Somers wrote: > On Mon, Feb 6, 2023 at 6:23 PM Rick Macklem wrote: > > > > 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 > > It think it should be just like write. An fsync should be required to > ensure that the effects will be visible after a reboot. I agree. It is easy for an application to do fsync() after fspacectl() to get synchronous behavior. But if we make fspacectl() synchronous, application cannot revert the behavior to the speedy one. As Alan said, it should be same as write(). This does not preclude some filesystems to choose stronger guarantees, of course.