I don't understand what you are trying to say. Are you suggesting the
fsync would help the issue you described (I don't see how), with the
file ending up having compressed and uncompressed extents, or is that
for some other issue you are thinking about?
Is this specific to Btrfs, or is it a Linux design choice?
Can't tell since I don't understand what is the problem.
As a normal end-user, my expectation is that if I 1) first write to a
file, then 2) change its attributes (compression), those attributes
should not affect the data previously written.
But how it is now, depending on how "quick" the system acts in writing
out the data, some of it might be written after the attributes take
affect. I found this non-serial way of writing confusing. It is probably
how it is supposed to be, and my understanding is lacking :)
Thanks again!
