From nobody Thu Apr 04 21:38:43 2024 X-Original-To: freebsd-hackers@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 4V9ZkS6B3zz5G5MM for ; Thu, 4 Apr 2024 21:38:56 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4V9ZkR6BxDz4MyP; Thu, 4 Apr 2024 21:38:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-29f69710cbbso1081975a91.1; Thu, 04 Apr 2024 14:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712266734; x=1712871534; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=h5CI78Ayh7+CctyCA+wUNBTrxrUkQEU9ZS6nLy2+JNM=; b=c8yHw4cv3pe+YRtSbZsi6Yg9HxW278GOb/dZyGKV0h01t6wIghzFBTrWfABKw+KmAc nKUJwh4648kqOE3X6pK3Mz5FIuFAx+qpHsZiZ0SFBVxuFzrg2r9trWB057NyqL6X22El BL/iTzZcHhemNpg2uXj9YXZivPNE/8eyWt0YkinYTc5D9ZjKra7pQNg7zN5ZZpQOW7Kp rm87Qob7zy0rLiY7TlQXMjwE5wkejxQZPgg5NXtbhA8b+Y8eCSalxyuK5thqaAvtVc64 1v/OWP8WuLquV5ZMIWPxPogitD2Y9VSdIs4fbLVY+F5yY9nYu15qhJyTrCH958D/5YOB EDIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712266734; x=1712871534; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=h5CI78Ayh7+CctyCA+wUNBTrxrUkQEU9ZS6nLy2+JNM=; b=Y9fAEEcRevHFe4/S/yTNBNDQDt259TwACjEX1zd6cMLdzH9TdrYQpjp+p0pDeKVTbT BtNRpNsyv1lGLOfKjKhH33lkI2hiI5pH/NM67s1nalOd1hhEyCgF5jMRRcmuQjoYvURL XZ/Qm8mywjXWOl1vJRu+aVoKS75gDmfESVbJKuUmN1XnfrLuxykE4DYsNzZ1f9CG45wT Gm8I672iju87OVOfzlLdMklyq0rF0PN1Uwz+vBk2J/8kPUqyiV9xyU6x/XVQxQbHOLjN s2+Drq6UOT/lGIU3PNUitkNKS8v3cRTHMMoDSZy36iyarCNWhewQ3WgFqQnSkYC7GcQX Z+nA== X-Gm-Message-State: AOJu0YxJ+hD7CcqQIxDlX5kTFgb4KYemu1lnFeEvYGMX0yNoXfknw0w4 KQXgEGN5JFZQsJ+s2cL4h+P98gs6UavJWduHPIRjZz7CQn7dLkgnaaNMbLKogXrb8jDxQWALd2e viw0OSPbs1DLJ0xsnX4lU+BANvvsXlUVUcQ== X-Google-Smtp-Source: AGHT+IFQBcQGWwJMSAWWBZNp1YDL06ahHH4rkSUcFpHDKgl6XRUCYt4ympG/PaIrF//SmxUjqeD3WY/Lm7XT9gSZTAM= X-Received: by 2002:a17:90a:4cc5:b0:2a2:61a0:d1f4 with SMTP id k63-20020a17090a4cc500b002a261a0d1f4mr961033pjh.18.1712266734002; Thu, 04 Apr 2024 14:38:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 4 Apr 2024 14:38:43 -0700 Message-ID: Subject: Re: SEEK_HOLE at EOF To: Alan Somers Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V9ZkR6BxDz4MyP On Thu, Apr 4, 2024 at 1:59=E2=80=AFPM Alan Somers wr= ote: > > On Thu, Apr 4, 2024 at 2:56=E2=80=AFPM Rick Macklem wrote: > > > > On Thu, Apr 4, 2024 at 11:15=E2=80=AFAM Alan Somers wrote: > > > > > > tldr; there are two problems: > > > 1) tmpfs handles SEEK_HOLE differently than other file systems > > > 2) everything else handles SEEK_HOLE at EOF poorly, IMHO > > > > > > Details: > > > > > > According to lseek(2), SEEK_HOLE should return the start of the next > > > hole greater than or equal to the supplied offset. Also, each file > > > has a zero-sized virtual hole at the very end of the file. So I woul= d > > > expect that calling SEEK_HOLE at EOF would return the file's size. > > > However, the man page also says that SEEK_HOLE will return ENXIO when > > > the offset points to EOF. Those two statements seem contradictory to > > > me. The first behavior seems more logical. I would expect SEEK_HOLE > > > to work the same way both at EOF and at any other file offset. > > > > > > What does the spec say? > > > > > > There is no POSIX standard for this. It was invented by Solaris, > > > Illumos's man page does not say clearly say what should happen at EOF= . > > > Linux's man page is clear: "whence is SEEK_DATA or SEEK_HOLE, and > > > offset is beyond the end of the file". That would seem to indicate > > > behavior 1: SEEK_HOLE should return the file's size at EOF. Only > > > beyond EOF should it return ENXIO. > > Well, there is the Austin Group stuff (never ratified by POSIX as I > > understand it). > > > > Here's what it says about SEEK_HOLE and offset: > > If whence is SEEK_HOLE, the file offset shall be set to the smallest > > location of a byte within a hole and not less than offset, except that > > if offset falls within the last hole, then the file offset may be set > > to the file size instead. It shall be an error if offset is greater > > or equal to the size of the file. > > > > I'd suggest we follow this, since it is the closest to a standard that = there is. > > That sounds like behavior 2: return ENXIO at EOF. For reference, do > you have a link to that somewhere? 0000415: add SEEK_HOLE, SEEK_DATA to lseek - Austin Group Defect Tracker (austingroupbugs.net) If this doesn't give you a link (gmail never shows the raw url for me) just google "SEEK_HOLE austin group". rick