Defrag.exfat Is Inefficient and Dangerous
1–10 of 14 posts
Re: Defrag.exfat Is Inefficient and Dangerous
#2>After reviewing the core defrag logic myself, I've come to a conclusion that it's AI slop.
Will call it a human slop. AI may've given them some code but they certainly haven't use it fully. I uploaded the defrag.c in ChatGPT asking to review on performance/correctness/safety and pointed the sames issues as you (alongside bunch of others but not interested at the moment to review them).
Re: Defrag.exfat Is Inefficient and Dangerous
#3Sigh. Piss poor engineering, likely by humans. For the love of god, do atomic updates by duplicating data first such as in a move-out-of-the-way-first strategy before doing metadata updates. And keep a backup of metadata at each point of time to maximize crash consistency and crash recovery while minimizing the potential for data loss. An online defrag kernel module would likely be much more useful but I don't trust them to be able to handle such an undertaking.
If a user has double storage available, it's probably best to do the old-fashioned "defrag" by single-threaded copying all files and file metadata to a newly-formatted volume.
Re: Defrag.exfat Is Inefficient and Dangerous
#4>After reviewing the core defrag logic myself, I've come to a conclusion that it's AI slop. Will call it a human slop . AI may've given them some code but they certainly haven't use it fully. I uploaded the defrag.c in ChatGPT asking to review on performance/correctness/safety and pointed the sames issues as you (alongside bunch of others but not interested at the moment to review them).
Talk about a baptism of fire for the dev.
Seems like they are very new to tbings and didn't expect it to be adopted, but were hoping for a bit of feedback.
Re: Defrag.exfat Is Inefficient and Dangerous
#5>We prioritized simplicity and correctness first, and plan to incrementally introduce performance optimizations in future iterations.
Sir, this is a correctness issue.
Re: Defrag.exfat Is Inefficient and Dangerous
#6Does nobody else think the responses from the person who wrote the code read like the usual sycophantic “you’re absolutely right!” tone you get from AI these days?
Re: Defrag.exfat Is Inefficient and Dangerous
#7Does nobody else think the responses from the person who wrote the code read like the usual sycophantic “you’re absolutely right!” tone you get from AI these days?
There at least 2 AIs.
Re: Defrag.exfat Is Inefficient and Dangerous
#8Sigh. Piss poor engineering, likely by humans. For the love of god, do atomic updates by duplicating data first such as in a move-out-of-the-way-first strategy before doing metadata updates. And keep a backup of metadata at each point of time to maximize crash consistency and crash recovery while minimizing the potential for data loss. An online defrag kernel module would likely be much more useful but I don't trust…
That last paragraph sums up the ZFS defrag procedure at one shop I worked at. Buy new disks and send/receive the pool.
At our size and use case the timing was usually close to perfect. The pools were getting close to full and fragmented as larger disks became inexpensive.
Re: Defrag.exfat Is Inefficient and Dangerous
#9Re: Defrag.exfat Is Inefficient and Dangerous
#10>After reviewing the core defrag logic myself, I've come to a conclusion that it's AI slop. Will call it a human slop . AI may've given them some code but they certainly haven't use it fully. I uploaded the defrag.c in ChatGPT asking to review on performance/correctness/safety and pointed the sames issues as you (alongside bunch of others but not interested at the moment to review them).
I did the same. Was genuinely curious. Didn't get much from it. I'm still confused.
The code base is huge for an LLM to handle, perhaps it was generated over multiple prompts idk. Not sure if someone can train a model on the kernel code or exfatprogs and generate the code. I doubt someone with such expertise would even go through the process when they can just write the code themselves which is much easier.