Re: PSA: Somehow, without action from me, hyberfile.sys got turned on

...w¡ñ§±¤ñ wrote:
>   Just like your device, there are reports of this same 'cheesy' occurrence.
>   But when you ask IT admins(managing 100,000+ devices) and MSFT 
> developers if(its) reproducible and validated without user or admin 
> intervention,  the answer is no.
>   User Intervention = anything the user/admin does to create the 
> condition(enable hibernation, reset the device to factory, 
> install/reinstall Windows[clean, repair, in-place - the latter two not 
> choosing to keep settings] and/or installation 3rd party software or 
> hardware).

Hi Winston,

I do appreciate your help and advice. 
I just wanted to be firm that I didn't do anything overtly.

The disk dried up right in front of my very eyes.

Apparently Windows "Self-Healing" detected the low-space/power-policy
inconsistency and triggered a reset of the power configuration to defaults.
This recreated hiberfil.sys, which demanded a contiguous block of space
that didn't exist, hard-locking the drive at 0 bytes.

It happened again just now. Right in front of my very eyes.
And it was NOT the hiberfile.sys that did it this time. 

Go figure. 

To be clear, a critical issue is that my old 1TB drive only has about 3GB
left, so a lot of Windows things fail when they can't find enough space.

For example, today my drive suddenly dropped to 0 again, and it wasn't the
operating system turning on hibernation (by that lovely OOTB experience).

Guess what failed just now?
Brave.

I checked the Change Journal (USN Journal), which records every file
modification and it was flooded with seemingly millions upon millions of
entries for Preferences.tmp, History-journal and LOG.old located in
%LOCALAPPDATA%\BraveSoftware\.

Huh?

You can watch this happen in real time:
 C:\> fsutil usn readjournal C:

It turns out Chromium browsers use "Atomic Writes" in that they create a
.tmp file, write data, and then rename/replace the original. Because the
disk was at >99% capacity, the mechanical HDD latency caused these writes
to stutter or timeout. Brave "panicked" and retried the operation thousands
of times per second. Even if the files themselves weren't saving, NTFS
recorded every single failed attempt in the Journal. The Journal metadata
expanded to several gigabytes just to keep track of the chaos, eating the
final 3GB of free space instantly.

Jeez Louise. You'd think developers would fix this garbage coding.
What was my fix this time?

1. Kill the Loop
   C:\> taskkill /F /IM brave.exe
        (Stops the forever metadata)
2. Flush the Metadata
   C:\> fsutil usn deletejournal /D C:
        (reclaims space eaten by the journal)
3. Rebalance the Load
   C:\> move C:\data\{stuff} F:\{another disk}
        (frees up about 10% to 15% free space on C:)
4. Defrag (but only when there's enough free space of 100GB to 150GB)
   C:\> defrag C: /U /V 
   or... 
   C:\> defrag C: /U /V /X (one big contiguous chunk)
   No need for "O" on an old system but use it for an SSD.

BTW, when was the last time you heard the word "defrag". 
Shades of 1990!

Moral of the story (other than to buy a bigger disk) is... 
 "If your space vanishes and DIR doesn't show where it went, 
  check your USN Journal. Your browser might be screaming 
  into the file system's "diary" until the diary itself 
  fills the disk."

A "clean system" isn't just about deleting temp files.
It's about maintaining free space geometry too. :)