@hartan Your first article in this series was well received. We're looking forward to the next instalment.

The second article was a hit, @hartan

This article was third in line on the original proposal.

Any chance you can keep the ball rolling with this one? You've got a growing fan club. :smile:

Hey @rlengland,

I'll definitely keep at it as best as I can. :)
While you're right about the order in the original proposal I'd like to publish #111 (Snapshots) first, because Snapshots are very closely related to Subvolumes. Also I think users are going to draw much more use out of snapshots (because they allow e.g. for very convenient backups).

@hartan I think doing the snapshot article makes good sense and I agree. Looking forward to the next installment.

Hello @rlengland,

took a bit longer than I wanted it to, but here's a preview for the next article: https://fedoramagazine.org/?p=37737&preview=true&preview_id=37737

I'm not sure wether I like it yet, because it doesn't have a lot of examples with it. On the other hand I think that compression isn't exactly something I can "show" with good examples, either. It still has a TODO left (need to upload something to Gitlab), but the text itself is ready for review!

@hartan We haven't spent a great deal of time on the text yet but will. However, the intro paragraph appears to be the same as that for the Snapshot article. Can you take a look at that and modify as necessary?

@rlengland Good catch, I did update the link to the previous article, though. :)

I fixed that and removed the last TODOs, there's now a script to perform a compression test on Gitlab (https://gitlab.com/hartang/btrfs-compression-test). Or would you prefer if I used pagure.io to host contents that I refer to from inside a Fedora Magazine article?

Looking forward to your feedback!

@hartan I've done a review/edit pass on this article and it looks pretty good. Two things:

1) on the following command:
$ findmnt -vno OPTIONS /path/to/mountpoint | grep compress
was there suppose to be a set of OPTIONS there or should the 'o' option and the text "OPTIONS" be omitted?

2) I've shifted the pronoun 'we' to 'you', in several locations. I believe 'you' is a bit more active and addresses the fact the the reader is being required to observe or take an action. In addition, you slid back and forth in the 'we'/'you' area so this is more consistent. I hope this is okay with you.

Andreas, I think this article is ready to publish if you can clear up the question about OPTIONS in my previous message.
Thanks in advance

Hey @rlengland,

thanks for the review and edit! I'm totally fine with making the usage of 'you' consistent in the text, I agree it's more active.

The command findmnt -vno OPTIONS /path/to/mountpoint is correct, by default finmnt will display the columns TARGET,SOURCE,FSTYPE,OPTIONS, and we only care about the OPTIONS here. :)

If you don't mind I'll give the text another read in the next two days. So if you don't hear back from me by Wednesday I'm fine with publishing the text.

Thank you, Andreas. A closer (more careful) reading of the man page would have made "OPTIONS" clear.
If I don't hear anything further I'll schedule publication for Friday 17 Feb.

@rlengland Just finished reading the article again and there's nothing I want to change. Looking forward to how the community likes this one!

@hartan Thank you for alerting me. I've scheduled the article for this Friday, 17 Feb. 0800GMT

Thanks for you hard work on this series. It is really appreciated. I've got my eye open for the next one :smile:

@rlengland Two readers each noted a little inconsistency/error in the text. Is there a chance we can update the text somehow?

I believe we can update the text but I'm not certain what the best way is. At the least, if you can provide the text and a description of exactly where it should be we can do it for you.

@glb may have a better or more efficient way to let you do it.

@hartan Let us know the text and location and we'll make any correction you wish to have done on this article.
Thanks.

@rlengland: I already added the following note to the article. I took some of the text from Andreas' reply in the comments section.

Note: Since the compression used by Btrfs relies on an in-kernel (re)implementation of these compression algorithms, the results from these user-space versions of the algorithms should be considered rough approximations.