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 do feel like the world now prefers short form content over long.
There is plently of long form content that upvoted on HN. I think the difference is when people feel like it is short form content with padding. AI is good as creating noise, so you have more words without having more to say.
Hence the criticism.
I'm starting to deal with "AI written requirements". They think it is so much better because it has more words, but it's just longer to read without adding anything meaningful. People don't like feeling like they've waisted their time on something that could have been a 140 char tweet.
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 do feel like the world now prefers short form content over long.
There is plently of long form content that upvoted on HN. I think the difference is when people feel like it is short form content with padding. AI is good as creating noise, so you have more words without having more to say.
Hence the criticism.
I'm starting to deal with "AI written requirements". They think it is so much better because it has more words, but it's just longer to read without adding anything meaningful. People don't like feeling like they've waisted their time on something that could have been a 140 char tweet.