linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>, antonio@gnu.org
Cc: linux-btrfs@vger.kernel.org, bug-tar@gnu.org, adilger@dilger.ca
Subject: Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)
Date: Wed, 6 Jul 2016 12:11:19 -0400	[thread overview]
Message-ID: <2ed25df0-4204-a7bc-66c7-85d2ccdb77fb@gmail.com> (raw)
In-Reply-To: <418c9c5c-243c-5395-54c5-8b3975489bfc@gmail.com>

On 2016-07-06 12:05, Austin S. Hemmelgarn wrote:
> On 2016-07-06 11:22, Joerg Schilling wrote:
>> "Austin S. Hemmelgarn" <ahferroin7@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
> e-mail, for reference, they include:
> * A direct clone of HEAD on torvalds/linux
> * 4.6.3 mainline
> * 4.1.27 mainline
> * 4.6.3 mainline with a small number of local patches on top
> * 4.1.19+ from the Raspberry Pi foundation
> * 4.4.6-gentoo (mainline with Gentoo patches on top)
> * 4.5.5-linode69 (not certain about the patches on top)
Further ones I've now tested that behave like the others listed above:
* 2.4.20-8 from RedHat 9
* 2.6.18-1.2798.fc6 from Fedora Core 6
* 3.11.10-301.fc20 from Fedora 20

IOW, it looks like whatever you're running is an exception here.

  reply	other threads:[~2016-07-06 16:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-02  7:18 stat() on btrfs reports the st_blocks with delay (data loss in archivers) Pavel Raiskup
2016-07-04 19:35 ` [Bug-tar] " Andreas Dilger
2016-07-05  9:28   ` Joerg Schilling
2016-07-06 11:37     ` Austin S. Hemmelgarn
2016-07-06 11:49       ` Joerg Schilling
2016-07-06 14:43         ` Antonio Diaz Diaz
2016-07-06 14:53           ` Joerg Schilling
2016-07-06 15:01             ` Paul Eggert
2016-07-06 15:09               ` Joerg Schilling
2016-07-06 15:11                 ` Paul Eggert
2016-07-06 15:12             ` Austin S. Hemmelgarn
2016-07-06 15:22               ` Joerg Schilling
2016-07-06 16:05                 ` Austin S. Hemmelgarn
2016-07-06 16:11                   ` Austin S. Hemmelgarn [this message]
2016-07-06 16:33                   ` Joerg Schilling
2016-07-06 17:35                     ` Andreas Dilger
2016-07-07  8:08   ` Pavel Raiskup
2016-07-11 14:41 ` David Sterba
2016-07-11 15:00   ` Chris Mason
2016-07-11 15:16     ` David Sterba
2016-07-11 17:30       ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ed25df0-4204-a7bc-66c7-85d2ccdb77fb@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=Joerg.Schilling@fokus.fraunhofer.de \
    --cc=adilger@dilger.ca \
    --cc=antonio@gnu.org \
    --cc=bug-tar@gnu.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).