Перейти до

Help! df: Avail -4,9G. Система не видит свободное место


Рекомендованные сообщения

Всем привет!

Попался на удочку файлового менеджера mc.

При попытке скопипастить большой файл по сети, он уперся в нехватку места в корне диска, и после этого в системе показывает, что нет места.

> df -h
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/root     62G     62G   -4,9G   109%    /

ОС: FreeBSD

# find / -size +1G 

тоже ничего не выдал.

 

Ребут не помогает.

 

sync, fsck кто-то на других форумах рекомндует, но не вижу толку.

 

 

Ссылка на сообщение
Поделиться на других сайтах

Утилита ncdu установлена?

 

Если нет, то попробуйте следующее:

du -h / | grep G

Найдете файлы больше 1GB.

Также, скорее всего, найдется несколько лог-файлов большого размера. Можете их удалить, освободив тем самым необходимое место в 5-6 ГБ. После этого установите ncdu и разберитесь, что именно "ест" место.

В связи с нехваткой дискового пространства некоторые демоны могли остановить свою работу. После освобождения дискового пространства запустите их вручную, либо же перезагрузите сервер.

Ссылка на сообщение
Поделиться на других сайтах

ничего не дало

# du -h -d 1 /
4.0K	/.snap
3.5K	/dev
8.1M	/rescue
6.6M	/sbin
276K	/libexec
 36K	/tmp
4.0K	/mnt
241M	/var
144K	/root
4.0K	/proc
2.9M	/etc
3.7G	/usr
1.2M	/bin
488M	/boot
4.0K	/media
9.6M	/lib

Ссылка на сообщение
Поделиться на других сайтах

Утилита ncdu установлена?

 

Если нет, то попробуйте следующее:

du -h / | grep G

Найдете файлы больше 1GB.

Также, скорее всего, найдется несколько лог-файлов большого размера. Можете их удалить, освободив тем самым необходимое место в 5-6 ГБ. После этого установите ncdu и разберитесь, что именно "ест" место.

В связи с нехваткой дискового пространства некоторые демоны могли остановить свою работу. После освобождения дискового пространства запустите их вручную, либо же перезагрузите сервер.

ncdu сейчас попробую. Система буквально только установлена, то есть еще ничего не делала.

Ссылка на сообщение
Поделиться на других сайтах

 

ничего не дало

# du -h -d 1 /
4.0K	/.snap
3.5K	/dev
8.1M	/rescue
6.6M	/sbin
276K	/libexec
 36K	/tmp
4.0K	/mnt
241M	/var
144K	/root
4.0K	/proc
2.9M	/etc
3.7G	/usr
1.2M	/bin
488M	/boot
4.0K	/media
9.6M	/lib

 

А если просто 

du -h / | grep G

?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

ncdu мимо кассы... 
 

pkg: Not enough space in /var/cache/pkg, needed 33 KiB available -5 GiB

А железка находится далеко... и консольки нет :(

 

Может еще какие стандартные средства есть, чтоб понять в чем пробема?

 

Как я себе воображаю, что когда закончилось место и повис mc, то системе не было отправлено, что освобождено место. Вот так оно и висит.

Відредаговано Respect!
Ссылка на сообщение
Поделиться на других сайтах

Понятно, что новый порт не получится установить, пока не освободится место. Попробуйте удалить что-то ненужное, чтобы хоть немного дискового пространства освободить. Посмотрите в /var/log, /home и /tmp

Однозначно найдется, что можно будет удалить. Кстати, на всякий случай "убейте" mc, если он все еще запущен:

killall -9 mc
Ссылка на сообщение
Поделиться на других сайтах

 

ничего не дало

# du -h -d 1 /
4.0K	/.snap
3.5K	/dev
8.1M	/rescue
6.6M	/sbin
276K	/libexec
 36K	/tmp
4.0K	/mnt
241M	/var
144K	/root
4.0K	/proc
2.9M	/etc
3.7G	/usr
1.2M	/bin
488M	/boot
4.0K	/media
9.6M	/lib

тут вывод неполный, должен быть еще корень /

может в корне скрытые какие-то файлы есть 

ls -la /
Відредаговано cheester
Ссылка на сообщение
Поделиться на других сайтах

В общем, что говорит 

du -ah / | grep G

последний отрывок из контекста:
 

3.7G	/usr
8.0K	/COPYRIGHT
1.5G	/data/myzen/myzen31.ts
1.1G	/data/myzen/myzen31.aux
2.6G	/data/myzen
2.6G	/data
7.0G	/

/data примонтирована отдельно.

А корень всего 7 гиг занимает.

Ссылка на сообщение
Поделиться на других сайтах

 

Понятно, что новый порт не получится установить, пока не освободится место. Попробуйте удалить что-то ненужное, чтобы хоть немного дискового пространства освободить. Посмотрите в /var/log, /home и /tmp

Однозначно найдется, что можно будет удалить. Кстати, на всякий случай "убейте" mc, если он все еще запущен:

killall -9 mc

killall -9 mc не помогает. Тазик уже бутался. 

Я не знаю где мне еще 5 гиг нарисовать, если всего занято 7 из 64 )

Ссылка на сообщение
Поделиться на других сайтах

Возможно все-таки стоит прочекать файловую систему.... Загрузись в single user mode и проверь на наличие ошибок.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Возможно все-таки стоит прочекать файловую систему.... Загрузись в single user mode и проверь на наличие ошибок.

к сожалению сервер находится удаленно и никакой консоли у него нет.

Еще одна отчаяная мера - это ресайз корневого раздела "на лету".

 

 

https://www.freebsd.org/doc/handbook/disks-growing.html

Відредаговано Respect!
Ссылка на сообщение
Поделиться на других сайтах

Фря рулит говорите? Запасся попкормом.

Еще вилами по воде писано...

 

c805d9b1336b7a04c7caad6a787e5233.jpg

 

Такую картину наблиюдаю именно с МС.

Ссылка на сообщение
Поделиться на других сайтах

А при чем тут мс, если сама фс говорит что свободно -5гб?? Тем более после ребута, явно баг ядра и фс.

Или удалить как-то гиг 10, или таки исать способ ребута и нормального чека фс.

Ссылка на сообщение
Поделиться на других сайтах

А при чем тут мс, если сама фс говорит что свободно -5гб?? Тем более после ребута, явно баг ядра и фс.

Или удалить как-то гиг 10, или таки исать способ ребута и нормального чека фс.

fsck сделал при перезагрузке - не помогает. 

Ссылка на сообщение
Поделиться на других сайтах

Это не баг.

Юникс-системы резервируют дисковое пространство (во Фре по умолчанию 8%). Только отображают по разному. 

Фря, если "залезли" в зарезервированное дисковое пространство отображает эти значения с отрицательным значением. 

Linux-ы показывают, что заполнение дисковой подсистемы больше 100%.

Відредаговано muff
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Заресайзить фс тоже не получается, т.к. gmirror не дает сделать. Так что прийдется топать ногами и с лайв-сд заниматься "переливанием мензурок".

Сдампить в другой раздел тоже не выходит, т.к. dump ругается на недостаток места. В общем замкнутый круг.

Відредаговано Respect!
Ссылка на сообщение
Поделиться на других сайтах

Во фре же есть fsck?

Я бы сделал fsck -y и в ребут, пусть лечит что сможет. Он обязан найти осиротевшие блоки и вернуть в виде ваших недокачанных файлов или как пустое место.

 

Upd: увидел про fsck, тогда вам к гуру бсд крутить тайные крутили.

Создайте на наге тему, там пара матерых человеков есть, думаю спасут.

Відредаговано KaYot
Ссылка на сообщение
Поделиться на других сайтах

Удалите хоть что-то и попробуйте установить ncdu.

Как вариант /usr/src, если сырцы подтягивали.

Ссылка на сообщение
Поделиться на других сайтах

Это не баг.

Юникс-системы резервируют дисковое пространство (во Фре по умолчанию 8%). Только отображают по разному.

Фря, если "залезли" в зарезервированное дисковое пространство отображает эти значения с отрицательным значением.

Linux-ы показывают, что заполнение дисковой подсистемы больше 100%.

Это ж дикость. Линукс не даст вам зарезервировать больше чем физически доступно, и никаких минусов или 100+% быть не может.
Ссылка на сообщение
Поделиться на других сайтах

У человека система занимает 7гб, а раздел на 62гб забит. Там видимо место не освобождается давно и всегда..

Т.е. нехватка 62-7+5=60(!!!)Гб.

Ссылка на сообщение
Поделиться на других сайтах

 

Это не баг.

Юникс-системы резервируют дисковое пространство (во Фре по умолчанию 8%). Только отображают по разному.

Фря, если "залезли" в зарезервированное дисковое пространство отображает эти значения с отрицательным значением.

Linux-ы показывают, что заполнение дисковой подсистемы больше 100%.

Это ж дикость. Линукс не даст вам зарезервировать больше чем физически доступно, и никаких минусов или 100+% быть не может.

 

http://help.ubuntu.ru/wiki/ext4

http://www.linuxshop.ru/articles/a337-working_with_the_volume_of_the_disk_in_linux_command_df_and_du

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan2="vlan 2 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan2_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я внес это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...
×
×
  • Створити нове...