Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

[Joerg Schilling]

"Austin S. Hemmelgarn" <address@hidden> wrote:

> On 2016-07-06 11:22, Joerg Schilling wrote:
> > "Austin S. Hemmelgarn" <address@hidden> 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:address@hidden                    (home) Jörg Schilling D-13353 Berlin
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/'