Issue #108: Understanding BTRFS and putting it to good use "General Explanation" - fedora-magazine-newsroom

@hartan Your first article for the series is very well written. I think, in general, images are usually helpful to explain concepts. They can reinforce the reader's "mental picture".

If you want to reach those that are not familiar with the "inode" concept, a little more explanation there wouldn't hurt and you can always indicate which sections the knowledgeable person can skip.

You might want to have the second one in the series started so there isn't a large time lag between them, but I understand that your time may be limited.

I'm a novice btrfs user and I'm looking forward to your articles.

@hartan: I see that there is a "TODO" in this article. I take it that you are still working on it?

@hartan: Do you have a status update on this article?

Your first article for the series is very well written.

Thank you!

If you want to reach those that are not familiar with the "inode" concept, a little more explanation there wouldn't hurt

Yes I thought so, too. I'm just uncertain how much of this sort of content I can add to keep the article relevant, since it does relate to btrfs after all.

You might want to have the second one in the series started so there isn't a large time lag between them

I already have a draft for that and I'll be updating the other pagure issue soon.

I see that there is a "TODO" in this article. I take it that you are still working on it?

@glb That is correct, I'd like to add some more sources so people don't just have to take my word for it. I'll also try to sketch an image of the CoW concept so people get a real picture to their mental picture. Myself I find it incredibly helpful to keep the CoW part in mind when doing most of the btrfs-related work I do.

I'm sorry for the long delays between my replies, my time management is in dire need of a review...

I have updated the article with two images to explain the CoW concept. I have decided that since inodes and everything that comes with it (I.e. directory entries, superblocks, etc.) are a topic that easily fills whole lectures, I'll try to find some external reference that is publicly available and explains the general concepts.

I have a question about Wordpress: In the past I saw other articles in the Magazine that had a section with References at the bottom and referred to these from the text (I.e. there was a hyperlink in the text that scrolled the page there). How exactly would I do that? I prefer that type of referring to things over hiding hyperlinks in the text.

Hi Andreas, @hartan
I believe the technique you need to use involves WordPress "Anchor Links". I have never used these but here are two links that might help. It seems relatively straight forward but will involve a few more steps than simply creating the link from the article text.

See if either of these is what you are looking for.

Foot notes technique: https://wordpress.com/support/how-to-add-footnotes/
Jump pages: https://wordpress.com/support/splitting-content/page-jumps/

@rlengland Thanks, that's exactly what I needed!

Just to keep you updated:
I'll get some friends to read the article to see whether it makes sense to them (They haven't heard of btrfs before, so I guess that "qualifies" them perfectly well). I'll also ask around in the btrfs community whether someone there would do some proof reading to make sure I don't spread false information on the internet. Because that would be embarassing. :smile:

I have the second article of the series pretty much done by now. I only have to take the time to move it all to Wordpress (I prefer writing in Markdown). I'll start drafting the third article while I wait on some feedback for the first. I think it's going pretty well now.

@hartan This sounds like an excellent plan. Thanks for the update and keep us posted.

I can review it in this issue or offline. I helped with the original btrfs by default change proposal.

I just enabled a "public preview" link for this article: https://fedoramagazine.org/?p=36325&preview=1&_ppp=2b661d8cc5

I think that should be enough for you to review it. But these links do expire after a week or so. Just let us know with a comment here if we need to regenerate the link.

Edited 2 years ago by glb

I just skimmed the article myself. One thing that maybe could/should be worded a little more carefully is the idea that Btrfs copies "the file" on updates. That's not exactly true. It will only duplicate blocks that have changed. In some cases it won't copy/duplicate any data at all. Namely, when appending new data and the original file size was an exact multiple of the block size.

This sounds wasteful and in some circumstances it is, for example if you have virtual machines that perform a lot of I/O operations on their disk images. That is because any change to the disk image requires Btrfs to copy changed parts of the disk somewhere else.

Consider a less literal variation on copy-on-write: redirect. Instead of a modified block of data overwriting the original location, it's written to a new location, i.e. nothing is actually wasted. It's a write in either case. What is true about COW is that it's temporarily going to use more space, because old/stale blocks aren't freed until the transaction modifying a file is complete. A transaction consists of writing the modified data blocks, writing metadata blocks that point to the new/updated data, writing superblocks that contain the root trees that point to the updated metadata blocks. This actually applies to anything on a COW file system: new, modified, or deleted files result in a consumption of space because the writes are redirected to unused blocks, and only once that's successful are the old blocks freed.

This concept might be important to get across, because when talking about Btrfs snapshots and why they are so cheap, it's a bit more straight forward to describe the snapshot in terms of old blocks simply not being freed. They remain accessible via a snapshot. And it is the lack of freeing these blocks that is the cost of snapshot creation. It also helps explain that the cost of snapshots comes when deleting them: delayed garbage collected or a delay in finding blocks that need to be freed.

What is the advantage of CoW? In simple terms: You can keep a history of your modified and edited files.

While true if you use snapshots, you get a benefit of COW even if you aren't using snapshots. Since there's no overwriting, there's no such thing as partial updates to the file system in case of crash or powerfail. It doesn't matter if writes are interrupted, the file system remains consistent. If we're writing a bunch of data and the power dies, yes that data is lost but the previous superblock, the root trees it points to, and all the data pointed to by the file system metadata is completely intact as of the last successful transaction.

You can use special commands to recover versions of files that previously existed somewhere on your disk. But this is a cumbersome process since it will have to scan the whole disk for you.

This is true but I'd probably not give users the imagination that there's some incantation that'll let them get back files they've deleted, rather than backing up per usual. The problem with freed blocks is we don't know how soon those blocks will get written to again. It might be minutes or weeks. And on SSDs, every Monday we run fstrim.timer by default, which is going to tell the SSD to garbage collect all unused blocks - which will make those blocks read full of zeros. If the user has a snapshot regime, they can use plain old cp to copy the files out of a snapshot right back into their existing ~/ to restore the file.

Overall it's a good article.

https://en.wikipedia.org/wiki/Log-structured_file_system

@hartan, @chrismurphy do you think the following Wikipedia article would be a good reference to put at the end of the article for further reading?

I think it explains many of the concepts outlined in Chris' previous comment.

I would not introduce another concept or more jargon. Log structured file systems are different from copy-on-write. And also jargon wise it gets a bit more complicated because Btrfs is unique in that it's not only COW but also uses btrees. You get portions of trees modified, with a generation bump occurring each time, rather than a log that contains stale/obsolete file system information until there's a checkpoint with compaction to remove all the stale parts.

Edited 2 years ago by chrismurphy

I just skimmed the article myself. One thing that maybe could/should be worded a little more carefully is the idea that Btrfs copies "the file" on updates. That's not exactly true. It will only duplicate blocks that have changed. In some cases it won't copy/duplicate any data at all. Namely, when appending new data and the original file size was an exact multiple of the block size.

That is true of course, but this is more of a special case, don't you think? When the file was a multiple of the block size before the modification and we append more data at the end, we do in fact not change the data in the last block, we write to a new one in any case (even on non-CoW filesystems). Right?

Consider a less literal variation on copy-on-write: redirect.

I've read that in the Btrfs wiki before, but I don't understand what it tries to tell me. It said there that it's the right mindset when developing, but I don't see the magic behind that point of view. Does this come from the way disk I/O works? Since we read a block, then modify it in RAM, and then when we write it back that write is transparently "redirected" to some other free block on disk? In that case I agree it's the right mindset for developing, but I don't see how knowing this offers any benefit to the user beyond introducing more technical background knowledge. I just don't know where to "draw the line" in terms of assumptions about what the reader knows.

nothing is actually wasted.

That is an unlucky wording indeed. But one can argue that CoW filesystems are rather wasteful in that this behavior does cause file fragmentation, right? It doesn't matter on flash media, I know, but HDDs aren't dead yet. Maybe I should mention that?

This actually applies to anything on a COW file system: new, modified, or deleted files result in a consumption of space because the writes are redirected to unused blocks, and only once that's successful are the old blocks freed.

This concept might be important to get across

I agree, I had hoped the article did mention the idea. But I'll give it another iteration and try to emphasize this concept a little more.

Now about the superblocks and root trees: I'm familiar with the concept because I've had my fair share of theoretical lecture about filesystems, but I don't know if this is the sort of knowledge to bring across to the expected audience of this article series. I also didn't really mention what directory entries are, where they come from, etc. but I agree that it helps in understanding how snapshots work.

How should I solve this? I could try to bring the idea of directory entries across, all the way down to the filesystem root node. That is very likely a crude simplification from what Btrfs does, but I think it keeps the article readable for anyone that doesn't plan to start a career developing filesystems and it's the general case for CoW filesystems.

Since there's no overwriting, there's no such thing as partial updates to the file system in case of crash or powerfail. It doesn't matter if writes are interrupted, the file system remains consistent.

That, too, falls into the same category as above. As you already mentioned, all the FS structures down to the filesystem root node are updated on every transaction, and knowing that this is easily understood. I'll add it to the introduction, then.

On a related note @chrismurphy : Do you think the images help in explaining the concept? And: Is there some source to read up on Btrfs transactions? I know that Btrfs has the concept of filesystem generations, and I assume that generation number is bumped every nth transaction. Is that correct? And if so, what is n?

And on SSDs, every Monday we run fstrim.timer by default

Good to know. :)
I'll leave that out, then.

Thanks for the elaborate feedback @chrismurphy !

I just skimmed the article myself. One thing that maybe could/should be worded a little more carefully is the idea that Btrfs copies "the file" on updates. That's not exactly true. It will only duplicate blocks that have changed. In some cases it won't copy/duplicate any data at all. Namely, when appending new data and the original file size was an exact multiple of the block size.

That is true of course, but this is more of a special case, don't you think? When the file was a multiple of the block size before the modification and we append more data at the end, we do in fact not change the data in the last block, we write to a new one in any case (even on non-CoW filesystems). Right?

Yes, the case where none of the file's data is duplicated is a special case and you don't need to mention it. However, I'm worried that your original wording might leave the reader with the impression that the whole file is duplicated each time because you used the "the file" in a few places where, really, it's just a "the modified blocks of the file" that are being duplicated. I just don't want people to think that Btrfs is going to duplicate a whole 100 gigabytes of file data when only a few bytes of the file are changed.

we append more data at the end, we do in fact not change the data in the last block, we write to a new one in any case (even on non-CoW filesystems). Right?

This is application specific. e.g. Text Edit, every time you modify and save a file, writes out a new file and then does a rename to replace the old with new.

If an application requests overwriting some portion of a file, overwriting file systems honor that by overwriting the applicable block. Both data and metadata. Btrfs in the same case doesn't, it'll write data to a new block, write updated metadata to a knew block, then update the supers to point to the updated tree roots.

In technical writing there is always one or more rabbit holes. You're going down more rabbit holes by necessity so your reader doesn't have to.

Since we read a block, then modify it in RAM, and then when we write it back that write is transparently "redirected" to some other free block on disk?

Transparent to user space, yes. For Btrfs, it's intrinsic to the design for both metadata and data. I make that distinction because there is nodatacow (mount option and a per file attribute). Metadata updates for nodatacow files is still COW, only the data writes are overwrites.

Does this come from the way disk I/O works?

Maybe? A drive can internally have either overwrite or COW-like behavior, e.g. conventional hard drives (non-zoned) will overwrite sectors as commanded by the kernel's block driver. An SSD has limited ability to modify the contents of a cell, when it can't it does read-modify-write to a new cell, and updates an internal map between software facing LBA and the internal physical cell (and sectors in it). But in this latter case, the file system doesn't know anything about that. Zoned storage, the file system or some other software layer needs to know about the zones (e.g. btrfs host-aware zoned support, vs dm-zoned).

I'm not sure you need to bring this up at all, it really depends on where you're going next, how you intend to build the story line going forward. You want to be really deliberate with what you mention, i.e. if it's not going to come up again at all, then omit it now. If you plan to discuss intermediate or advanced Btrfs features, it might not be a bad idea to do rough outlines of those now These tend to be easier to write because you necessarily assume the reader has the background knowledge to absorb the advanced nature of the topic. Basic articles are harder to write. But advanced topics outlines can help you form a list of things you want your reader to know for future articles.

You can certainly push back on "redirected" and be more literal, e.g. "btrfs never overwrites in-use blocks."

Do you think the images help in explaining the concept?

Generally, visuals are good. I'm not very visual myself, but I think abstract technical topics can benefit from well thought images - even if they're using metaphor and aren't perfectly technically correct.

How should I solve this?

Decide if you want the user to understand the on disk format, versus use cases. If you want to make the series about technical details of Btrfs, then go with the former. If you care more about helping users identify some problem and how Btrfs can help, then emphasize use cases. You really can just gloss over technical detail entirely if you want.

And: Is there some source to read up on Btrfs transactions?

There are a few mentions in man 5 btrfs but it's pretty lightweight. There's a bit more:
https://btrfs.wiki.kernel.org/index.php/Btrfs_design
https://github.com/btrfs/btrfs-dev-docs

I know that Btrfs has the concept of filesystem generations, and I assume that generation number is bumped every nth transaction.

Generation is bumped every transaction or commit interval. There is a transaction with a sync, or the end of the commit interval. By default the commit interval is 30 seconds. Only changed items will get a generation bump A leaf block might contain 100 or so items, but only items with changes get an updated generation. The generation gets used for various kinds of runtime sanity checks, but also is central to how send/receive works with snapshots and why it's so cheap.

I just don't want people to think that Btrfs is going to duplicate a whole 100 gigabytes of file data when only a few bytes of the file are changed.

Right. It is actually tricky to explain what happens on disk in every case, but also tricky why the behavior is an advantage. Writing technical articles is much like file systems, there's always tradeoffs! It's the author who has weigh the tradeoffs.

It might be worth exploring the duplicate file question a bit more in a future article. I like the term "shared extent" to describe what happens when we create a reflink copy. And "extra name" when describing what happens when we create a hard link. When the user duplicates a file using either cp or GNOME Files, on Btrfs (and XFS) the data blocks are not duplicated. We get a reflink copy instead, or two inodes with the same extents (thus they are shared). It's also the same with subvolume snapshots, these instantly create many shared extents.

The trouble is that conventional CLI tools aren't familiar with shared extents yet so they're counted every time the tool comes across any reference to those extents.

Do you think the images help in explaining the concept?

Generally, visuals are good. I'm not very visual myself, but I think abstract technical topics can benefit from well thought images - even if they're using metaphor and aren't perfectly technically correct.

@hartan: If the images are not your own work, they will need proper accreditation.

@hartan: It doesn't look like this article has been modified since July 16th. Are you still working on this or do you want it to go out as it is?

If the images are not your own work, they will need proper accreditation.

@glb I'm aware, thanks for mentioning that. I painted the images currently in the article in Inkscape myself.

Also I'd like to work some more on this article and incorporate some of @chrismurphy s feedback (Thank you for the elaborate discussion!). I'm just a bit short on free weekens at the moment...

@glb @chrismurphy I gave the article another go and changed a few bits. In particular I am now taking more space to explain the CoW concept, both for files and folders (as a special type of file). This will be beneficial when explaining the snapshots later on in the series, because it heavily makes use of these terms and concepts. I also tried to clean up some other imprecisions discussed above.

As for the general scope: I decided that the articles will focus on use cases and empowering users to leverage btrfs features, rather than giving a lecture about filesystems and explaining technical details. Hence, I hope that I get the key selling points across better now... ?

I'd be very happy if you could give the article another read!

Could anyone post an updated link to the article? The earlier one has expired. Thanks.

https://fedoramagazine.org/?p=36325&preview=1&_ppp=9e8081d02d

No problem. Thanks for reviewing this Chris!

Edit: We should probably keep comments about the articles in their respective cards to make things easier to follow. Andreas has provided a link to the card for discussion about his second article below.

Edited 2 years ago by glb

For anyone that wants to follow the other articles in the series, I shared a preview to the second one (topic "Subvolumes") in #109.

Few quibble-suggestions

today (such as ~~mechanical~~ HDDs, SSDs, SD cards, etc…) is still mostly what it was

A block is typically ~~512 or~~ 4096 Bytes in size.

ext4,btrfs,xfs use 4K blocks on x86; although btrfs uses larger 16K metadata blocks by default. I think you can safely ignore this detail.

Below is an ~~hypothetical~~ example of what this ~~may~~ looks like:

look at the inode structure of ~~the ext4 filesystem~~ Btrfs linked below [1].

Just a suggestion to stick with Btrfs since that's the topic; but then I realize that the only link I have handy is for the on-disk inode format which is not that interesting. Not even the developers refer to this format day to day. Instead they use the btrfs inspect-internal dump-tree tool to show a more human friendly format.

On-disk format (not that interesting)
https://btrfs.wiki.kernel.org/index.php/Data_Structures#btrfs_inode_item

Human-readable dump-tree example from a VM of Fedora 36, nothing private or secret
https://pastebin.com/raw/52VCkbaF (2 week expiration)

That is a single 16KiB metadata leaf in the "root" subvolume (which is a file b-tree). What you're seeing are a bunch of items in that block, including multiple inode items. e.g. line 17 is the start of a file. What you think of as the inode would be items 3, 4, 5, 6. Those each refer to the same inode number, 19579. If you did an ls -li on this file you'd get 19579 for the first column. So lines 17-36 are the inode for this one file.

I'll see if I can get someone with btrfs wiki write access to add an example...

Btrfs users and developers often refer to this process as “redirection” because the file write is redirected to different storage blocks.

That might just be me :D Consider the following: In that sense, it might be simpler to think of COW as a kind of "redirection", because the file write is redirected to different storage blocks, rather than being overwritten.

You can keep a history of your modified and edited files. Older file version will hang around, unless your disk runs out of space and removes older copies to reclaim space. We can tell Btrfs to keep the references to the old file versions (inodes) somewhere we can explicitly access them.

This is a bit confusing. Maybe...

You can choose to keep older files by telling Btrfs to keep the references to them.

Without snapshots the blocks for stale/deleted file contents are freed up pretty quickly (few minutes) and are then subject to being overwritten. Since everything is COW on Btrfs, the snapshot is cheap, it doesn't results in additional writes. In effect, it prevents the freeing of blocks referenced in the snapshot. And the creation of the block references already happened, so by also not freeing/deleting) those metadata blocks, that's in effect how we have a snapshot. The cost of snapshotting is with modifying either the original subvolume or the snapshot and that's where you get that recursion you mention in "Copy-on-Write for folders" - the nature of copy on write.

That is because the filesystem metadata updates don’t occur until the end of a transaction.

Maybe something like That is because filesystem metadata updatse are also COW, the file system itself is never overwritten, so an interruption can't leave it in a partially written state.

~~(part 2 later, need to eat lunch)~~ Read the rest, no quibbles! Good job!

Edited 2 years ago by chrismurphy

@hartan Is there an update on this article after the last @chrismurphy comments?

@hartan is part one of your Btrfs series ready for publication?

@glb , @rlengland Sorry, I haven't gotten round to sitting down and editing this article again since @chrismurphy s last comment (and again: Thanks for your time and the feedback!). Also I won't be near a PC until around September 19th, so I'm afraid there won't be any progress in the meantime.

I must admit that writing these articles is much more involved than I had expected in the beginning. I really want to pull this through and publish the article series, I'll just need a lot of time to get there. I hope you bear with me... I'll report back when there are any more changes to be reviewed, although I think that given the last batch of comments, the article will be finished the next time I report back.

@hartan Take the time you need to do a good job. We'll be here when you are ready.
(and we'll do our best not to hassle you until you report back :smile: )

Okay, it is done now.

I have added the "quibble-suggestsions" by @chrismurphy (Thank you very much!) and read through the whole article again. I'm very happy with the current state, and "Yoast" doesn't see much wrong with it either.

Regarding the inode structure: I decided to link to the btrfs on-disk format and solve the "problem" like this:

If you want to know more about this, have a look at the inode structure of the btrfs filesystem linked below [1]. For a more detailed explanation of what the individual fields mean, you can refer to the inode structure of the ext4 filesystem [2].

So, what happens next, then?

@hartan Your article should go "live" on 5 Oct. The edits I did were pretty minor but feel free to read over it if you wish. I've also created a feature image for it that I hope we can use in the next 2 articles simply replacing part of the text.

Let us know if you have changes or questions about anything.

Looking forward to the next installment!

Edited 2 years ago by rlengland

@rlengland:

A block is typically 4096 Bytes in size.

I don't think "Bytes" is a proper noun. Shouldn't it be "bytes"?

This includes the files size, where to find the storage blocks that make up the file contents, it’s access rules ...

Should that be the possessive s (i.e. "the file's size")? Also, I think "it's" should be "its" in this case.

... has big implications on a filesystems capabilities ...

Again, I think that should be the possessive s ("filesystem's").

When we change a file ...

I know I'm being nit picky, but this looks like it would be easy to reword to avoid the use of "we". How about "When a file is changed ..."?

... you will likely hardly notice at all.

There are perhaps a few too many adjectives here. How about "... it is unlikely you will notice the difference."

We can choose to keep a history of your modified and edited files. We can tell Btrfs to keep the references to the old file versions (inodes) somewhere we can explicitly access them.

Again, it would probably be good to avoid the use of "we" in contexts such as this. Readers might read that as "[Fedora] can choose to keep a history of your ... files" and "[Fedora] can tell Btrfs to keep the references ... somewhere [Fedora] can explicitly access them." Some readers could think that articles on "fedoramagazine.org" are speaking on behalf of the Fedora Project when the word "we" shows up in the article. We (the editors for Fedora Magazine) should try to avoid such a misunderstanding. I think it would be better if these cases of "we" were substituted with "you" (or reworded to avoid the use of pronouns all together).

Also, do you perhaps mean "easily access them" instead of "explicitly access them"?

btrfs creates

*Btrfs

... appended 3 more bytes at the end.

"more" is probably redundant in this case.

btrfs will reclaim

*Btrfs

From a filesystems point of view ...

*filesystem's

Also, it looks like there is some inconsistency with the casing of "Copy-on-Write"/"Copy-on-write"/"copy-on-write". I'd probably go with the first form and use that consistently throughout the article.

Also, the footnote links ([1], [2], etc.) don't seem to be working properly. Maybe it is because I'm viewing it through the preview link. I'm not sure.

These are just my opinions. Please feel free to take them or leave them. 🙂

@glb I think I've amended the article with your suggestions. I believe the footnotes will work now. I removed some extra text blocks and it removed the anchor the [x] links pointed to. They linked to the "Sources" section at the end of the article.

Hey @rlengland and @glb,

thanks for adding the suggestions already!
I wasn't expecting things to move that quickly now. But don't get me wrong, I'm totally fine with it. :-)
I just saw it today and I can't seem to view the article any longer - is that on purpose? It says it's in "Public Review", but I don't find a link or anything.

Also I assume I should stick around to answer potential comments once the article is released? Will I get notified when new comments arrive, or what exactly is the procedure for that?

Thanks for guiding me through the process, providing feedback and sticking with me until the end. And thank you @chrismurphy for all the technical feedback!

https://fedoramagazine.org/?p=36325&preview=1&_ppp=9b37cbf9d3

Annoyingly, once it is scheduled, the original author loses access to it. I'll move it back to draft status and update this card with the current preview link. I'll also (try) to remember to re-schedule it before the deadline.

Also I assume I should stick around to answer potential comments once the article is released? Will I get notified when new comments arrive, or what exactly is the procedure for that?

It would be great if you can respond to comments. You should get email notifications when they are submitted. The emails will also contain links to approve the comments, but I don't think those links work. You might be able to approve comments by logging into the admin interface directly. But I'm not sure. Some have said it works. Others have said that it does not.

Edited 2 years ago by glb

I just made a small correction. I think Richard misunderstood what I was saying when I suggested that "we" be removed in a few of the sentences. It is not "Fedora" that decides whether or not to make and keep snapshots. It is the user.

Thank you @glb !

I noticed in this sentence:

As a consequence, as long as a reference is kept to any of the old directories and are not deleted or overwritten,

Since we talk about a single reference, shouldn't it be "and is not deleted ..."?

Apart from that the article looks very good!

I read this as referencing directories as plural so I've modified the text as follows:

"... as long as a reference is kept to any of the old directories and they are not deleted or overwritten, ..."

If this is incorrect, please modify as necessary.
Thanks

@rlengland

The added "they" makes it clear, thanks!

It's good to go now, please schedule it for release tomorrow again.

Hi @glb and @rlengland,

I think the feedback on the article is mostly positive so far, which makes me very happy. However, while I do get email notifications about moderating the comments, I cannot seem to perform any actions on the comments inside wordpress. Is that on purpose, or am I just missing the buttons? I go to "Notifications", and the hit the little speech bubble icon, which opens up all the comments to my article so far. I can see the ones on moderation, but I cannot "accept" them or anything. What do I have to do?

Thanks in advance!

I guess it only works if you have full access to edit everything then. Sorry. We'll have to look into the permissions someday and try to figure out why it doesn't let the author approve the comments to their article. For now, I think you'll just have to wait until one of the editors handles it.