[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data los
From: |
Joerg Schilling |
Subject: |
Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers) |
Date: |
Wed, 6 Jul 2016 18:33:13 +0200 |
User-agent: |
Heirloom mailx 12.5 7/5/10 |
"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/'
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), (continued)
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Joerg Schilling, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Antonio Diaz Diaz, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Joerg Schilling, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Paul Eggert, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Joerg Schilling, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Paul Eggert, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Austin S. Hemmelgarn, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Joerg Schilling, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Austin S. Hemmelgarn, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Austin S. Hemmelgarn, 2016/07/06
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers),
Joerg Schilling <=
- Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Andreas Dilger, 2016/07/06
Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), Pavel Raiskup, 2016/07/07
Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers), David Sterba, 2016/07/11