I don't know which filesystem was used. But if ext4 was used, it will be one of reasons. When you random write on ext4, and then do fsync, ext4 fast commit (introduced in 5.10) will combine them into a whole range from the lowest address to highest address, so it will sync far more data from actual modified data for random write. And even worse, if the range is larger than EXT4_FC_SNAPSHOT_MAX_RANGES, it will fallback to old full commit behavior and got worse result. There is a patch to fix this issue but it's still not merged.
https://lore.kernel.org/all/20260730003715epcms2p54b7e3cc340...
Author here - Just wanted to add this Disclaimer: AI was used extensively here, both to debug the cluster and to write this article.
I support responsible use of A.I
I understand the discourse around Slop/Vibe code etc… Personally as long as the slop / vide code does the job securely, reliably and is maintainable does not matter if you hand write the code or use A.I. I prefer to use all the tooling available to me build things.
The fact that you posted here means that you want people to read your article. Yet you don't have the will to write the article yourself. Honestly, would have been a good read but after about reading 30% of it earnestly, it just felt like a padded article (filled with the usual AI-isms such as "[comma] the marketing is real") that you could have written better.
The problem with using AI to write it is that you are under no pressure to to maintain brevity. Maybe not a bad thing when you need a guide but in this case it just made it harder to read
Thank you for the feedback. Of course I do want people to read. The whole point of posting this here or anywhere is so that if anyone, who is in the similar situation can jump to the TLDR or conclusion and fix it will save them some time.
Not the entire article is A.I. generated A.I. articles are longer but ideas can be conveyed in different ways. I chose to convey in the way I felt best. The article went through multiple human reviews and in future if I decide to write an article brevity will be in my mind when writing longer articles. I do feel like the world now prefers short form content over long.
I don't know which filesystem was used. But if ext4 was used, it will be one of reasons. When you random write on ext4, and then do fsync, ext4 fast commit (introduced in 5.10) will combine them into a whole range from the lowest address to highest address, so it will sync far more data from actual modified data for random write. And even worse, if the range is larger than EXT4_FC_SNAPSHOT_MAX_RANGES, it will fallback to old full commit behavior and got worse result. There is a patch to fix this issue but it's still not merged. https://lore.kernel.org/all/20260730003715epcms2p54b7e3cc340...
Author here - Just wanted to add this Disclaimer: AI was used extensively here, both to debug the cluster and to write this article.
I support responsible use of A.I I understand the discourse around Slop/Vibe code etc… Personally as long as the slop / vide code does the job securely, reliably and is maintainable does not matter if you hand write the code or use A.I. I prefer to use all the tooling available to me build things.
The fact that you posted here means that you want people to read your article. Yet you don't have the will to write the article yourself. Honestly, would have been a good read but after about reading 30% of it earnestly, it just felt like a padded article (filled with the usual AI-isms such as "[comma] the marketing is real") that you could have written better.
The problem with using AI to write it is that you are under no pressure to to maintain brevity. Maybe not a bad thing when you need a guide but in this case it just made it harder to read
Thank you for the feedback. Of course I do want people to read. The whole point of posting this here or anywhere is so that if anyone, who is in the similar situation can jump to the TLDR or conclusion and fix it will save them some time. Not the entire article is A.I. generated A.I. articles are longer but ideas can be conveyed in different ways. I chose to convey in the way I felt best. The article went through multiple human reviews and in future if I decide to write an article brevity will be in my mind when writing longer articles. I do feel like the world now prefers short form content over long.