ТОП 10 ВОПРОСОВ НА СОБЕСЕДОВАНИИ ПО LINUX — Transcript

Разбор ТОП-10 вопросов на собеседовании по Linux для DevOps с подробными объяснениями и практическими примерами.

Key Takeaways

Хардлинк — это дополнительное имя для одного и того же файла с общим номером иноды и счётчиком ссылок.
Симлинк — отдельный файл, содержащий путь к целевому файлу, с ограничением на количество переходов.
Права доступа для каталогов имеют особое значение, где execute (search) позволяет переходить внутрь каталога.
Sticky бит ограничивает удаление файлов в общих каталогах, обеспечивая безопасность совместного использования.
Практические примеры использования хардлинков и симлинков важны для успешного прохождения собеседований.

Summary

Объяснение разницы между хардлинком и симлинком с техническими деталями инод и файловой системы.
Рассмотрение ограничений хардлинков и особенностей работы симлинков, включая быстрые симлинки и лимит переходов.
Практическое применение хардлинков в инкрементальных бэкапах и симлинков в управлении конфигурациями Linux.
Разбор прав доступа 755 для директорий и значение битов r, w, x для каталогов.
Объяснение роли sticky бита в каталогах, его влияние на удаление файлов и наследование групп.
Подробное объяснение работы команды free и значений buff/cache и available (продолжение видео).
Советы по тому, как глубоко и грамотно отвечать на популярные вопросы на собеседованиях по Linux.
Пояснение работы системных вызовов unlink и механизмов удаления файлов в Linux.
Разбор структуры каталогов и файлов с точки зрения ядра и файловой системы ext4.
Рекомендации по использованию примеров из реальных сценариев для впечатления на собеседовании.

Full Transcript — Download SRT & Markdown

Speaker A

Всем привет, друзья. Это канал ПростопS. И как вы могли понять по названию ролика, сегодня мы разберём 10 самых популярных вопросов на собеседовании по Линуксу в Девопсе. И возможно, некоторые из этих вопросов вам покажутся очень простыми, но тем не менее это самые

Speaker A

популярные вопросы, которые звучат из собеседования в собеседование. Не будем долго задерживать, подписывайтесь на наш канал в Телеграме. А мы начинаем. Первый вопрос: чем отличается хардлинк от симлинка? И хоть этот вопрос считается мавитоном, тем не менее его очень часто

Speaker A

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

Speaker A

ядра файл — это, а если конкретнее, то структура данных внутри файловой системы. В файловой системе ext4 одна инода занимает 256 байт. И в этих 256 байтах хранится вообще всё про файл: его владелец, группа, права доступа, размер и временная метка, когда он был создан,

Speaker A

когда модифицирован, когда менялись метаданные, причём с точностью до секунды. Там же лежит счётчик жёстких ссылок. И самое интересное — поле i-блок на 60 байт, в котором хранятся указатели на реальные данные файла на диске. А вот имя в иноде не хранится. Имя живёт в

Speaker A

каталоге. При этом каталог — это тоже файл, просто специальный. Внутри него табличка из двух колонок: строка, имя и номер иноды. Когда вы делаете file.txt, ядро открывает каталог, находит строку file.txt, берёт оттуда номер иноды, идёт в таблицу, читает метаданные и указатели на блоке, и

Speaker A

только после этого начинает читать данные из диска. Но вернёмся к нашему вопросу. Хардлинк — это ещё одна строчка в этой табличке, которая указывает на тот же самый номер иноды. Это не копия и не ссылка, а буквально ещё одно имя для

Speaker A

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

Speaker A

файл и хардлинк с названием hardlink1, у них обоих будет один и тот же номер иноды, один и тот же счётчик ссылок, равный двум, и одни и те же метаданные, потому что это один и тот же файл. Окей, с созданием разобрались. А что происходит

Speaker A

при удалении? Когда мы пишем rm, на самом деле вызывается системный вызов unlink. Он удаляет запись из каталога и уменьшает счётчик. Данные из диска стираются только, когда выполняются два условия: счётчик ссылок дошёл до нуля, и ни один процесс не держит этот файл

Speaker A

открытым. Если процесс ещё пишет файл через открытый дескриптор, ядро не тронет данные, пока дескриптор не закроется. У хардлинков при этом есть два ограничения, про которые тоже часто спрашивают. Первое: хардлинк нельзя сделать через границу файловой системы.

Speaker A

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

Speaker A

сделать хардлинк на каталог. И это тоже легко объяснить. Если каталог А содержит хардлинк на каталог B, а B содержит хардлинк на каталог А, то ядро при обходе дерева уйдёт в бесконечный цикл.

Speaker A

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

Speaker A

если путь короткий, до 60 байт, он хранится прямо в поле i-блок самой иноды, то есть вообще без выделения блоков на диске. Это называется быстрый симлинк. А для длинных путей уже придётся выделить отдельный блок данных. Когда вы обращаетесь к симлинку, ядро читает

Speaker A

строку путь и начинает разрешение пути заново. И тут возникает вопрос: а что если симлинк ссылается на другой симлинк, тот на третий и так далее? Тогда ядро будет ходить по цепочке, но не бесконечно. Есть лимит в 40 переходов.

Speaker A

Если за 40 шагов до реального файла не добрались, ядро вернёт ошибку. И ещё пара вещей, которые стоит узнать про симлинки. У симлинка всегда выставлены максимальные права, и на Линуксе они игнорируются, а доступ определяется правами целевого файла. А если целевой

Speaker A

файл удалить, то симлинк повиснет и станет, по сути, битым. Но тут тоже есть интересный момент. Если потом создать новый файл по тому же пути, симлинк автоматически снова заработает, потому что он хранит строку путь, а не ссылку на конкретную иноду. Ну и чтобы закрыть

Speaker A

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

Speaker A

Rsnapshot и rsync с флагом link-dest. Суть в том, что неизменённые файлы просто получают новый хардлинк в новом снапшоте, и вы экономите кучу дискового пространства, потому что данные на диске хранятся в одном экземпляре. А симлинки — это вообще основа управления

Speaker A

конфигурациями в Linux. pattern sites enabled и sites available в nginx, включение юнитов systemd, цепочки версий библиотек и даже systemd на современных дистрибутивах. Это всё симлинки на /usr/bin.

Speaker A

Второй вопрос у нас такой: что означают права 755 для директории? На первый взгляд вопрос элементарный. 755 значит для владельца r-x, для группы и остальных. Но собеседующий здесь почти всегда пойдёт дальше и спросит: "А что конкретно означает execute для

Speaker A

каталога?" И вот тут можно очень хорошо себя показать. В первом вопросе мы уже говорили, что каталог — это специальный файл, внутри которого табличка: имя файла, номер иноды. Так вот, биты r, w и x для каталога управляют доступом именно к этой табличке, и работают они

Speaker A

совсем не так, как для обычного файла. Бит r (чтение) позволяет прочитать имена записей из каталога. То есть команда ls покажет вам список файлов. Но вот тут начинается самое интересное. Если у вас есть только r без x, то ls покажет вам

Speaker A

имена. Но ls -l выдаст вопросики вместо размера, прав и всего остального. Потому что, чтобы прочитать метаданные файлов, нужно обратиться к их инодам. А обращение к инодам — это уже бит x. Бит x же для каталога

Speaker A

он называется search, а не execute, позволяет входить в каталог через cd и обращаться к инодам файлов внутри уже по имени. И тут тоже есть интересный нюанс. Бит x нужен на каждом каталоге в цепочке пути, чтобы ядро смогло прочитать файл по пути /home/user/file,

Speaker A

оно проверит бит x на корне, на home и на user. Если хотя бы на одном его не будет, доступ будет ограничен, даже если на самом файле будут полные права. Идём дальше. Бит w (запись) позволяет создавать, удалять и переименовывать файлы внутри каталога, но работает

Speaker A

только в связке с иксом. Без x бит w бесполезен, потому что мы не сможем обратиться к каталогу, чтобы что-то в нём изменить. И ещё кое-что, что тоже могут спросить в связке с этим вопросом.

Speaker A

Sticky бит — это то, что стоит, например, на каталоге /tmp, там 1777, а отображается так, как показано на экране. На самом деле этот бит просто ограничивает удаление. В каталоге с правами три семёрки любой пользователь может удалить любой файл, потому что

Speaker A

удаление — это запись в каталог, а w стоит для всех. Sticky меняет правила, и теперь файл может удалить только его владелец, владелец каталога или root.

Speaker A

Без sticky бита на /tmp любой пользователь системы мог бы удалять чужие временные файлы. И есть ещё один специальный бит sticky на каталоге. А делает он следующее. Все новые файлы и подкаталоги, созданные внутри, автоматически получают группу каталога, а не основную группу пользователя,

Speaker A

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

Speaker A

что показывает команда free и что такое buff/cache и available. Сначала разберём, что вообще показывает free.

Speaker A

взгляд кажется, что всё плохо, хотя на самом деле всё отлично. Available показывает 14 ГБ, то есть приложением доступно почти всё. Давайте теперь пройдёмся уже по каждому полю. Тотал - это общий объём физической памяти минус то, что ядро зарезервировало для себя

Speaker A

при загрузке. Фри - это страницы, которые вообще ничем не заняты. Прямо вот совсем пустые. - это то, что реально занято процессами. Шарит - это TMP, FS и разделяемая память. А Buff Cashш - самый интересный пункт в нашем списке. Buff Cш

Speaker A

- это сумма трёх вещей: буферы, cas и s recllaimable. Чтобы понять, что это, надо разобраться, как Linux работает с памятью. Linux придерживается простого принципа: свободная память - это потерянная память. То есть зачем держать память пустой, если в неё можно положить

Speaker A

что-то полезное? Поэтому ядро агрессивно использует всю незанятую память под кэш. Прочитали файл с диска, ядро оставит его копию в памяти в Page Casш. Если файл понадобится снова, не придётся лезть на диск. Ядро просто отдаст его из памяти.

Speaker A

И тут надо разделять две вещи. Это page Casш и Buffer Casш. Page CASш - это про содержимое файлов. Например, вы прочитали каталог Энджинкса, и ядро оставило его копию. Приложение записало данные влог. Сначала они легли в Page Casш, и только потом ядро сбросило их на

Speaker A

диск. На любом рабочем сервере Page Cas - это основной потребитель памяти. Причём страницы в этом Page Cas бывают двух видов: чистые, то есть те, которые совпадают с тем, что уже лежит на диске.

Speaker A

И их можно выкинуть, потому что ничего не потеряется, потому что данные есть на диске. А есть грязные - это те, куда приложение уже записало новые данные, но до диска они ещё не доехали. И грязные просто так выкинуть нельзя. Сначала надо

Speaker A

сбросить на диск то, что имеем, иначе мы потеряем данные. Дальше. Бафер Cшш - это совсем другая история. Он кэширует не содержимое файлов, а служебные структуры в файловой системе. Мы в первом вопросе говорили про таблицу IOT, про каталоги.

Speaker A

Так вот, Superbлок, таблицаe, Group Descriptors, вся эта навигационная кухня файловой системы - это Buffer Casш. Он обычно маленький, Мгаб 200 и400, но без него ядру пришлось бы при каждом обращении к файлу лезть на диск за метаданными. И в выводе фри эти два кэша

Speaker A

слиты в одну колонку buffш. Поэтому, когда вы видите там 13 ГБ - это в основном page CASШ, то есть содержимое файлов, которые сервер недавно читал или писал. Теперь про available. Это оценка самого ядра. Сколько памяти оно сможет отдать новым приложениям без того, чтобы

Speaker A

лезть в Swap. Почему available больше free? Мы как раз это разобрали. Page Cash можно освободить. Чистые страницы выкидываются мгновенно, и ядро это понимает. Поэтому, когда она считает available, оно берёт memф, прибавляет примерно половину файлового кэша, далее прибавляет примерно половину так

Speaker A

называемого reclamable slap. Это внутренние структуры ядра, которые тоже можно отдать и оставляет небольшой резерв на всякий случай. Но почему половину, а не всё? Потому что если выкинуть весь кэш, то система формально, конечно, выживет, но производительность в этот момент сильно просядет, потому

Speaker A

что каждое чтение файла снова пойдёт на диск. И здесь возвращаемся к нашему примеру. Free 1,2 ГБ, available 14, то есть система полностью здорова. Те 13 ГБ в баffш - это не проблема, но на Сабесее могут копнуть ещё дальше. А как вообще

Speaker A

Linux выделяет память приложением? Когда приложение запрашивает у ядра гигабайт памяти, физическая память не выделяется вообще. Вместо этого ядро создаёт запись VMA, то есть Virtual Memory Area. По сути, просто пометку, что этот диапазон адресов закреплён за процессом, и возвращает указатель. Физические

Speaker A

страницы появляются только, когда процесс реально начинает писать в эту память. Первое обращение вызывает так называемый pageйфold. Дальше ядро его ловит, выделяет физическую страницу и подставляет её. Это называется lazy allocation, то есть отложенное выделение. И это значит, что можно

Speaker A

запросить 100 ГБ на машине с 16 ГБ памяти и ничего не упадёт, пока мы реально не начнём использовать эту память, потому что существует она только на бумаге. Переходим к четвёртому вопросу. Что такое LVM и зачем он нужен?

Speaker A

Но давайте начнём с проблемы. Вот есть у вас сервер, а на нём директория VAR на отдельном разделе размером, допустим, 20 ГБ с файловой системой XT4. ЛОги растут, раздел заполнен на 95%. И без LVM нам нужно добавить диск, перенести данные,

Speaker A

поменять FS Tab, перезагрузиться. А с LVM нам нужно три команды. И теперь давайте разберёмся, как он работает. LVM - это logical Volume Manager, прослойка между физическими дисками и файловыми системами. А построена она на трёх уровнях. Нижний уровень - это физическое

Speaker A

хранилище PV, то есть диск или раздел, который вы инициализировали для LVM. Что при этом происходит? На устройство записывается специальная LVM-метка, в которых лежит UU ID и указатель на область метаданных, а всё остальное пространство нарезается на кусочки одинакового размера, так называемые

Speaker A

physical Extense. По умолчанию 1PE - это 4 Мб, то есть минимальная единица, которая оперирует LVM. Всё выделение пространства дальше будет кратно этим 4 Мбм. Средний уровень - это Volume Group, то есть пул, который объединяет один или несколько PV. То есть вы можете взять

Speaker A

физические диски и сказать: "Теперь это одно общее большое пространство". Размер PE задаётся при создании Volum Group и одинаков для всех PV внутри. И тут есть важная деталь. Каждый PV хранит полную копию метаданных всего Volume группа. То есть информация о структуре пула

Speaker A

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

Speaker A

устройство, созданное из свободного пространства Volume Group. Кладём на него файловую систему, монтируем. И для приложения это выглядит как обычный раздел. Они вообще не знают, что под ними ЛВМ. Под капотом у ЛВ просто таблица, что такой-то номер логически лежит физически там-то, один к одному. И

Speaker A

реализовано всё через специальный мапер, то есть фреймворк ядра для создания виртуальных блэчных устройств. Через него, кстати, работает докеровский overlay. Ну а зачем всё это нужно, мы поймём, вернувшись к нашему сценарию с ВAR. Три команды инициализировали новый диск, добавили Volume Group, расширили

Speaker A

Том и файловую систему. Всё, вар стал на 50 ГБ больше, без размонтирования и без перезагрузки. XT4 и XFS это поддерживают на лету. А дальше насобесе могут спросить про снапшоты. И тут важно понимать главное. При создании снапшота ничего не копируется. LM просто выделяет

Speaker A

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

Speaker A

отдельную область и только потом записывает новые данные. Это называется копий. Сnпшот хранит не полную копию Тома, а только то, что изменилось с момента создания. Но у этого есть свои минусы, потому что каждая первая запись в блог - это тройная работа с диском,

Speaker A

потому что надо прочитать старое значение, сохранить его и записать новое. А если висит несколько снапшотов, старое значение надо сохранить в каждой.

Speaker A

И ещё момент, область для хранения изменений имеет фиксированный размер. Если она заполнится на 100%, снапшот просто не остановится и удалится, и данные будут потеряны. Поэтому в конфиге ЛВМа настраивают автоматическое расширение, то есть ядро само подрастит область, когда та заполнится на 70%. И

Speaker A

последнее. В третьем вопросе мы говорили про Lazy Allocation, когда приложение запрашивает гигабайт памяти, а физически выделяется он только при записи. Есть такой же принцип в ЛМЕ, называется Thoreisionниing. Допустим, создали пул на 100 ГБ, а внутри раздали томам суммарно 800. Но пока данные не

Speaker A

записаны, физическое место не занято. Но в таком сценарии обязателен мониторинг, потому что если пул заполняется, он уходит в RIDonли, и это затрагивает все дома внутри. Что такое Srace и когда его применять? Называется это трассировщик системных вызовов. Любая программа в

Speaker A

Линуксе, когда ей нужно что-то от ядра, открыть файл, прочитать данные, подключиться по сети или выделить память, делает системный вызов. Sraй перехватывает каждый такой вызов и показывает вам, что вызвали, с какими аргументами и что ядро вернуло. Под капотом использует механизм Pace. Это

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

из три, запиши в три, закрой три. Но почему три, а не ноль? Потому что первые три номера уже заняты. При запуске любого процесса ядро автоматически создаёт три дескриптора. Ноль, то есть in стандартный ввод, один, то есть STD out, он же стандартный вывод. И два,

Speaker A

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

Speaker A

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

Speaker A

может быть дескрипторов вообще. В Linux же всё есть файл. И обычные файлы, и сокеты, и пайпы, и деф- устройства.

Speaker A

Каждое открытое TCP соединение - это тоже файловый дескриптор. Каждый открытый OG - тоже дескриптор. И если их не ограничивать, то один процесс может сожрать все ресурсы ядра. Поэтому есть лимиты. Основной - это лимит на процесс.

Speaker A

По умолчанию 1.24 дескриптора. Этот лимит мягкий, и процесс может поднять его сам, но не выше жёсткого. Обычно это 4.096.

Speaker A

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

Speaker A

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

Speaker A

седьмому вопросу. Диск заполнен, но DF и показывают разные цифры. Почему? Ситуация такая. На сервере DF показывает, что диск заполнен на 95%.

Speaker A

Идём разбираться, запускаем ДУ, а там суммарно набирается 60%. Вопрос, куда делись 35? Чтобы понять, надо разобраться, как считают DF и Ду. Ходит по дереву каталогов, открывает директорию, читает записи и для каждого файла смотрит размер через айду, суммирует. Если у файла нет записи в

Speaker A

каталоге, его просто не видит, а DF работает на уровне файловой системы. Он вызывает FS и спрашивает у файловой системы напрямую, сколько блоков всего, сколько занято и сколько свободно. этой команде неважно, есть ли у файла запись в каталоге или нет. Если блоки заняты,

Speaker A

значит заняты. И тут опять возвращаемся к первому вопросу. Данные с диска стираются только в тот момент, когда счётчик жёстких ссылок дошёл до нуля и ни один процесс не держит файл открытым.

Speaker A

А в шестом вопросе мы говорили, что каждый открытый файл - это дескриптор в таблице процесса. Так вот, если процесс ещё держит дескриптор, блоки на диске остаются занятыми. И это и есть самая частая причина расхождения. Удалённые, но ещё открытые файлы. Типичный сценарий

Speaker A

с тем же инжинксом, который пишет в access.log. Log вырастает до 10 ГБ. Мы выполняем rmacess.log и запись каталога исчезает. Этот файл больше не видит, но держит дескриптор открытым и продолжает туда писать: "Блоки заняты и DF их считает". Отсюда

Speaker A

расхождение. Вопрос номер восемь. No space left, но место есть. Что происходит? Продолжаем разбираться с утилитой DF. Запускаем DF -H. Смотрим.

Speaker A

Видим, например, 40% свободно. Место есть, но система пишет, что его нет. Опять возвращаемся к первому вопросу.

Speaker A

Самая частая причина ошибки No Space Left при наличии свободного места - это то, что закончились айноды. То есть блоки свободны, но создать новый файл невозможно, потому что не осталось ни одной свободной айноды. Проверяется это командой DFI. Она покажет не

Speaker A

использование блоков, а использование iно. И если там 100% - это наша проблема. На практике это может случиться, когда на диске появляется огромное количество мелких файлов.

Speaker A

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

Speaker A

необходимости, пока есть свободные блоки. Better FS тоже так делает. Там iноoda и блок - это не два отдельных пула, а общий ресурс. Поэтому ситуация, что место есть, а нет, на XFS и беfs практически невозможно. Ну и чтобы закрыть вопрос полностью, но - это не

Speaker A

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

Speaker A

перемонтировании в RIDonли, то дело не вместе и не в айнодах. Девятый вопрос. Что такое EOW и почему он может быть высоким при низкой нагрузке ЦПУ? EOT - это разновидность Idle, то есть время, когда процессор свободен, но есть хотя

Speaker A

бы один процесс, который ждёт завершения ввода-вывода. Ключевое слово свободен. Процессор в состоянии и его вейт ничего не делает. Он мог бы выполнять другие задачи, если бы они были. Просто в данный момент единственное, что стоит в очереди - процесс, заблокированный на

Speaker A

ожидании водо-вывода. И если запустить на этом же ядре какую-нибудь вычислительную задачу, его вейт упадёт, а юзыш вырастет. Хотя диск как тормозил, так и тормозит. Почему его вейт может быть высоким при низкой нагрузке ЦПУ?

Speaker A

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

Speaker A

проблемы - это медленный диск. Вторая причина - это свап. Мы в третьем вопросе говорили, что когда физическая память заканчивается, ядро начинает скидывать данные из RAM на диск, то есть в swap, а диск медленный. И когда процессу понадобятся эти данные обратно, он стоит

Speaker A

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

Speaker A

Последний, десятый вопрос. отдаёт 504, но лод age низкий. Где проблема? Пишите в комментарии, либо смотрите разбор вопроса у нас в телеге.

Speaker A

Всем спасибо за просмотр. Подписывайтесь на канал, ставьте лайки. Увидимся в новых видео. Всем пока-пока.

Topics:LinuxDevOpsсобеседованиехардлинксимлинкправа доступакаталогинодафайловая системауправление конфигурациями

Frequently Asked Questions

В чем основное отличие хардлинка от симлинка в Linux?

Хардлинк — это дополнительное имя для одного и того же файла с общим номером иноды и счётчиком ссылок, тогда как симлинк — это отдельный файл, содержащий путь к целевому файлу.

Почему нельзя создавать хардлинки на каталоги или через границы файловой системы?

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

Что означает execute (x) право для каталога в Linux?

Право execute для каталога позволяет заходить внутрь каталога (search) и обращаться к файлам по имени, что необходимо для доступа к содержимому каталога.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →