1. Крок: Дізнайтеся, яка проблема у вас є насправді
Коли ваша файлова система несподівано наповнена, існує маса можливих причин. Дивіться відповідь Іллі Кагана детальніше про це. У переважній більшості випадків слід легко визначити (і врешті-решт виправити) справжню причину, тому переформатування / перевстановлення не було б необхідним.
Отже, перший крок - з’ясувати, у чому саме проблема, тобто куди пропав пропущений простір. Тож спочатку виконуй
df -hl -x tmpfs -x devtmpfs
Тут відображається перелік усіх використаних розділів дисків у вашій машині, їх розмір, наскільки вони наповнені та їх місце монтажу. З цього списку візьміть той, який, на вашу думку, занадто повний, і відзначте його точку кріплення. У вашому випадку це коренева файлова система, на яку встановлено /
.
Тепер ми аналізуємо, де всередині цієї файлової системи використовується простір. Виконати
sudo du -xhsc /* 2> /dev/null
(Замініть /
вказану вище точку монтажу.) Для цього потрібен sudo, оскільки не всі каталоги можуть бути читатими для вашого користувача. Це може зайняти деякий час (особливо у великих файлових системах), оскільки йому потрібно відвідувати кожен окремий каталог у них.
Ця команда робить, щоб показати вам кожен файл і каталог всередині даного каталогу разом з його розміром (включаючи підкаталоги). Тож із цього списку візьміть ті, які, на вашу думку, є більшими, ніж повинні бути, та знову зателефонуйте команді в цей каталог. (Тобто, запустіть команду ще раз, але замініть ім'я великого каталогу з попереднього списку /
.)
Наприклад, у вашому випадку було зрозуміло, що /var
це єдиний великий каталог, тому вам потрібно буде виконати
sudo du -xhsc /var/* 2> /dev/null
Продовжуйте виконувати ці кроки, поки ви не знайдете жодного великого файлу, або не знайдете каталог з великою кількістю файлів, який разом займає весь цей простір.
У вашому випадку наступним кроком було виконання
sudo du -xhsc /var/log/* 2> /dev/null
тому що він /var/log
був настільки великий, і це показало вам, що був один файл журналу з іменем uvcdynctrl-udev.log
174 ГБ (що, очевидно, погано).
2. Крок: Визначте, чому файли існують і чому вони такі великі
Тепер нам потрібно з’ясувати, чому ідентифіковані є, або чому вони такі великі, якщо їх очікують там.
У вашому випадку файл журналу /var/log
не є нічого підозрілим, але його розмір, безумовно, є. На щастя, пошук Google просто з назвою файлу відображає наступний звіт про помилку як перше звернення, що, очевидно, та сама проблема, що і ми: http://bugs.launchpad.net/ubuntu/+source/libwebcam/+bug / 811604
3. Крок: Розв’яжіть задачу
У цьому випадку файл журналу деяких матеріалів, пов’язаних із веб-камерою, здається не цікавим, тому ми можемо легко видалити його командою sudo rm /var/log/uvcdynctrl-udev.log
та звільнити весь простір.
На жаль, звіт про помилку все ще відкритий, і в коментарях немає рішень чи шляхових вирішень, тому вам, мабуть, зараз доводиться жити з цією помилкою. Ви можете час від часу видаляти файл журналу, щоб звільнити місце.