> On Jul 6, 2016, at 10:33 AM, Joerg Schilling > <joerg.schill...@fokus.fraunhofer.de> wrote: > > "Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote: > >> On 2016-07-06 11:22, Joerg Schilling wrote: >>> >>> >>> 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....
So, what you are saying is that you don't care about star working properly on Linux, because it has an "inofficial" procfs implementation, while Solaris has an "official" 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... So, it's OK that NFS is not POSIX compliant in various ways, and star will deal with it, but you aren't willing to fix a heuristic used by star for a behaviour that is unspecified by POSIX but has caused users to lose data when archiving from several modern filesystems? That's fine, so long as GNU tar is fixed to use the safe fallback in such cases (i.e. trying to archive data from files that are newly created, even if they report st_blocks == 0). Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP using GPGMail
