From nobody Thu Apr 04 22:44:54 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 4V9cBv1Z87z5GC5C for ; Thu, 4 Apr 2024 22:45:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4V9cBs5R6Bz4Tqb for ; Thu, 4 Apr 2024 22:45:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=BTB1E7Zh; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::12e) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-516ab4b3251so1842312e87.0 for ; Thu, 04 Apr 2024 15:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1712270704; x=1712875504; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EudZB0DoPEMlHnwHLGVrMw4HmrwRMUP9pboBN63XqDs=; b=BTB1E7Zhn00cASx48XWKeSEFal0fxg+pxH17bUkQHGon9nmmsAn7UHvrMZ37wEUPwc h0QKZuVJsKNsR/yVyLdyGdw8rJIK7oMTGmyjRvP/w+eY130ThJITmVLBeGxzaAyUGgoY 7MZiOJrLW5akvZ56ytKWk9zTRpxgbVapiclQv5sAcHAiGw0TlY4QjcQKsRi8kV1tUDaN CKiEm6QsV8lWAgCf1UaBBgi78tHF0HRUlV7CyMLSxNvZweAtz55Jp9GoSVMvbStZZzCE ltNwH+1mNDfhL4NDMoDDglge5Sjle4b+O6COiXNL4Zeb1fC64Bf3q/OHRGj/eIXvSEF4 Js8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712270704; x=1712875504; h=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=EudZB0DoPEMlHnwHLGVrMw4HmrwRMUP9pboBN63XqDs=; b=Pr0w5zzq36adzfKXLnd+z02icfgHD44BheOFgepV0w3x0ewSy1xfcOcYbdIKTGtp4b PExlFOM5oS5OLZj5lWZPCPLAvkQy4wVR1IfYC+XbxAXUDZ0M4NfFA9E+gf5uF1WP3zjM PzrIF/3Z1+Fivxufyber717C2kbvO32u3vA8NfLYs2FcjjDpuvMql+jwGxY/WLAKYrFH PhhzE9BAqHtwdiSMSCnHUetk+pQS2RpTnnbpZXVEN504wu2N2/j4KZ5k65BY+sF03v7U rY2skCTIsTtKDx3gzKjM9YF+Mz31V1KcSWhJec9mfgq3PsSjBHG6gPDqqxxonFYUsYxd 4XnA== X-Forwarded-Encrypted: i=1; AJvYcCUvvNVFYl5U4JObflS5AWEgLy1c4oxHdKIBqwR4xuL3BuO1W6Ysqxw+YSsdUHGG196BSFCS6igXxKugsnnG6A/Lvp/LIhRuBUWZB6U= X-Gm-Message-State: AOJu0YyI5hM7omKERlu87Se7mX2Df9Sx9FdcNPtJPt5nxa5fPyHpEuWJ D26IyZ0j/vqeiOxQSOqsvqMB8ZJDcokYZm6MQpCKni2oYElqNdiewC66bAW96MvV8k7zeVIcahc bXtMCfvn0Qo/ar62xUIyRArvJU8qARefU4Q4nKw== X-Google-Smtp-Source: AGHT+IFW5jZVagr5k6qXD9OuQklyGZvO+CQuNBck3UG/HEHv322bdxCIvnk1BijuYOe8paxlKkYerhUkiJBV5Od3vHg= X-Received: by 2002:a05:6512:554:b0:516:c41f:b0fc with SMTP id h20-20020a056512055400b00516c41fb0fcmr503853lfl.58.1712270704357; Thu, 04 Apr 2024 15:45:04 -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: Warner Losh Date: Thu, 4 Apr 2024 16:44:54 -0600 Message-ID: Subject: Re: SEEK_HOLE at EOF To: Rick Macklem Cc: Alan Somers , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000017e07c06154d17b1" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from]; ARC_NA(0.00)[]; TAGGED_RCPT(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4V9cBs5R6Bz4Tqb --00000000000017e07c06154d17b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2024 at 3:39=E2=80=AFPM Rick Macklem wrote: > On Thu, Apr 4, 2024 at 1:59=E2=80=AFPM Alan Somers = wrote: > > > > 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 nex= t > > > > 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 > would > > > > 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 wh= en > > > > the offset points to EOF. Those two statements seem contradictory = to > > > > me. The first behavior seems more logical. I would expect SEEK_HO= LE > > > > 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 tha= t > > > 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 tha= t > 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". > You have to join the mailing list to have access. It's easy to do. You can then download the latest draft (which I think is the ballot draft, so will be quite close to final, usually just 'typos' and such are corrected before the published standard).This will be the next POSIX.1 standard, likely this year. So it's kinda hard to give an exact link :(. Warner --00000000000017e07c06154d17b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 4, 2024 at 3:39=E2=80=AFP= M Rick Macklem <rick.macklem@g= mail.com> wrote:
On Thu, Apr 4, 2024 at 1:59=E2=80=AFPM Alan Somers <asomers@freebsd.org> wr= ote:
>
> On Thu, Apr 4, 2024 at 2:56=E2=80=AFPM Rick Macklem <rick.macklem@gmail.com>= ; wrote:
> >
> > On Thu, Apr 4, 2024 at 11:15=E2=80=AFAM Alan Somers <asomers@freebsd.org&g= t; wrote:
> > >
> > > tldr; there are two problems:
> > > 1) tmpfs handles SEEK_HOLE differently than other file syste= ms
> > > 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.=C2=A0 Als= o, each file
> > > has a zero-sized virtual hole at the very end of the file.= =C2=A0 So I would
> > > expect that calling SEEK_HOLE at EOF would return the file&#= 39;s size.
> > > However, the man page also says that SEEK_HOLE will return E= NXIO when
> > > the offset points to EOF.=C2=A0 Those two statements seem co= ntradictory to
> > > me.=C2=A0 The first behavior seems more logical.=C2=A0 I wou= ld expect SEEK_HOLE
> > > to work the same way both at EOF and at any other file offse= t.
> > >
> > > What does the spec say?
> > >
> > > There is no POSIX standard for this.=C2=A0 It was invented b= y 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".=C2=A0 That would= seem to indicate
> > > behavior 1: SEEK_HOLE should return the file's size at E= OF.=C2=A0 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 small= est
> > 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 great= er
> > or equal to the size of the file.
> >
> > I'd suggest we follow this, since it is the closest to a stan= dard that there is.
>
> That sounds like behavior 2: return ENXIO at EOF.=C2=A0 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)<= br> just google
"SEEK_HOLE austin group".

You= have to join the mailing list to have access. It's easy to do. You can= then download the latest draft (which I think is the ballot draft, so will= be quite close to final, usually just 'typos' and such are correct= ed before the published standard).This will be the next POSIX.1 standard, l= ikely this year.=C2=A0

So it's kinda hard to g= ive an exact link :(.

Warner
--00000000000017e07c06154d17b1--