From nobody Sun Oct 10 13:48:49 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 0A05C12DF1F7 for ; Sun, 10 Oct 2021 13:49:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 4HS3Dz6ngKz4nSl for ; Sun, 10 Oct 2021 13:49:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id s18-20020a0568301e1200b0054e77a16651so1366714otr.7 for ; Sun, 10 Oct 2021 06:49:07 -0700 (PDT) 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=tFpF2tvVTMTB3g76ffSEqMCIAEgv7cyezZo70PSFqRE=; b=lsyZin3ZYcyEtJezvSJ1Zfg0HF3w6LXscJGd9qRdLfhjEkQKYdKFXl5M4rlgPyzLt9 eGwbt/CgAu6VNtyVkBv6YM0x1EWj+IiKzyarg0le0rf7EhOVo2uhj9+xQ6KTrpLPSXKS ms9nKEbT2zCP0w97KqgWjyAvWNhZZGKcZmSQ6gKZSjBdlDnY9xYhRN51qT+bGZaA7Sio n645qHrffcvynvKrVTWKPZxjM0iXC0iHJtVDOE3diLlDCHhKFTEuBxLdy0+8XTbBw1rV SG8lqKJ26dTEgZ+0JrWlB45u0uBZusayuIV58bDuRVLxSMb0VDQ7SU0JxihL9MTExury m+4g== X-Gm-Message-State: AOAM53366Nvfls+VXH3JG9O3Ks9HsJ9dKf8PtjVAjZVEsSIHZoL9tC+p IuSZdDzzFgrl0iiTahsQ5/05/feWK8rU6KRy6MwC2c2V X-Google-Smtp-Source: ABdhPJz5Yuqe/Lr/9TOgbZ0d44plY8cbRP0kDRtApPxpI4DxibuYcx0lYiJJ95gQZkI9GdBj6q9LFQ4whN9GuPqiiMk= X-Received: by 2002:a05:6830:44ab:: with SMTP id r43mr16980040otv.371.1633873740908; Sun, 10 Oct 2021 06:49:00 -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: Alan Somers Date: Sun, 10 Oct 2021 07:48:49 -0600 Message-ID: Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HS3Dz6ngKz4nSl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 9, 2021 at 11:57 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? No. It works for UFS, which is an overwriting file system. But for ZFS, when the user comes back later to rewrite those same offsets, ZFS will actually allocate new LBAs for them. > > >> - 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 > >