Разбивка диска и свободное место.

[Amiger]

Помогите, не могу установить софт по причине(Если я верно понял):
Недостаточно места на диске ( Конкретно мал /tmp и / ).
Правильно, ли разбит диск? И как его почистить? Или правильно разбить.
Систему ставил не сам.

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 259M 226M 20M 93% /
tmpfs 251M 0 251M 0% /lib/init/rw
udev 247M 100K 247M 1% /dev
tmpfs 251M 0 251M 0% /dev/shm
/dev/sda5 1.9G 65M 1.7G 4% /home
/dev/sda6 1.9G 396M 1.4G 23% /usr
/dev/sda7 68G 408M 65G 1% /var
overflow 1.0M 1.0M 0 100% /tmp

P.S.Реально же не могу справиться с обрезанием ICQ и прочей фигни для офисного сообщества.

[drBatty]

/dev/sda1 259M 226M 20M 93% /

конечно мало. надо метров 500 минимум.

/dev/sda6 1.9G 396M 1.4G 23% /usr

тоже мало. я правда не знаю, зачем эта система, но по любому 1.9 мало

overflow 1.0M 1.0M 0 100% /tmp

дык а это что? вообще пусто что-ли?

/dev/sda7 68G 408M 65G 1% /var

грузитесь с LiveCD, и переразмечайте. отрезайте от var.

ЗЫЖ и где вы такую разбивку-то нашли? в мануале 1990го года?

[SLEDopit]

вообще пусто что-ли?

Наоборот - забито.

где вы такую разбивку-то нашли?

Систему ставил не сам.

да и вообще, судя по разбивке, больше на сервак похоже.

А вообще, нужно либо переразбивать через live cd (например gparted), либо, если уж очень лениво и никаких ценных данных нет (если они есть - обязательно скопировать) просто переустановить систему с новой разбивкой. При вашей разбивке, второй вариант - проще.

[MrClon]

А вообще, нужно либо переразбивать через live cd (например gparted)

Предварительно забекапив все ценные файлы. О подобных мелочах часто забывают.

А вообще в /var и /usr места хватает, а пакетный менеджер как правило только эти директории использует, так-что не вполне понятно от чего софт не ставится.

P.S. а чего там с ICQ и зачем его обрезать (он и так из Израиля родом, значит обрезанный из коробки)?

[drBatty]

так-что не вполне понятно от чего софт не ставится.

а мне - понятно:

overflow 1.0M 1.0M 0 100% /tmp

Наоборот - забито.

дык там жалкий метр всего.
можно сказать - пусто.

[rm_]

Наоборот - забито.

дык там жалкий метр всего.
можно сказать - пусто.

Вы шутите так, или правда не въезжаете? По-вашему если ёмкость для чего-либо (к примеру кружка) заполнена до краёв, но при этом очень маленькая сама по себе - то можно сказать она пустая?

[drBatty]

Вы шутите так, или правда не въезжаете? По-вашему если ёмкость для чего-либо (к примеру кружка) заполнена до краёв, но при этом очень маленькая сама по себе - то можно сказать она пустая?

стакан с водкой, где по стенкам размазана 1 капля водки, с практической т.з. пуст.
так и HDD с tmp равным 1Мб === HDD без tmp.
А вопрос о наполнении такого малого /tmp эквивалентен вопросу деления на ноль. А при делении на ноль, как известно, получается неопределённость. (:

дык там жалкий метр всего.
можно сказать - пусто.

или правда не въезжаете?

дык понимайте буквально -
Q: сколько мб в tmp?
A: 1.
Стало быть, tmp - пуст. Ибо 1Mb в tmp === почти пусто. С т.з. программ и системы. Т.з. таблицы разделов меня волнует мало...

[arkhnchul]

временный костыль - /tmp сделать симлинком куда-нибудь на /var/tmp, раз уж там места дофига. Так, в принципе, можно жить некоторое время.

[MrClon]

На сколько я понимаю /tmp в данном случае находится не на харде а в RAM, так-что его расширение не должно составить проблем.

arkhnchul
Думаю mount --bind /var/tmp /tmp будет более… аккуратно что-ли.
Или вообще mount -t tmpfs -o size=128M tmpfs /tmp

[return12]

На сколько я понимаю /tmp в данном случае находится не на харде а в RAM, так-что его расширение не должно составить проблем.

arkhnchul
Думаю mount --bind /var/tmp /tmp будет более… аккуратно что-ли.
Или вообще mount -t tmpfs -o size=128M tmpfs /tmp

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

[MrClon]

Держать /tmp в памяти или хотя-бы на отдельном разделе практичнее. В первом случае временные файлы читаются/пишутся быстрее и не нагружают диск лишниней нагрузкой. Если просто на отдельный раздел выносить то не будет фрагментироваться раздел с системными файлами, а если на отдельные разделы вынести ещё /var и /home то можно будет корневой раздел примонтировать только на чтение что в общем-то кошерно для статичных систем.

[drBatty]

Держать /tmp в памяти или хотя-бы на отдельном разделе практичнее. В первом случае временные файлы читаются/пишутся быстрее

а это НЕ правда. Вы забыли про кеширование. У нас не венда.

т.е. на отдельном разделе /tmp/ нужно держать. Но не в памяти. на отдельном разделе по соображениям безопасности, ибо это общедоступный раздел. А вот в памяти не обязательно (хотя можно, из-за той-же безопасности)

если вы всё же пожелаете держать /tmp/ на диске, то нужно продумать меры его очистки при выходе из системы.

[watashiwa_daredeska]

а это НЕ правда. Вы забыли про кеширование. У нас не венда.

Кеширование все равно подразумевает необходимость обращения к диску. Для временных файлов, думаю, соотношение числа чтений/записи несколько хуже (с т.з. кеша) по сравнению со среднестатистическим не временным файлом, а значит кеш для /tmp менее полезен. В то же время, tmpfs может засвопиться в случае неиспользования, но не требует обязательного обращения к диску.

[drBatty]

Кеширование все равно подразумевает необходимость обращения к диску. Для временных файлов, думаю, соотношение числа чтений/записи несколько хуже (с т.з. кеша) по сравнению со среднестатистическим не временным файлом, а значит кеш для /tmp менее полезен. В то же время, tmpfs может засвопиться в случае неиспользования, но не требует обязательного обращения к диску.

ну давайте померим.
на моих системах нет разницы. я проверял компиляцию ядра, и прочие ресурсоёмкие задачи.

и да. Уважаемый watashiwa_darede..., вы забыли про отложенную запись. При всём уважении, не мне вам упоминать об этом. Особенно в этой теме.

[watashiwa_daredeska]

я проверял компиляцию ядра, и прочие ресурсоёмкие задачи.

А что, при компиляции создаются временные файлы? ЕМНИП, gcc -pipe существует давно и широко используется. Лично я вообще не могу припомнить у себя задач, которые интенсивно используют /tmp: у меня там в основном сокеты всяких X Window, ssh-agent'ов, emacs'а и пр. и пара времянок от fvwm (конфиги обрабатываются m4).

[MrClon]

Кеширование все равно подразумевает необходимость обращения к диску. Для временных файлов, думаю, соотношение числа чтений/записи несколько хуже (с т.з. кеша) по сравнению со среднестатистическим не временным файлом, а значит кеш для /tmp менее полезен. В то же время, tmpfs может засвопиться в случае неиспользования, но не требует обязательного обращения к диску.

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