WSL1 проти WSL2: один пінгвін, два зовсім різні рахунки за диск

WSL1 і WSL2 однаково дарують Linux-термінал на стільниці Windows, але зсередини один — шар трансляції, а другий — віртуальна машина, і слід на диску в них улаштований зовсім по-різному. Якщо системний диск тихо втратив 30–50 ГБ, майже напевно вони пішли в ext4.vhdx дистрибутива WSL2.

Дві архітектури — дві моделі зберігання

У WSL1 ядра Linux немає взагалі: система транслює системні виклики Linux у виклики Windows на льоту, а файли лежать у звичайній папці — історично %LOCALAPPDATA%\Packages\<Distro>\LocalState\rootfs — цілком видимій засобам Windows. Тому вона легка на диску й швидка, коли скрипти ходять по /mnt/c, але трансляція неповна: Docker, systemd і все, що потребує екзотичних викликів, не працює. WSL2 крутить справжнє ядро Linux у легкій службовій віртуалці, що лагодить сумісність, але вся файлова система дистрибутива тепер живе всередині ext4.vhdx — віртуального образу диска, який Windows підключає, але не розуміє.

Vhdx лежить у %LOCALAPPDATA%\Packages для дистрибутивів із Store і в %LOCALAPPDATA%\wsl для новіших установок, і в нього одна погана риса: він росте на вимогу і сам ніколи не зменшується. Видалення файлів усередині дистрибутива звільняє місце у віртуальному диску, але файл .vhdx тримає свою максимальну позначку, поки ви не стиснете його вручну. Подивитися розмір файла у «Проводнику» одразу після великого чищення всередині дистрибутива — класичне розчарування: цифра не зрушилася.

Де кожен із них ховає гігабайти

Жодна версія за собою не прибирає, і місце витікає у напрочуд небагато місць:

ext4.vhdx у WSL2 — у кожного дистрибутива свій; сетап із Docker спокійно доводить його за 30 ГБ
Власний диск даних Docker Desktop (docker_data.vhdx) із тим самим правилом «тільки рости»
Папка rootfs у WSL1 — скромна на тлі, але покинуті старі дистрибутиви тримають повну установку
Кеші пакетів і збірок усередині дистрибутива — apt-кеші, node_modules, каталоги target/ і build/, що роздувають vhdx назавжди
Бекапи wsl --export і звантажені образи дистрибутивів, забуті у «Завантаженнях»

Повертаємо місце, не зламавши дистрибутив

Спершу приберіться всередині: apt autoremove і apt clean, docker system prune у Docker Desktop, чистка кешів npm і pip — усе, що спорожнює віртуальний диск до стиснення його контейнера. Потім виконайте wsl --shutdown: працюючий дистрибутив блокує свій vhdx. Далі стискайте образ: Optimize-VHD з параметром -Mode Full, якщо стоїть інструментарій Hyper-V, або diskpart із командами select vdisk file="<шлях>", attach vdisk, compact vdisk, detach vdisk на будь-якій Windows. Свіжі версії WSL уміють wsl --manage <Distro> --set-sparse true: vhdx починає віддавати місце автоматично, і в довгу це справді кращий режим.

Два крайні засоби заслуговують на свої імена. Команда wsl --export пакує дистрибутив у .tar, який можна розгорнути на іншому диску через wsl --import — це чистий спосіб забрати установку WSL2 з переповненого C:. А wsl --unregister <Distro> видаляє дистрибутив разом із його vhdx цілком, відкату в команди немає, тож ставтеся до неї як до ядерної. Заодно обмежте апетит віртуалки файлом .wslconfig із лімітами пам'яті та процесорів: інакше простіюча WSL2 тримає гігабайти оперативки просто так.

Питання та відповіді

Як зменшити файл ext4.vhdx у WSL2?

Спершу почистіть усередині дистрибутива, виконайте wsl --shutdown, потім стисніть vhdx через diskpart (select vdisk file, attach vdisk, compact vdisk, detach vdisk) або Optimize-VHD. На свіжому WSL команда wsl --manage <Distro> --set-sparse true вмикає авточистку місця.

Що вибрати: WSL1 чи WSL2?

WSL2 — варіант за умовчанням і єдиний для Docker, systemd та всього, чому потрібне справжнє ядро. WSL1 лишається кращим для легкої роботи в консолі з файлами на віндових дисках: без віртуалки, без vhdx і без апетиту до пам'яті.