On Jan 19, 2018, at 2:27 AM, Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote: > > Paul Eggert <egg...@cs.ucla.edu> wrote: > >> On 01/18/2018 02:33 AM, Joerg Schilling wrote: >>> Returning a value for st_blocks, that changes with the phases of the moon >>> while >>> the content of that file is not changed is another unexpected behavior. >> >> Not at all. It's completely expected nowadays, for the same reason that >> invoking statvfs twice on the same file might return different results, >> even if no application has made any change to any file. Nothing in POSIX >> says or implies that an implementation cannot spontaneously change the >> amount of available space in a file system, or that it cannot >> spontaneously change the amount of space that a file is using. > > Sorry, but this is not related to our topic. If you change the filesystem, it > may result in a change of available free space. > > Maybe, we should delay this discussion until you present us arguments for your > whishes.
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? Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
