Defrag.exfat Is Inefficient and Dangerous • Hacker News Board

Re: Defrag.exfat Is Inefficient and Dangerous

#11

Post by dxdxdt » Sun, Dec 14, 2025, 4:17 AM UTC

burnt-resistor wrote: post #3

Sigh. 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…

Yeah. Pretty much.

Read the defrag code in other well-established fs like ext4 or btrfs. They all have limitations(or caveats, if you will). It's one of those problems where you just have to throw money at it and hope for the best. Even Microsoft kinda just gave up on it because it's really a pointless exercise at this point in time and age.

Re: Defrag.exfat Is Inefficient and Dangerous

#12

Post by forgotpwd16 » Sun, Dec 14, 2025, 11:43 AM UTC

dxdxdt wrote: post #10

forgotpwd16 wrote: post #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).

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.

Multiple prompts are mandatory for anything non-trivial or/and larger in scope. That said, the exfatprogs repo is ~60k tokens (in 8k LOC) and Linux's exfat driver* is ~40k tokens (in 6k LOC). So directly relevant code is ~100k tokens (in 14k LOC). Not that extensive.

>Not sure if someone can train a model on the kernel code or exfatprogs and generate the code.

They can certainly finetune such a model. Not a crazy idea, just computationally expensive. (But less expensive than training from scratch.)

*Of course Linux driver also uses many includes so if consider those alongside linked code the number goes significantly up.

Re: Defrag.exfat Is Inefficient and Dangerous

#13

Post by dxdxdt » Sun, Dec 14, 2025, 12:51 PM UTC

forgotpwd16 wrote: post #12

dxdxdt wrote: post #10

Earlier quoted context omitted.

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.

Multiple prompts are mandatory for anything non-trivial or/and larger in scope. That said, the exfatprogs repo is ~60k tokens (in 8k LOC) and Linux's exfat driver* is ~40k tokens (in 6k LOC). So directly relevant code is ~100k tokens (in 14k LOC). Not that extensive. >Not sure if someone can train a model on the kernel code or exfatprogs and generate the code. They can certainly finetune such a model. Not a crazy ide…

> just computationally expensive. (But less expensive than training from scratch.)

Model training requires GPUs w/ 1kW TDP. I can shit out code on noodles and red bulls. Not sure about the quality, but still way less energy :)

Jokes aside, the defrag program probably was a slob to some extent.

Re: Defrag.exfat Is Inefficient and Dangerous

#14

Post by rcxdude » Sun, Dec 14, 2025, 1:04 PM UTC

zapzupnz wrote: post #6

Does 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?

It's plausible that they are using an LLM for translation, which would create the tone but not necessarily mean that they are delegating all thought to it.