Comment by segfaultbuserr | Hacker News Reader

Comment by segfaultbuserr | Hacker News Reader

Parent Full thread

> outsourced foreign support rep telling the user to run sfc /scannow

Sysadmin story. Recently I had a really strange problem after a disk migration - defrag.exe simply would not run no matter what (I needed it to TRIM the SSD), it just quits without any messages, as if it's /bin/false. GUI had the same problem.

The first search result was a thread at answers.microsoft.com, they give the same canned "sfc /scannow, dism /restorehealth, chkdsk /f" response. But OP finally solved the problem on their own, the "Optimize Drives" service was somehow been stopped, restarting it solved the problem. I tried it, it didn't work. Having no options, I decided to give the seemingly useless solution a shot (why did I bother to try? This was after a disk migration, I felt filesystem corruption could be real). It finally worked after "chkdsk /f"...

I was genuinely impressed. It was the first time ever that it actually fixed a real problem for me. Presumably defrag.exe detected a filesystem anomaly and refused to run.

> defrag.exe simply would not run no matter what (I needed it to TRIM the SSD)

Would be interested in the logic here, given that it runs counter to what I thought was extremely obvious advice by now.

Defrag generates writes to rearrange blocks in the _virtual_ view of storage visible to the OS, but even after defragmentation, the _physical_ placement is totally outside the control of anything except the firmware. If after defragmentation a file's blocks are arranged (0, 1, 2, 3) in the OS-visible view, in flash are still very likely to to be arranged (412, 77, 1, 12341, 5) etc. All you can do is let it know that some range of sectors is not used, which is what TRIM enables, and that does not require defragmentation upfront.

> All you can do is let it know that some range of sectors is not used, which is what TRIM enables, and that does not require defragmentation upfront.

This is exactly what defrag.exe does on an SSD today. Since Windows 10 (or 8?), instead of doing a "real" defrag, defrag.exe also has an option to issue TRIM commands to unused blocks on an SSD. In other words, it works like fstrim(1). The time has changed and you must have missed the update. I suggest keeping your knowledge up-to-date before delivering a lecture on disk defragmentation on a forum where everyone should've known better.

https://docs.microsoft.com/en-us/windows-server/administrati...

> /d Perform traditional defrag (this is the default).

> /l Perform retrim on the specified volumes.

> /o Perform the proper optimization for each media type.

Since I migrated the hard disk using a block-level copy via "dd", it's a good idea to manually TRIM the disk afterwards to inform the controller about the unused blocks in the new filesystem for proper wear leveling (to the controller, the block-level copy looks like a single large file).

And before another one gives me another lecture: No, I did not corrupt the filesystem because I made the mistake of copying the disk while Windows was still in Fast Startup mode. It was probably ntfsresize(8), to be fair, the corruption was extremely minor.

Thanks for the excellent explanation, but the attitude and needless personalization was unnecessary. This functionality was previously available via the Optimize-Volume cmdlet, I guess it makes sense the defragmenter was updated with similar functionality to account for the typical Windows user.

Reply on news.ycombinator.com