Возможно диск скоро станет неработоспособным linux

Возможно диск скоро станет неработоспособным linux

Can’t write to the hard disk — (не могу записать на жесткий диск) на Linux/Unix системах. Получали такое сообщение? Хотите проверить поврежден ли диск или нет? Хотите понять почему получили сообщение «диск переполнен»? Попробуйте эти 8мь советов, что бы решить проблему с диском.

1. Ошибка: Нет свободного места на устройстве

Когда диск полон на Unix-подобной системе вы получите сообщение об ошибке на экране. Вот например

Первым шагом является запуск команды DF, чтобы узнать информацию об общем пространстве и свободном пространстве в файловой системе, включая разделы:

Или попробуйте читаемый формат

Решение проблемы, когда диск полон:

Сжатие журналов и других файлов используя GZIP или bzip2

Удалить ненужные файлы с помощью команды rm на Unix-подобной системе

Перемещение файлов на другой раздел системы или внешний жесткий диск, используя Rsync команду:

Узнайте самые большие каталоги или файлы которые используют дисковое пространство на Unix-подобных systesm:

Обрезать конкретный файл. Это полезно для файла журнала:
truncate -s 0 /ftpusers/ftp.upload.log

Найти и удалить большие файлы, которые открыты, но были удалены на Linux или Unix:

2. Файловая система находится в режиме только для чтения

Вы можете в конечном итоге получить такое сообщение об ошибке следующим образом, когда вы пытаетесь создать файл или сохранить файл:

Запустите команду монтирования, чтобы узнать, файловая система смонтирована в режиме только чтение:

Чтобы устранить эту проблему, просто перемонтировать файловую систему в режиме чтения-записи:

3. Проблема с дескриптором

Иногда, DF команда сообщает, что есть достаточно свободного места, но система утверждает, файловая система заполнена. Вы должны проверить inode, которые идентифицируют файл и его атрибуты на файловых системах с помощью следующей команды:

Если 100% ваших дескрипторов используются, попробуйте следующие варианты:

  • Найти ненужных файлов и удалять или перемещать на другой сервер.
  • Найти нежелательные большие файлы и удалить или переместить на другой сервер.

4. Жесткий диск умирает

Ошибки ввода / вывода в лог-файл (например, /var/log/messages) указывает, что что-то не так с жестким диском, и это может быть сбой. Вы можете проверить жесткий диск на наличие ошибок, используя команду smartctl. Синтаксис:

Вы также можете использовать «Disk Utility», чтобы получить ту же информацию

5. Диску или серверу сильно жарко.

Высокие температуры могут привести к плохому функционированию. Так что вам нужно поддерживать нужной температуры сервера и диска. Высокие температуры могут привести к завершении работы сервера или повреждения системы и файлов на диске. Только современные жесткие диски имеют датчик температуры. Hddtemp поддерживает чтение SMART информации от SCSI-диски тоже. Hddtemp может работать как простой инструмент командной строки или как демон, чтобы получить информацию от всех серверов:

Вы можете использовать команду smartctl тоже:

6.Работа с поврежденными файловыми системами

Файловая система на сервере, может повредится из-за жесткого перезагрузки или какой-либо другой ошибки, такие как плохие блоки. Вы можете восстановить поврежденные файловые системы следующей FSCK команды:

7.Работа с программным обеспечением RAID на Linux

Чтобы получить текущее состояние программного RAID в Linux введите следующую команду:

Вы должны заменить неисправный жесткий диск. В этом примере, я собираюсь заменить /dev/sdb (2-й жесткий диск RAID 6). Это работает, только если ваш сервер поддерживают горячую замену жесткого диска:

8. Работа с аппаратным RAID

Вы можете использовать команду samrtctl или поставщика, чтобы узнать статус RAID и дисков в контроллере:

Обратитесь к поставщику конкретной документации, чтобы заменить неисправный диск

Решил подключить старый (ранее рабочий) жесткий диск, но столкнулся с проблемой:
1) На винде: отображаются все разделы, при заходе в них видно все файлы и папки (т. е. диск "рабочий"), но спустя несколько сек. пока я нахожусь в этом жестком, всё зависает (вообще всё), пока не отключу его руками от материнки, но если я буду пользоваться компом и ни коим образом не затрагивая ни единый раздел второго жесткого диска всё будет отлично работать, пока не притронусь к нему (любым способом, например не заходя в него прогнать антивирусом, то сразу весь комп виснет навечно)
2) В линуксе в программе дисков пишет: ВОЗМОЖНО, ДИСК СКОРО СТАНЕТ НЕРАБОТОСПОСОБНЫМ.

Читайте также:  Как отсканировать документ на принтере brother

Исключая ответы "выбраси сваё старое га*но и купи новый" , может ли кто что-либо посоветовать? Прогнать к примеру какой-либо утилитой или еще что??
Я как-то не до конца понимаю, диск то вроде как рабочий, система его видит, отображает разделы, файлы в них и т. д.
Ах да, последний раз когда я им пользовался, делая большой баннер в ФШ, что видимо сильно нагрузило систему, исходя из того, что даже перемещение мыши по экрану шло с задержкой, комп завис, пришлось руками перезагружать и после перезагрузки он включался с ошибкой загрузчика (непомню точно что там было написано, но суть как я читал в гугле была с загрузчиком). И спустя месяц я решил снова подключить его и столкнулся с проблемами, описанными выше. В день "поломки" при подключении другого диска, "сломанный" диск комп вообще не видел и при подключении питания к нему никак не реагировал (сейчас же жужжит, давая понять что надежда на излечение всё же есть )

советы, руководства, инструкции.

Страницы

среда, 10 июня 2015 г.

Устраняем тормоза системы при операциях ввода-вывода, или вспомним о #12309

Баг #12309 — самый знаменитый баг в ядре Linux, довольно долго досаждавший пользователям Linux на десктопах. Сам баг исправлен в ядре Linux 3.3, но симптомы, похожие на таковые при 12309, могут проявляться на некоторых конфигурациях до сих пор. В сети можно найти много инструкций по лечению этих симптомов. Приведу в пример статью с сайта linux.org.ru, оригинал которой можно найти по ссылке с некоторыми дополнениями.

На самом деле 12309 — это не один, а несколько багов, смешанных в кучу. Можно выделить следующие случаи появления:

при копировании больших объемов данных с диска на диск (или с раздела на раздел одного диска);
при нехватке ОЗУ (и, соответственно, диком своппинге);
при копировании на USB-девайсы;
при использовании зашифрованных разделов;

Соответственно, фиксы тоже будут разные.

Сначала тест: восприимчива ли ваша система к 12309? введите в терминале:

dd if=/dev/zero of=/tmp/test bs=1M count=1M

и понаблюдайте за отзывчивостью системы. Если всё по-прежнему быстро — то читать статью можно разве что для профилактики и расширения кругозора.

Оптимистическое выделение памяти

Возможно, в научных программах какого-нибудь толка позволить выделить терабайт ОЗУ при наличии 3 Гб физической памяти и считается приемлемым, но на десктопе, где много процессов должны спокойно сосуществовать, такой расклад неприемлем — зажравшаяся программа спокойно вытеснит все остальное, после чего система практически остановится. Хуже всего то, что суть бага 12309 в том, что ядро принимает решения о том, какие страницы вытеснять, мягко говоря, неоптимально, а чинить это долго, муторно, и не в каждой ситуации решение будет приемлемым.

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

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

Читайте также:  Hal tim base start it

Для этого нужно прописать в /etc/sysctl.conf

Максимум памяти, который можно будет выделить, будет равен в сумме
объему свопа + некоторому проценту физической памяти. Этот процент по
умолчанию равен 50, но можно его несколько увеличить. Во всяком случае, я
выставил его в 80 и пока что катастроф нет.

Некоторые люди полагают, что если отключить своп, то 12309 исчезнет. А вот как бы не так. Своп (swap) — это хранилище анонимных страниц памяти. Код исполняемых программ и всяких библиотек не анонимен и по умолчанию не изменяем. В то время как на 32-битных системах исполняемый код зачастую зависим от позиции (начального адреса), что приводит к тому, что, во-первых, динамический линковщик проводит вычисление смещений каждый раз при загрузке и, соответственно, страницы кода анонимны (это несет с собой недостаток в виде наличия нескольких копий одной и той же библиотеки, но и преимущество в виде невозможности вытеснить страницы кода для освобождения памяти), то на 64-битных системах практически весь код линкуется в независимом от позиции виде (PIC).

Это означает, что, во-первых, загрузка такого кода — это фактически всего лишь mmap() на исполняемый файл, во-вторых, можно держать только одну копию страниц кода на каждый процесс, сколько раз его ни загружай. Это достоинства. Недостаток в том, что даже при отсутствии свопа ядро может в случае нехватки освободить память за счет страниц со спящим кодом. Когда код надо будет выполнять, поднимать его надо будет с диска, и хорошо бы тогда иметь место в очереди ввода-вывода, а то система встанет в неудобную позу, причем надолго.

Так как ядро, вообще-то, достаточно умное, чтобы сначала при возможности сбросить в своп анонимные страницы спящих процессов, то своп лучше все же иметь. Чаще всего доставать этих страниц надо будет меньше (особенно в случае Xorg и его драйверов, не путать с драйверами ядра).

Уменьшение размеров дисковых буферов

С одной стороны, отдавать под дисковые буферы практически всю свободную память — здравая идея. А с другой стороны, чем больше ОЗУ, на самом деле, тем сильнее это способно ударить в критической ситуации.

Это работает вот как. У ядра есть буфер файловой системы. Мы пишем много данных. Этот буфер заполняется грязными страницами, а потом выполняется системный вызов sync() и буфер сбрасывается на носитель. Чем больше буфер, тем больше данных надо будет сбрасывать. Все бы ничего, да вот когда кому-то вдруг вздумается выделить себе памяти, в первую очередь будут сбрасываться все эти буферы, и если при этом вдруг надо будет закачать страницы с исполняемым кодом, им опять-таки придется ждать в очереди. Опять слайдшоу, с возможной цепной реакцией.

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

Есть еще одна неприятная особенность, связанная трудно сказать, с чем — возможно, с реализацией DMA, но вполне возможно, что не с ней, или не только с ней. Берем какой-нибудь медленный для записи носитель, типа той же USB-флешки, и пробуем записать на него данных побольше, фильм какой или что-то навроде. Мы увидим, что происходит это рывками — сначала заполняется буфер, сколько влезет, а потом весь сбрасывается, потом весь заполняется. и так далее. При этом суммарно потраченное время почему-то ощутимо больше, чем как если бы мы примонтировали носитель с -o sync, а скорость записи на, собственно, носитель невообразимо мала.

Читайте также:  Как собрать антенну сетка

Но если уменьшить порог количества грязных блоков, после которого начнется их сброс на носитель, не до сверхмалых величин, но все же — это позволит проводить зачитку данных из источника и запись на носитель параллельными DMA-трансферами. Я у себя выставил этот объем равным 2 мегабайтам, что, с одной стороны, уменьшает количество перезаписей в случае частой смены маленьких файлов и значительно увеличивает скорость переноса больших объёмов данных. Возможно, если поиграться размером, можно найти оптимальное быстродействие, но не думаю, что буфер больше 16 мегабайт будет эффективным.

echo 2097152 >/proc/sys/vm/dirty_bytes
echo 2097152 >/proc/sys/vm/dirty_background_bytes

Для сохранения после перезагрузки, прописать в /etc/sysctl.conf

Стоит учесть, что кеши чтения файловой системы будут все так же занимать почти все свободное ОЗУ, но при этом запись будет осуществляться, как только блоков, помеченных на запись, наберется на 2 мегабайта.

Значение dirty_bytes должно делиться на 4096 нацело.

В результате, даже при переваривании больших объемов данных, система не заикается. Может затормозить сам процесс, который выделяет память, но отзывчивость системы не теряется.

Кеш файловых систем

Иногда бывает такая проблема: у вас относительно новое ядро, тесты с dd проходят на ура, а вот когда надо много маленьких файликов создавать/менять/убивать, например, командой dpkg, система встает колом и не может даже регистрами пошевелить.

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

По умолчанию оно почему-то 100, что просто безумно на десктопных нагрузках.

Установить параметр swappiness равным 10 или 5, чтобы подкачка задействовалась только при исчерпании 90 и 95% памяти соответственно:

sudo nano /etc/sysctl.conf

Добавить в конец vm.swappiness = 10

Сохранить и выполнить sudo sysctl -p

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

самому (в некоторых дистрибутивах, например Calculate Linux, BFQ по умолчанию). В остальных же случаях можно сменить планировщик на лету.

Перевесить системные прерывания на одно ядро (на многоядерном процессоре) скриптом:

for interruption in `grep usb /proc/interrupts | awk ‘‘| sed ‘s/://g’` ; do

echo 1 > /proc/irq/$/smp_affinity;

При самостоятельной сборке ядра, задействовать 100Hz таймер ядра и опцию No Force Preemption (Server) mode.

Выставить приоритет ionice для ядра 1 (realtime) для пространства пользователя (userspace) — 3.

Установить ядро с патчами для реализации режима реального времени (linux-lowlatency, есть по умолчанию в репозиториях

Подводя итог, можно отметить: самого бага давно нет, но на некоторых конфигурациях могут возникнуть его симптомы, по совершенно

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

ещё более серьёзна, а самое главное — никак не решаемая. Система может с лёгкостью встать колом при копировании больших объёмов данных,

и её придётся перезагружать кнопкой Reset. Неоднократно с этим сталкивался. А вот симптомы 12309 удалось увидеть лишь при копировании фильма с

NTFS-раздела на старую, потрёпанную жизнью, флешку. И то потом проблему так и не удалось воспроизвести, потому списал на случайность.

Обзор планировщиков ввода-вывода

Статья о решении проблем с 12309 (на английском).

Ссылка на основную публикацию
Ввод на клавиатуре 5 букв
Слово из 5 букв, первая буква - «Б», вторая буква - «А», третья буква - «Т», четвертая буква - «О»,...
В биосе нет вкладки advanced
Обычно вопросом «как открыть advanced bios или расширенный режим?» задаются для того, чтобы произвести более детальные настройки в базовые системы...
В каком спеке качать рогу
За данные годы разбойники продолжили развиваться и стали теперь одним из самых сильных для прокачки классов. Нашими слабыми сторонами были...
Видеокарта msi n1996 технические характеристики
Недавно мы заметили, что многие пользователи приходят на наши сайты в поисках таинственной аббревиатуры «N1996». Нам стало интересно, почему? Непродолжительные...
Adblock detector