"Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote:
> On 2016-07-06 11:22, Joerg Schilling wrote:
> > "Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote:
> >
> >>> It should be obvious that a file that offers content also has allocated
> >>> blocks.
> >> What you mean then is that POSIX _implies_ that this is the case, but
> >> does not say whether or not it is required. There are all kinds of
> >> counterexamples to this too, procfs is a POSIX compliant filesystem
> >> (every POSIX certified system has it), yet does not display the behavior
> >> that you expect, every single file in /proc for example reports 0 for
> >> both st_blocks and st_size, and yet all of them very obviously have
> >> content.
> >
> > You are mistaken.
> >
> > stat /proc/$$/as
> > File: `/proc/6518/as'
> > Size: 2793472 Blocks: 5456 IO Block: 512 regular file
> > Device: 5440000h/88342528d Inode: 7557 Links: 1
> > Access: (0600/-rw-------) Uid: ( xx/ joerg) Gid: ( xx/ bs)
> > Access: 2016-07-06 16:33:15.660224934 +0200
> > Modify: 2016-07-06 16:33:15.660224934 +0200
> > Change: 2016-07-06 16:33:15.660224934 +0200
> >
> > stat /proc/$$/auxv
> > File: `/proc/6518/auxv'
> > Size: 168 Blocks: 1 IO Block: 512 regular file
> > Device: 5440000h/88342528d Inode: 7568 Links: 1
> > Access: (0400/-r--------) Uid: ( xx/ joerg) Gid: ( xx/ bs)
> > Access: 2016-07-06 16:33:15.660224934 +0200
> > Modify: 2016-07-06 16:33:15.660224934 +0200
> > Change: 2016-07-06 16:33:15.660224934 +0200
> >
> > Any correct implementation of /proc returns the expected numbers in st_size
> > as
> > well as in st_blocks.
> Odd, because I get 0 for both values on all the files in /proc/self and
> all the top level files on all kernels I tested prior to sending that
I tested this with an official PROCFS-2 implementation that was written by
the inventor of the PROC filesystem (Roger Faulkner) who as a sad news pased
away last weekend.
You may have done your tests on an inofficial procfs implementation....
> > Now you know why BTRFS is still an incomplete filesystem. In a few years
> > when
> > it turns 10, this may change. People who implement filesystems of course
> > need
> > to learn that they need to hide implementation details from the official
> > user
> > space interfaces.
> So in other words you think we should be lying about how much is
> actually allocated on disk and thus violating the standard directly (and
> yes, ext4 and everyone else who does this with delayed allocation _is_
> strictly speaking violating the standard, because _nothing_ is allocated
> yet)?
If it returns 0, it would be lying or it would be wrong anyway as it did not
check fpe available space.
Also note that I mentioned already that the priciple availability of SEEK_HOLE
does not help as there is e.g. NFS...
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
