From nobody Sun Oct 10 20:15:44 2021 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 D40F517F7ADF for ; Sun, 10 Oct 2021 20:15:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 4HSCq64rNhz4VHL; Sun, 10 Oct 2021 20:15:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 7B4483D307; Sun, 10 Oct 2021 22:15:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1633896939; bh=fte4tmqDdgs8j8nsePt6irr6vY4HRlMlIlYUcpzCbMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QgtLPhkFru4H7H122N62J3z6uVM8rbBqkMtKcxUCFToK2Z6c/XhaDDxhJr907+ckk ViRmP/j+nTST186ckVxaqws3EMtJm6WlJHLAGP7Y+dPpFuzx9CcNTclrCt3x6247Vx oChV6ixTmfTd89bJN/KXYPgc1kank+XV/sS9haDJodVEWSR1rdi4G0vl2PEmjYzGjq ltCOGWLwX9WcX2kKwIdEdg3joWvL+DarXzrN0L/btooSIYIz9H7Pv6gn1T2HD6K/Ti sQV/BZXfFHpP6z7iXccgdb7qM0DutQ0pRXR4NWdvmh2AzHQo8f/l+2QaxR6zc2tP6z oHKMD75ogRxgw== X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWDqjiuvmxKF; Sun, 10 Oct 2021 22:15:39 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id E334D3D14A; Sun, 10 Oct 2021 22:15:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1633896938; bh=fte4tmqDdgs8j8nsePt6irr6vY4HRlMlIlYUcpzCbMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kwawD3gmS92y6f9w8zogbDlsCJlzZyaWB8byk4yZ/0wgDPFTFz21whALSXP7zHgWY r6MIQ4lwvozs1gvzwQc/GzbvVk0vzqqpokwyPQMBdMUc2+oxJHPfjpMWJ6sWpzLjOg 2YQh2nhERKFEj2TKgzmPnfLgnMhOxgTBlhVL2wRZvw9zO9h3sWk93LAnQ51+iLMEsY DmFHbW9kYs5Bq2J/To3xN/gl31vcdjcdUsIzuvlmewA6ayxa1rl4r0IhdofzVJSf2h ozhkcLuPBM68XNDu/k4mque4Uo6uXH6LgWbqiwXATrvYKfO3YLQ2tzsG0R8CjuVoKs +OXbXb7YlJ9Bw== Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem , Alan Somers Cc: FreeBSD Current References: Message-ID: Date: Sun, 10 Oct 2021 22:15:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4HSCq64rNhz4VHL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: wjw@digiware.nl From: Willem Jan Withagen via freebsd-current X-Original-From: Willem Jan Withagen X-ThisMailContainsUnwantedMimeParts: N On 10-10-2021 07:57, Rick Macklem wrote: > >>> This leads me to a couple of questions: >>> - Is there a good reason for not using vop_stdallocate() for ZFS? >> Yes. posix_fallocate is supposed to guarantee that subsequent writes >> to the file will not fail with ENOSPC. But ZFS, being a copy-on-write >> file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? > I had the same problem in Ceph, where a guaranteed writable space is required for keeping a log of modifications to the system. Not having this space might case loss of data. Writing al zero's is probably even worse on filesystems that have compression set. Almost nothing is allocated, and so no guarantee at all. Next trick wass to write random data, but then you run into the problem signaled by Alan and Warner. New writes will need free space, since the CoW nature. Solution was to actually create a specific zpool just for this. But that will not help you with NFS 4.2 I guess --WjW