Re: NFSv4.2 READ_PLUS support?
- In reply to: Freddie Cash : "Re: NFSv4.2 READ_PLUS support?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 26 Aug 2025 17:03:03 UTC
On Tue, Aug 26, 2025 at 8:45 AM Freddie Cash <fjwcash@gmail.com> wrote: > > From your link, this page specifically: > https://pubs.opengroup.org/onlinepubs/9799919799/ > > A hole is a contiguous region of bytes within a file, all having the value of zero. > > Definition of a hole from here: > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html > > A contiguous region of bytes within a file, all having the value of zero. > > Sounds like POSIX treats a hole in a file as a stream of 0x00 bytes. Yes, it is my understanding that a POSIX hole "might not have blocks allocated to it, or it might". It would be less confusing if anyone discussing "unallocated regions" used that term and not "hole". RFC7862 (the NFSv4.2 one) seems to use "hole" loosely without defining it. (In some placed it seems to refer to "unallocated regions". In others, it seems closer to the POSIX definition.) I'm just sticking with the POSIX definition for now, rick > > On Tue, Aug 26, 2025 at 6:32 AM Aurélien Couderc <aurelien.couderc2002@gmail.com> wrote: >> >> On Mon, Aug 25, 2025 at 1:45 PM Dag-Erling Smørgrav <des@freebsd.org> wrote: >> > >> > "Rob Norris" <robn@despairlabs.com> writes: >> > > Cedric Blancher <cedric.blancher@gmail.com> writes: >> > > > Holes are not sequences of 0x00 bytes. Holes means "no data here". ZFS >> > > > compression should preserve the sparse information, otherwise you turn >> > > > ANY sequence of 0x00 bytes into holes,and that will break databases >> > > > and other applications which depend on exactly that *precise* >> > > > semantics. >> > > This is the second time I've heard this on this list (previously[1]) but >> > > I don't know what it's referring to. >> > >> > They made it up. >> >> Nobody made that up. It's reality, even defined by POSIX, IETF NFS and >> the UNIX greybeards, long ago >> >> > A hole is just an optimization, and it is 100% up to >> > the file system whether holes are created and where. Any application >> > that considers a hole to be semantically different from a sequence of >> > zeroes is broken. >> >> No, this is part of POSIX (e.g. >> https://pubs.opengroup.org/onlinepubs/9799919799/ ff), *AND* >> traditional UNIX filesystem behaviour. >> >> As pointed out, changing hold to 0x00 bytes is bad, as it breaks >> existing applications (usually databases and scientific applications), >> >> Aurélien >> -- >> Aurélien Couderc <aurelien.couderc2002@gmail.com> >> Big Data/Data mining expert, chess enthusiast >> > > > -- > Freddie Cash > fjwcash@gmail.com