Я не могу воспроизвести симптом, который у вас есть при доступе к серверу SMB на Mac. Поскольку Samba работает в обратном направлении (Mac к Linux), используйте что-то другое для доступа к Mac.
Здравствуйте и добро пожаловать на форум!
Возможно, стоит рассмотреть возможность того, что ваша проблема не в DNS, может быть, что ваше сетевое соединение просто ненадежно по какой-либо причине, что некоторые пакеты теряются. О том, что ssh сеансы выживают, нам мало что говорит, потому что ssh сеанс использует TCP так, что может работать, даже если много пакетов потеряно. DNS, с другой стороны, использует UDP, поэтому если некоторые UDP-пакеты (входящие или исходящие) потеряны, это может привести к сбоям DNS.
Тестирование с использованием ping, как вы сделали, является хорошей идеей, может быть стоит сделать больше из этого, например, ping чаще, что раз в секунду, чтобы увидеть, есть ли иногда потери пакетов и если время этого коррелирует с проблемами DNS. Также стоит отметить, что ping включает в себя другой протокол (ICMP), может случиться, что есть какая-то проблема с UDP, но что ping работает в любом случае. Тогда, возможно, стоит запустить тесты с использованием UDP, что можно сделать, например, с помощью инструмента iperf3 .
Если вы сами управляете DNS-сервером, то вы можете следить за этим, чтобы увидеть, поступает или нет DNS-запрос, и увидеть, послан ли ответ с DNS-сервера.
Вы также можете попробовать отслеживать входящий и исходящий сетевой трафик локально, используя что-то вроде tcpdump или tshark , чтобы убедиться, что DNS-запрос отправлен, и проверить, можно ли увидеть ответ от DNS-сервера.
В любом случае это некоторые идеи, я надеюсь, что некоторые из них могут быть полезны. Удачи!
Для начала, чтобы пересказать другой ответ, вы можете легко увидеть все содержимое ext4.vhdx , просто запустив WSL и посмотрев на файлы. Например:
будут найдены все файлы в файловой системе ext4 , подключенной как root (/), но не файлы на подключенных дисках NTFS/Windows ( -xdev исключает другие файловые системы).
Вы также можете видеть места хранения, используемые этими же файлами:
sudo du -hdx
Если эта сумма отличается от размера файла ext4.vhdx , то да, как вы уже подозреваете, у вас, вероятно, есть неиспользованное пространство. Как вы упомянули в вашем вопросе, WSL будет увеличивать этот файл по мере необходимости, но не будет автоматически сокращать его при удалении файлов.
Чтобы вручную сжать файл,вы можете выполнить любой из шагов, упомянутых в данном ответе суперпользователя . Вот один из них, скопированный из ссылочного комментария Github:
Примечание: Альтернативным способом прямого доступа к vhdx было бы раскручивание новой виртуальной машины на базе Linux на Hyper-V и добавление этого виртуального диска (или его копии) в экземпляр. Невозможно проверить его непосредственно в Windows, так как Windows не понимает файловую систему ext4.
WSL2 создает виртуальный диск в формате .vhdx, который хранит файлы гостевой операционной системы. Это включает в себя в том числе Docker-образы, скачиваемые для запуска контейнеров. С течением времени размер диска сильно растет и начинает отъедать полезное место на диске C:.
WSL2 не поддерживает высвобождение места на виртуальном диске, поэтому делать это нужно вручную.
Для начала удаляем неиспользуемые Docker-образы:
А также выполняем удаление неиспользуемых системных пакетов:
apt-get clean
apt-get autoclean
apt-get autoremove
76.84GB высвободилось на виртуальном диске. На диске C: 76.84GB все еще недоступны для пользования.
Ситуация исправляется следующим образом. Открываем PowerShell с правами администратора и выполняем:
То же самое проделываем для диска Docker:
Ура, на диске C: появились 76.84GB и даже больше.
May 13, 2022 · wsl, windows
