From nobody Sun Oct 10 06:02:46 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 6169617EA10B for ; Sun, 10 Oct 2021 06:02:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrv702PDz4pVl for ; Sun, 10 Oct 2021 06:02:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id w13so15268455vsa.2 for ; Sat, 09 Oct 2021 23:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HVDKb/Bn4P661p8ejWFwHTRLWdcokUBPPJA/CY3zkRM=; b=pJ/0QwZ7cJsLDf81OU3Z7J81UFxol4x/PXJEUKkrvdHN1+B5Jmxbbp1gx4OSnZDY1m wMwdbwko1YZFYe8EtoN8SzvhDqIHkg7vWIfgZhmmrFl6I/UWmz/NmFLp0/+DOWAt4yvc rrKygTUs9Q6A1/GDyZxx3KNywe/j4ZOE9nES+9KfoMEyAtNrv/uqatsTN8qarDTqrijc RyCss36n/AHBOLzUDPMKCGr/T2FmNoMhc05Pnn6slKsQ8tgsRWJUCEy7O+xTgSpMYB1d 8yxTKAtNH+/o4mjXFXU8GC0pBu+hVzCRcqYzgtv+qoFF/wYk9ZGMlly1g0Qevza6jlKk GpDA== 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=HVDKb/Bn4P661p8ejWFwHTRLWdcokUBPPJA/CY3zkRM=; b=FkfxxbhroD231hxO0JygTEe/zo+pI+6meZUeb6yqe50Ezb1daZk5eLutfCSV5lGVKr m6TfDPuP8RSmjmLaauSqvVYIWKKHkSu2imuprANFr8aw/TG7A1SwDIfufdu8R+Td897B O5nJ3bmtBT5MfFS8nUT/oWV3rJIudHXk0ikGwmuRXSi4hsvyOlu93RBD0IWPdZ0BF1/k A3ms1G8nmG0BkJtfajYdoGGzlxCZvqwIwnvU2+lWuffZb+lFcZgMww8ld2K1+ma5RShz ISS9zZj/AVrf8+AWa5OWutDuIQPIqOVWecyuqWNTDgKxaq4Yp+8JPyparqICPOOmBGa+ gYvQ== X-Gm-Message-State: AOAM533iv0h04IWWWMmKFXRUfwOs3X5dk+DyvWGNdWtXaV293pGY5cgL Cxy9NdkdSKgl7e/FCtJklzB4GEMqc2Q1uYDBc1LSDA== X-Google-Smtp-Source: ABdhPJxh4gxlD5IiEvzjuAN5Re30kS1vY14ag4ry7A+xsJB1n1tlDFANgC0gZ/xJY+IN0az10AxN4lbEk5Qv3MY3rfU= X-Received: by 2002:a05:6102:6ce:: with SMTP id m14mr18457891vsg.42.1633845778108; Sat, 09 Oct 2021 23:02:58 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Sun, 10 Oct 2021 00:02:46 -0600 Message-ID: Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem Cc: Alan Somers , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000038ee5f05cdf95db5" X-Rspamd-Queue-Id: 4HRrv702PDz4pVl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000038ee5f05cdf95db5 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021, 11:58 PM Rick Macklem wrote: > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nfsv4@ietf.org's testing > event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I > think > this is now "cast in stone". > > >> > >> 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? > Since it is log based, that would make it worse. The blocks aren't instantly reclaimed when marked invalid. So you'd need storage for both and the 0d blocks could cause a resource shortage when the real writes come in. ZFS doesn't have a reservation system to reserve blocks in the log for a given file... Warner >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > > > > --00000000000038ee5f05cdf95db5--