Caveats with compression and fallocate

[jimis]

No description provided.

[jimis]

ping @adam900710

[adam900710]

Although I have merged the two patches, they all went through some modification.
If you want to contribute to btrfs in the future, it would be better to follow the next two points:

• Write a commit message
  Even for simple doc update, please write a short description for the change.

• Use a "Signed-off-by" line
  This can be generated by "-s" option of "git commit".

[kdave]

I'd like documentation updates to be easy and low barrier so I don't insist on formatting, changelog or Signed-off-by. This is also mentioned in README.md. Casual fixes or clarifications are more valuable than requiring the whole contribution process.

[kdave]

Also the Signed-off-by line should not be added by us unless it's part of the patch. I add Author: tag or link to the issue or pull-request, this keeps the credit. The signed-off-by line and DCO has a 'legal' meaning https://developercertificate.org/ and needs to be stated by the author.

[jimis]

Thank you! Would you consider adding a mount option for fallocate() to return EOPNOTSUPP and stop messing with compression?

Our discussion gives me the impression that is now a possibility:

Maybe the best tradeoff is to add a mount option fallocate=off.

That will be feasible.

I can try push that direction after you have updated the docs.

[jimis]

I also wonder, does the case I documented here for files extended with fallocate(), also apply for files extended with ftruncate()?

That is, such files will be excluded from future compression?

[adam900710]

Only for falloc(), not ftruncate().

The PREALLOC inode flag is added for any preallocated file extent, meanwhile truncate only creates holes.

[jimis]

Thank you @adam900710. So it seems ftruncate() may be the most efficient way to extend a file. I'll transfer this info to the postgresql-hackers mailing list where this issue and potential workarounds are being discussed.

[adam900710]

truncate is fast but it's really different from fallocate by there is nothing really allocated.

This means the later writes will need to allocate their own data extents.
This is fine and even preferred for btrfs, but may lead to performance drop for more traditional fses.

We're in an era that fs features are not longer that generic, fallocate is just one example, in fact fallocate will cause more problems more than no compression.

It's really a deep rabbit hole, and is not something simple true or false questions.