Re: [Bug-tar] Detection of sparse files is broken on btrfs

[Joerg Schilling]

Andreas Dilger <address@hidden> wrote:

> So, what you're saying is that filesystem resizing is forbidden by POSIX,
> background data compression and data deduplication is forbidden by POSIX,
> migration across storage tiers is forbidden by POSIX?  All modifications
> to the filesystem need to be synchronous because they cannot have any
> background effects?
>
> POSIX is useful as a guideline, but shouldn't be considered a straight
> jacket that prevents innovation in storage.  Doubly so if POSIX doesn't
> actually require some behaviour, but only implies it by omission as you
> are suggesting.
>
> Maybe, you should stop trolling in the GNU tar mailing list and flogging
> your own tar for the past ten years?

Are you confused?

....or why do you attack me and agree with me at the same time?

Yes, filesystem resizing is a reason why statvfs() may return different data.
But as mentioned before, this is unrelated to the stat() data.

You need to understand the spirit of POSIX or you will missinterpret it.

BTW: There was a teleconference discussion about a similar problem with stat() 
some years ago and there is a full agreement that stat() returns the "visible" 
state of the cached filesystem in a way that there is no permission to modify 
stat() data just because the state of only the background storage did change.

Since you need to reserve space on the background storage before you can even 
write to the cached data for a file, you need to make stat() return the related 
state that includes the reserved space.

If you still don't understand this, I recommend you to try to write an in 
kernel 
filesystem implementation.... I did this 30 years ago.

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://sf.net/projects/schilytools/files/'