Andreas Dilger <adil...@dilger.ca> 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:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
