Hi Mark, > Andreas Dilger wrote: > > We considered it a bug in ext4 and Lustre on the basis that it broke > > existing tools (tar, and AFAIR cp) that were working fine when > > delayed allocation and inline data features were not enabled. Since > > we were in a position to fix the filesystems faster than other tools > > (potentially those beyond tar/cp that we were not aware of), we > > decided to return an approximation for the st_blocks value to ensure > > that userspace tools do not behave incorrectly. > > Okay, but this is not an argument that the bug is in Btrfs. It's > merely a statement that you chose to work around the problem in your > own code.
No, it's *wise insight* into the reason to change btrfs regardless of whether it's correctly reading POSIX or not. As well as all the public source code that might make these long-held assumptions, there's lots of private, corporate, code too that would break if they encountered btrfs's beliefs, whether in btrfs or something else. And that breakage needs to be discovered case by case, probably when investigating why data has been lost! If, long term, btrfs want to be beyond reproach then they should lobby for a POSIX change/clarification. Alternatively, GNU tar or star can do similar. It seems clear progress has caught up with POSIX and it needs to decide a good way forward; it's judged well in the past, give it a chance. Don't let Jörg's occasional brusqueness skew your judgement. :-) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
