Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт. В общем это суперчеловек, чрезвычайно могущественный и очень полезный. Но задумывались ли вы когда-нибудь, какую цену мы платим руту? Не думали же вы, что он работает за просто так.
Вы знаете команду df? Она показывает все подключенные сейчас диски и статистику по ним: сколько место занято, сколько свободно. Например:
$ df -m
Filesystem 1M-blocks Used Available Use% Mounted on
udev 224 1 224 1% /dev
tmpfs 48 1 47 2% /run
/dev/dm-0 9204 7421 1294 86% /Вы когда-нибудь замечали, что для локальных дисков сумма Used и Available чаще всего меньше общего размера диска? Ненамного, но меньше.
Давайте ради эксперимента попробуем занять все место на диске:
$ dd if=/dev/zero of=test bs=1M count=10240
dd: error writing ‘test’: No space left on device
1365+0 records in
1364+0 records out
1431212032 bytes (1.4 GB) copied, 2.05683 s, 696 MB/sОтлично, no space left on device. Место закончилось. Проверим:
$ df -m
Filesystem 1M-blocks Used Available Use% Mounted on
udev 224 1 224 1% /dev
tmpfs 48 1 47 2% /run
/dev/dm-0 9204 8714 0 100% /Use 100% и мы больше не можем ничего записать. Но значит ли это что никто не может. Помните, что возможности рута безграничны? Давайте попробуем под рутом, а вдруг.
$ sudo dd if=/dev/zero of=test1 bs=1M count=10240
dd: error writing ‘test1’: No space left on device
474+0 records in
473+0 records out
497000448 bytes (497 MB) copied, 0.783122 s, 635 MB/s
$ ls -lh
total 1.8G
-rw-rw-r-- 1 homm homm 1.4G Oct 6 02:37 test
-rw-r--r-- 1 root root 474M Oct 6 02:37 test1Удивительно! На совершенно забитый диск влезло еще почти полгигабайта. И вот теперь df показывает, что действительно, всё-всё, за малюсеньким исключеним, забито:
$ df -m
Filesystem 1M-blocks Used Available Use% Mounted on
udev 224 1 224 1% /dev
tmpfs 48 1 47 2% /run
/dev/dm-0 9204 9188 0 100% /Но как так получилось? Места на диске не было, а рут смог записать еще. Подождите гуглить, я за вас уже всё нагуглил. Оказывается, при создании файловой системы по умолчанию Линукс резервирует 5% под неопределенные нужды рута. Это может быть полезно для системного диска, который большую часть времени не забит под завязку и там действительно что-то может понадобиться руту. Теоретически. Но если у вас файловый сервер, к которому подключены 10 винтов по 2 терабайта, вы же просто в никуда отдаете целый терабайт места. Ведь вряд ли рут пишет на эти диски хоть что-то.
По этому поводу не устраивались митинги и демонстрации, Госдума не собиралась три раза, но тем не менее почти каждый из нас отдает руту 5% своего диска. Под его неопределенные нужды.
Как это исправить
Проще простого.
$ sudo tune2fs -m 0 /dev/dm-0
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Вуаля, теперь мы и сами без труда и без рута? можем под завязку засрать собственный диск.
$ dd if=/dev/zero of=test1 bs=1M count=10240
dd: error writing ‘test1’: No space left on device
474+0 records in
473+0 records out
496992256 bytes (497 MB) copied, 0.835994 s, 594 MB/sДанный способ совершенно безопасен, может быть использован на ходу и не требует размонтирования диска. Правда хорошо подумайте, нужно ли оно вам на системном диске.
Важное уточнение: как верно заметили в комментариях, такой резерв по умолчанию есть только на файловых системах ext3 и ext4.
Комментарии (127)
Markuzzz
06.10.2017 11:36+8А потом у вас однажды кончится свободное место и удалить с файловой системы вы уже ничего не сможете, потому что no space left on device.
homm Автор
06.10.2017 11:45-2Вы говорите так навскидку, или увас есть какое-то знание о внутреннем устройстве файловых систем ext?
Markuzzz
06.10.2017 12:06Навскидку. По-умолчанию у вас зарезервировано 5% от размера файловой системы. Вы полностью использовали все 95% файловой системы и теперь при любой операции, в том числе удалении файлов/директорий вы получите сообщение о том, что не осталось свободного места на устройстве. Теперь, для того, чтобы удалить ненужные файлы, можно уменьшить размер зарезервированного места, удалить файлы и, опционально, вернуть назад резерв. А теперь представьте, что у вас нет зарезервированного места в файловой системе и расположена она на блочном устройстве, где нет возможности увеличить размер файловой системы.
potan
06.10.2017 12:10+1Вроде как удаление файла может вызвать ошибку «не достаточно места» только на btrfs и zfs при использовании снапшетов, а на ext* всегда возможно. Или я отстал от жизни и ext3 уже как-то по новому себя ведет?
xi-tauw
06.10.2017 12:49+1Как мимокрокодил могу предположить, что потенциально вирус-майнер-патч Бармина мог забить не только все место на диске, но и всю ОЗУ. Попытка удалить файл требует загрузить исполняемый файл rm или любой другой обладающий данной функцией, но ОЗУ вся занята. Скинуть своп на диск мы не можем, так как тот тоже переполнен.
DaemonGloom
06.10.2017 13:05+1Своп всегда можно скинуть на диск, потому что он или отдельный раздел, или файл фиксированного размера. Если же для него не отключили copy-on-write в какой-нибудь btrfs, то админ — сам себе злобный буратино.
pansa
06.10.2017 23:44Что ещё за «заполнить всё ОЗУ»? o_0
Во-первых, никакого всего ОЗУ не существует, каждый процесс видит только свою виртуальную память.
Во-вторых, придёт злой OOM-killer и убьет засранца =)
Sly_tom_cat
06.10.2017 14:04+6EXT4 (она же ext2 с наворотами) дарит просто кучу проблем при 100% заполнении.
И это я говорю не потому что хорошо разбираюсь во внутреннем устройстве EXT2-3-4, XFS, BTRFS, NTFS,… а потому что уже сталкивался с такой ситуацией на практике.
DaemonGloom
06.10.2017 11:41+9Поздравляю вас. Только что вы получили смешную ситуацию — если полностью забить диск, то вы не сможете даже подключиться удаленно к серверу. Не говоря уж о том, что это место используется и самой ОС для работы с файловой системой периодически в целях избежания фрагментации (ситуация стала не так остра в ext4).
homm Автор
06.10.2017 11:42+3если полностью забить диск
Если полностью забить системный диск. Пожалуйста, пишите точнее.
DaemonGloom
06.10.2017 12:35+1Невозможность входа — да, только для системных разделов. Либо для /home, если используется графическая оболочка какая-либо.
Но фрагментация будет грозить любому диску. Хотя бы процент оставить необходимо. Иначе скорость ФС может упасть сильно.
saboteur_kiev
06.10.2017 13:20SSD/ramdisk фрагментация не грозит
darkdaskin
06.10.2017 17:16SSD грозит другая проблема. Если не останется свободных erase-блоков (размер которых может достигать нескольких мегабайт), придётся полностью перезаписывать блок для записи даже одного байта. Хотя обычно SSD держит определённый объём зарезервированным аппаратно, но при активной записи его может и не хватить.
Например, мой (довольно пожилой) смартфон начинает невыносимо тормозить, если осталось менее 1 ГБ свободного места, помогает только вайп. Видимо, контроллер недостаточно умён, чтобы производить дефрагментацию на физическом уровне и из-за фрагментации ФС оказываются занятыми все erase-блоки.
khim
06.10.2017 23:11ramdisk в Linux — это что-то новенькое (для тех кто в танке: tmpfs — это не ramdisk), а вот забив диск под завязку вы можете устроить такую фрагментацию, что и SSD не спасёт (скорости рандомного доступа и на SSD не так велики, как вам кажется — особенно для пользовательских SSD, не оптимизированных под базы данных).
DaemonGloom
07.10.2017 06:55А чем, на ваш взгляд, отличается tmpfs от ramdisk? И то, и другое — способ выделить часть ОЗУ для хранения файлов. А что туда записывать и куда смонтировать — это уже отдельный вопрос, причём настраиваемый пользователем.
khim
07.10.2017 13:57ramdisk — это выделенный под хранение файлов кусок памяти. Поверх которого «разводится» стандартная файловая система. У него фиксированный размер и когда его ёмкость «подходит к концу» на нём начинается фрагментация (хотя её последствия, конечно, не так страшны как для диска реального).
tmpfs — это просто «обьекты в памяти», которые делают вид, что они на диске, но которым «законодательно запрещено» занимать более 50% памяти. Так как для них, на самом деле, используется вся доступная память, то проблем с фрагментацией при заполнении tmpfs быть не может. А вот если занять всю память… мой рекорд — переключение с графической на текстовую консоль (где уже можно найти какую-нибудь программу и убить её) за 45 минут. Машинка не повисла, не умерла… она просто работала — то действие, которое обычно занимает секунды заняло почти час…DaemonGloom
08.10.2017 10:09Для windows есть программы, которые создают точно такие же динамические диски (например, ImDisk и Primo Ramdisk). Так что разницы в этом плане нет никакой.
khim
09.10.2017 21:05Так что разницы в этом плане нет никакой.
Разница принципиальна. У вас либо есть secondary storage, либо его нет. Например если мы взяли и отобразили файл в память — скольку у нас будет копий данных? В случае с дисковой файловой системой, в том числе с файловой системой, размещённой на диске в памяти ответ — таких копий будет две: одна — где-то в недрах page cache, другая — на, собственно, блочном устройстве. Что выглядит несколько глупо (для тех целей, для которых обычно применяется tmpfs), но иногда может иметь смысл. Так как вы, немного поработав с этим устройством, сможете его размонтировать и залить «как есть» на флешку. Или переслать на другуй компьютер. Да мало ли что может захотеться сделать с диском!
А в tmpfs никакого диска нет. Ну вот совсем нет — и всё. Cо всеми вытекающими.
P.S. Классический ramdisk в Linux, разумеется, тоже есть. Просто он редко испоьзуется. Но бывает и такое. Скажем если вы хотите создать образ дискеты или ещё что-нибудь подобное. Но это редко случается. В большинстве случаев достаточно tmpfs.saboteur_kiev
09.10.2017 22:49Что за бред? Вы троллите?
Смысл рамдиска не в количестве копий, а в том, как с этим диском работает софт.
Если я перегружаю сервер, включаю рамдиск, данные которого грузятся с образа на диске — ежу понятно, что у меня есть образ на диске и потом появится файл в памяти.
Но если я сервер не перегружаю — все программы, которые хотят прочитать данные с «диска», будут смотреть на ramdrive, и следовательно скорость работы возрастает.
Я не могу просто так держать программу в памяти, если я ее много раз запускаю и закрываю, но если я создаю виртуальное устройство, на которое кладу файлы программы — то я могу это делать, и программа не будет ничего подозревать.
Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.khim
09.10.2017 23:41Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.
И именно этого не происходит при использовании tmpfs. Там нет диска. Никакого. Ни физического, ни виртуального. Это файловая система, работающая без диска.saboteur_kiev
10.10.2017 10:44если это просто «файловая система», то отформатируйте пожалуйста какой-либо ДИСК этой файловой системой.
khim
10.10.2017 11:24А кто вам сказал, что файловая система обязана размещаться на диске? Есть сетевые файловые системы — у них диск размещается бог знает где (и его может не быть вообще), есть виртуальные файловые системы.
Это не я выдумываю — это вот прямо на страничке с описанием того, что такое файловая система написано: Some file systems are used on local data storage devices; others provide file access via a network protocol (for example, NFS, SMB, or 9P clients). Some file systems are «virtual», meaning that the supplied «files» (called virtual files) are computed on request (e.g. procfs) or are merely a mapping into a different file system used as a backing store.saboteur_kiev
10.10.2017 13:06это сказали вы.
кроме того, nfs это еще одна виртуализация, а не файловая система. Ибо на самом источнике — есть конкретная файловая система, которая и занимается хранением файлов и остальных файловых сущностей. nfs всего лишь предоставляет им доступ.
В то время, как tmpfs/ramfs — самодостаточны.
IMHO, вы слишком много читаете и воспринимаете буквально, забывая, что мир меняется и функционал, и уровень виртуализации.
Например на каком-то кластере может работать рейд, на котором работает lvm на котором лежит образ для виртуалки на virtualbox, на котором поднят например линукс, на котором лежит оракл, в котором используется оракловский ASM. В результате, на каком диске/файловой системе лежит какой-нить конкретный tablespace?
Не стоит слишком строго классифицировать.
То же деление на скриптовые и компилируемые языки тоже давно кануло в небытие.KivApple
10.10.2017 13:54кроме того, nfs это еще одна виртуализация, а не файловая система.
Это абсолютно не важно. С точки зрения системы, которая монтирует NFS, удалённого диска не существует. Она не может никак знать, что там за ФС и какой накопитель (а может быть, и нет накопителя, если на удалённой стороне используется tmpfs).
Просто есть некий чёрный ящик, который «из ничего» достаёт файлы и каталоги по запросам (на самом деле запросы приводят к генерации сетевого трафика, но это уже детали реализации NFS, в случае tmpfs сетевого трафика не будет).
Надо мыслить абстрактно :-)
saboteur_kiev
07.10.2017 11:17Для тех кто в танке:
1. Загляните в /dev/shm — 90%, что у вас это уже есть. Готовый к использованию юзерский рамдиск.
2. tmpfs это именно рамдиск, единственные два момента — по дефолту она автоматом разрастается и свопиться. Но можно ее замаунтить под именем ramfs, в этом случае она свопиться на диск не будет, а ограничение размера задать во время маунта.
Что забавно, так это то что именно tmpfs появилась на базе ramfs, еще в ядре 2.4, лет 15 уже как в ходу. А сам проект ramfs существовал еще раньше, на базе shmfs. Не слишком новенькое?khim
07.10.2017 14:02tmpfs это именно рамдиск, единственные два момента — по дефолту она автоматом разрастается и свопиться.
Для тех, кто в танке: любая файловая система начинает «плохо себя вести», когда у неё не остаётся «пространства для дыхания» — любая. ext2fs, NTFS, fat, любой zfs… в том числе если она на рамдиске. А вот ramfs/tmpfs — они, как бы, рамдиском не являются и от этой проблемы не страдают.
Загляните в /dev/shm — 90%, что у вас это уже есть. Готовый к использованию юзерский рамдиск.
Нет. Если даже забить /dev/shm «под завязку», так что там ни байта завести нельзя будет — тормоза не возникнут. Потому что это не — ramdisk.saboteur_kiev
08.10.2017 12:39«Нет. Если даже забить /dev/shm «под завязку», так что там ни байта завести нельзя будет — тормоза не возникнут. Потому что это не — ramdisk»
Это бред =)
Файловая система начинает себя плохо вести по большой части из-за фрагментации. И эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным. А это как раз флешки, ssd и конечно рамдиски.
Определение рамдиска это не «потому что он не тормозит при заполнении», а потому что он расположен в памяти (в ram).
Кроме того, под линукс хватает сторонних программ для организации виртуального рам-диска, который вы можете отформатировать в любую любимую ext2, zfs и т.д.
Просто в Linux есть поддержка рамдиска из коробки, в виде ramfs и tmpfs, которые внутри — одно и тоже, с разницей которую я пояснил выше.khim
08.10.2017 18:57эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным.
Ферритовые кольца в наше время не актуальны. И даже если использовать что-то подобное — то будут накладные расходы на поиск следующего блока. На фрагментированном диске у вас тупо будет больше экстентов и на работу с ними уйдёт больше времени.
А это как раз флешки, ssd
Вы сейчас серьёзно говорите, не шутите? Да посмотрите же, блин, на тесты. Вот — первый попавшийся в гугле: последовательное чтение — 529Мб/сек, случайное — 38МБ/сек. Разница — больше, чем на порядок.
и конечно рамдиски.
В случае с рамдисками разница тоже будет — хотя и не такая разительная.
Определение рамдиска это не «потому что он не тормозит при заполнении», а потому что он расположен в памяти (в ram).
Опять 25. Смотрю в книгу — вижу фигу. Ramdisk — это RAM + disk. Или, говоря формально, программная технология, позволяющая хранить данные в быстродействующей оперативной памяти как на блочном устройстве.
Так вот в tmpfs RAM-таки да, а disk (блочное устройство) — таки нет. Потому tmpfs и не ramdisk.
Обратите внимание что в статье про RAM-disk прямо наверху идёт отсылка на solid-state drive и tmpfs отдельно — это три похожих, но разных технологии!
На настоящем ramdisk'е при 100% заполнении тормоза таки возникнут — хотя и не такие ужасные, как на SSD или, тем более, HDD.
Просто в Linux есть поддержка рамдиска из коробки, в виде ramfs и tmpfs, которые внутри — одно и тоже, с разницей которую я пояснил выше.
Нет — ramfs и tmpfs не являются ramdisk'ом. Даже initrd уже изжит (initrmfs — это не ramdisk, там тоже нет блочного устройства).
Кроме того, под линукс хватает сторонних программ для организации виртуального рам-диска, который вы можете отформатировать в любую любимую ext2, zfs и т.д.
И вот там — вы можете получить разные забавные эффекты при заполнении оного. Но для большинства систем — это не актуально…saboteur_kiev
09.10.2017 11:07Причем тут блочное устройство?
Прошу прощения, нор прямо по вашей ссылке черным по белому написано
«A RAM drive (also called a RAM disk) is a block of random-access memory (primary storage or volatile memory) that a computer's software is treating as if the memory were a disk drive (secondary storage)»
Что в переводе означает не блочное устройство, а блок RAM, который программное обеспечение (например ОС) использует как disk drive. И все.
Все остальное — это уже классификация, насколько полно поддерживается весь интерфейс обычных дисковых устройств и отдельный тюнинг.khim
09.10.2017 13:38И все.
Не всё. Для тех, кто не понимает что обозначают слова «treating as if the memory were a disk drive» (со ссылками, объясняющими, что disk drive — это, оказывается, a block storage device) там же, ещё выше, написано чётко и отдельно: This article is about virtual drives emulated with software. For hardware storage devices using RAM, see solid-state drive. For filesystems without drive emulation, see tmpfs — чтоб уж совсем никакой путаницы не было.saboteur_kiev
09.10.2017 18:29Это просто уже различные реализации ram disk.
Ссылки в википедии не являются строгими признаками классификации, это просто для тех, кто не знает что такое disk drive — для них ссылка. Но мы то знаем, что это такое, и возможно даже больше, чем это описано на википедии.
Насчет «четко и отдельно», похоже нужно перевести и эту фразу, потому что IMHO вы просто не понимаете ее значения:
«Эта статья — про виртуальные диски, которые эмулируются при помощи ПО. Для хардварных устройств, которые используют RAM, смотрите SSD, для файловой системы без эмуляции диска — смотрите tmpfs».
Другими словами, под ramdisk называется диск, который эмулируется софтом в оперативной памяти компьютера.
Если взять планки RAM и поместить их на отдельное устройство, мы получим SSD.
tmpfs — конкретная реализация рамдиска в линукс без эмуляции устройства заслужила отдельную статью.
Если же вы интерпретируете текст иначе, мы можем спорить вечно.khim
09.10.2017 21:20Другими словами, под ramdisk называется диск, который эмулируется софтом в оперативной памяти компьютера.
Диск. Блочное устройство. На котором «сверху» надстраивается файловая система. Которое можно отмонтировать и перелить (посекторно перелить!) на другое устройство.
Ничего этого сделать с tmpfs — нельзя. Там дальше в описании RAM disk'а упоминается /dev/ram on Linux, md(4)[8] on FreeBSD, но не tmpfs — как вы думаете, почему? Да, чёрт побери, потому что в tmpfs нет диска! Это, чёрт побери, файловая система, а не блочное устройство! Одна вообще в другом ряду стоит.
Бывают диски: гибкий, жёсткий, твёрдый, и да, ещё и RAM disk.
А бывают — файловые система: FAT, NTFS, ext4 или, вот ещё, tmpfs. Это — не диски, это, чёрт побери, файловые системы — как и следует из названия!
Если же вы интерпретируете текст иначе, мы можем спорить вечно.
Ну не понимаю я о чём тут спорить! Для любого диска (в том числе для RAM disk'а — такого как/dev/ram5) я могу сделатьumount,dd(в диск или в файл) — а потом, на другой машине, соответственно,ddиmount. Если, как вы утверждаете,tmpfs— это таки диск, то для неё это должно быть возможно тоже.
Ну и? Как мне это сделать? Не подскажете?saboteur_kiev
09.10.2017 22:56Почему каждый диск обязан быть блочным устройством?
Например стриммеры — символьные. Хотите сказать кассету со стриммера нельзя побайтово перелить?
Почему вы считаете, что tmpfs нельзя замаунтить?
$ mkdir test
$ sudo mount -t tmpfs -o size=512m tmpfs test
dd — просто работает со всеми блочными устройствами, а не избирательно только с дисками.
ramfs и tmpfs — отличаются тем, что сразу реализуют rmadisk для конкретных нужд — хранить файлы. А не создают виртуальное блочное устройство для работы с dd. Но это не означает, что они перестают относиться к рамдискам.khim
10.10.2017 00:16Почему каждый диск обязан быть блочным устройством?
Потому что, чёрт побери, это определение дискового устройства.
Почему вы считаете, что tmpfs нельзя замаунтить?
Её можно замаунтить. И размаунтить тоже можно. Вот только после того, как вы её размаунтите все данные будут потеряны. Именно потому что диска под ней нету!
dd — просто работает со всеми блочными устройствами, а не избирательно только с дисками.
Она ещё и с символьными устройствами работает. Но если устройства нет (никакого — ни символьного, ни блочного), то она не работает. А раз нет устройства — то нет и RAM disk'а! Так вот в tmpfs — RAM есть, а диска — нет.
Но это не означает, что они перестают относиться к рамдискам.
Означает. В описании tmpfs очень чётко написано: A similar construction is a RAM disk, which appears as a virtual disk drive and hosts a disk file system.
Simular — это не more general, это different.
А не создают виртуальное блочное устройство для работы с dd.
Раз они не создают устройства для работы сdd— то это не диск.
Иначе что у вас тогда такое «диск» и чем оно от файловой системы отличается?
Та же история, что и с сетевыми технологиями: NBD — диск, NFS — не диск.
Они на разных уровнях абстракции работают…saboteur_kiev
10.10.2017 10:42Рамдиск по определению не должен хранить данные при перегрузке. То, что некоторые программы сохраняют образ рамдиска при выключении — это дополнительный удобный функционал, а не основной.
В общем, простите, но с вами продолжать разговор бессмысленно. Вы прицепились к слову суффиксу диск, и не видите всего слова рамдиск, который лишь эмулирует функциональность носителя информации, и совершенно не обязан эмулировать ВЕСЬ функционал.
То есть вы докапываетесь до мелочей, а не до сути. На этом откланяюсь.khim
10.10.2017 11:57Рамдиск по определению не должен хранить данные при перегрузке.
Может и хранить. Я сам лично видел RAMdisk, который таки хранил данные при перезагрузке — так как у машинки батарейка на модуле памяти была и память при перезагрузке не очищалась.
То есть вы докапываетесь до мелочей, а не до сути.
А какова сущность диска в вашем случае? Чем отличаеться файловая система от диска и каковы их свойства?
В моём мире — всё просто: диск — есть диск, он может быть гибким, оптическим и даже виртуальным, но это — блочное устройство, обращение к данным на нём происходит на уровне секторов.
А файловая система — это более высокоуровневое понятие, тут секторов уже нет, есть файлы. Она может быть дисковой, сетевой и виртуальной. В частности tmpfs — виртуальная файловая система для хранение временных данных.
А вашем мире что такое диск? Что такое RAMdisk? И что такое, наконец, файловая система? Почему вдруг у вас файловая система стала диском?
Только не надо говорить что «RAMdisk — это такая хрень», а «файловая система — это такая шняга», пожалуйста… потому что неясно как вы собираетесь что-то вообще обсуждать не имея определений, а имея только «суть, которую не выразить словами».saboteur_kiev
10.10.2017 13:09Есть программные продукты, выполняющие определенный функционал.
Зная принципы реализации этого функционала, можно четко понимать какой тип файловой системы, какие диски, какое ПО использовать в конкретном случае.
Если же брать ваше — то в каждом конкретном случае использовать диск? почему? какой? зачем нам просто невнятное «блочное устройство»?
Нужно понимать принципы реализации, и отталкиваться от них, а не от устаревшей классификации.
Всю терминологию стоит использовать с оговорками, поскольку четкое определение редко когда может охватить ВСЕ существующие реализации в силу устаревания.
Chugumoto
06.10.2017 12:04«Но если у вас файловый сервер, к которому подключены 10 винтов по 2 терабайта, вы же просто в никуда отдаете целый терабайт места.»
эм… на файловом сервере просто так подключены диски?
сдается мне они таки в 10 или 5ый рейд собраны например…
итого никакого терабайта… ну 0,5 или 0,66 может…saboteur_kiev
06.10.2017 12:22+2А рейд просто так подключен на файловом сервере?
Сдается мне, он таки отформатирован в ext3/ext4 например.
Итого — именно 5% от 10*2 терабайта, поделить на расходы 10-го или 5-го рейда, может наскрестись под терабайт.Chugumoto
06.10.2017 13:39ну… лучше использовать аппаратный рейд-контроллер.
в итоге при 10ом рейде из 10 2тб винтов система у нас будет видеть одно устройство на 10тб. и когда мы его отформатируем… то от этого 5% будет 0.5тб, а никак не 1, если бы просто монтировали 10 2тб винтов, с которых да 10*0.1тб…homm Автор
06.10.2017 13:44+5Это действительно имеет значение? 5% останутся 5% при любом размере диска.
saboteur_kiev
06.10.2017 14:34+2Какая разница какой контроллер для рейда использовать? размер диска от организации рейда не зависит, только от его уровня. И в любом случае мы в конечном счете создаем файловую систему с теми же 5%, вне зависимости там один диск или рейд на сто дисков.
Chugumoto
06.10.2017 16:09вот именно! 5% от массива, но не 5% от объема входящих в него дисков.
а страйп на файловом сервере я думаю никто использовать не будет.
я об этом
пс: а контроллер… некоторые программные под никсами у меня выглядели не как одно устройство, а именно как контроллер и винты отдельно были… и только при установке дров…saboteur_kiev
06.10.2017 17:061. Про то, что диски собраны в рейд — вы придумали сами, и тут же на фоне этой выдумки начали сочинять про разницу между 1 тб и 500 гб.
2. Даже лишние 500 гб — тоже весьма немаленький объем.
3. Страйп на файловом сервере — как раз вполне даже адекватный вариант. Это же не массив для корпоративного приложения или базы данных. Файловый сервер — чаще всего файлопомойка. И даже если это общий диск с файлами пользователей, бывает вполне достаточно регулярного бэкапа, вместо 5-го рейда.
4. Какая разница сколько там устройств. 5% резервируются на конечной файловой системе, неважно где она была создана — на единичном диске или массиве или рамдиске (кстати рамдиске).
havock
06.10.2017 18:38-2У вас арифметика какая? По модулю 10? Как у вас 10 винтов по 2 ТБ дали RAID объемом 10 ТБ ??? 10*2=10 ??? Вот тут у вас расчеты и поехали. А так 5% все тот же 1 терабайт. Комментаторы, вы хоть пересчитывайте числа в чужих комментах.
Grief
06.10.2017 20:51+1Емкость RAID10 = 50%
havock
07.10.2017 03:44-3логическая, но не физическая, и, к тому же, как это влияет на процент? мы в любом случае теряем те же 5%, то есть 1 терабайт физического объема, вопрос того, что там хранится копия информации и система вопринимает две физических области как одну логическую не влияет на относительные потери никак
Sly_tom_cat
06.10.2017 14:25А просто не надо бездумно ничего делать. Если форматируете в EXT4 то уберите резерв рута (если он не нужен конечно). А если форматирует в XFS, например, то уже никаких резервов не будет.
Mnemonik
06.10.2017 12:17+28Пора открывать раздел «Хабр для самых маленьких».
Этой статьей можно его достойно открыть. Только сменить желтушное название на более подходящее по смыслу «Как я сам сделал открытие написанное в первой главе любого руководства по администрированию Linux не читая их и сразу написал про это статью на самый большой ИТ ресурс России».homm Автор
06.10.2017 12:44+4Я бы назвал раздел «Последний шанс самоутвердиться для тех, кто уже все знает» )
sevikl
06.10.2017 13:43+2я бы назвал «как программисту залезть туда, куда не надо». пишите на пистоне, не лезьте в администрирование
devop-su
06.10.2017 23:45+2Увы и ах!
Оказывается если к коротенькому комментарию с ServerFault
добавить заголовок с сайта газеты Жизнь,
то получается целая статья для хабра образца 2017 гэ
Makaronin
06.10.2017 12:23+2Все таки 5% оправданы на системном разделе, как определенного рода защитный буфер от возможности выпалить в «no space left on device».
Автору стоило бы наверное проверить и другие варианты использования и последствий своих манипуляций.
Darka
06.10.2017 12:55+7Автор, открыл для себя резервирование блоков на ext(2|3|4) файловой системе. Похвально.
ABATAPA
06.10.2017 13:06-1О боже ты мой! Всегда хотел увидеть, как выглядит тот самый man. Так вот оно как… :)
PravdorubMSK
06.10.2017 13:09-1Михалков — это который режиссер?
homm Автор
06.10.2017 13:17Российский
PravdorubMSK
06.10.2017 15:43-2Как человек и агитатор Михалков может и не очень.
Но полная версия «Утомленные Солнцем 2» у меня вызвала восхищение. Это самый прекрасный, страшный и романтичный фильм о тех годах. Тут Михалков превзошёл всех. более лучшего кино о войне я не видел.homm Автор
06.10.2017 15:58+1Ох. Похоже вы просто не поняли, при чем тут Михалков. Вот: http://www.bbc.com/russian/russia/2010/10/101026_mikhalkov_dvd_tax.shtml
SADKO
07.10.2017 12:16-1Ну и чем же root хуже Никиты Сергеевича?
Из вашего-же поста следует, что аппетит у root-a есть и его можно уменьшить, что вообще-то не секрет не разу, но не суть…
… иное дело аппетиты Михалкова, которого эпизодически пытаются согнать с кормушки, но даже если этот день случиться, проблемы это никак не решает. Какие маны тут курить, в какой консоль чего вводить? Михалков — хуже root-a!
utoplenick
06.10.2017 13:13+7Такими темпами хабр скоро в лайфру превратится: «Скандалы интриги расследования ext2/3/4 безнаказанно пожирает дисковое пространство! Хватит это терпеть!!! „
avallac
06.10.2017 13:17+3Какой позор, автор считает, что создатели Linux дураки?
По опыту скажу, что ни раз сталкивался с ситуацией, когда этот небольшой резерв очень помогал, например загзипить какие-то данные. И вообще место для маневра нужно не только на системном диске. Очень редко требуется полная утилизация диска, чтобы положить в 0 и забыть. Для рабочих систем обычно если 80% заполнения => чистка или расширение.
Выглядит как бедный бизнес, который не может позволить себе несколько % в резерв, но при этом потеряв гораздо больше на последствиях.
NeiroNext
06.10.2017 13:31Думал почему то что об этом известно достаточно давно, ведь при установке (во всяком случае в консольном режиме), на стадии разбивки диска указывается опция выбора процентного выделения резервного размера для рута.
Хотя пользы от него и правда не очень много, теоретически произойти может всякое и дополнительное свободное место для суперпользователя может спасти сервер, дав возможность админу свободу действий даже при полностью забитом диске, при возникновении какой то непредвиденной ошибки с заполнения всего диска.
Sly_tom_cat
06.10.2017 13:54+1Место резервирует не Linux а файловая система ext4!!!!
Учите матчасть чтобы не писать такие безграмотные статьи!
Поставьте систему на btrfs/xfs/… список можно долго продолжать. И у вас не будет 5% резерва на рута.
Но резерв на рута оставлен не просто так а со смыслом. Он нужен для записи логов когда ваш ком уже умирает от полного заполнения корневого раздела. Т.е. вы хотя бы сможете потом узнать что и как и почему умерло.
Ну а то что многие форматируют свои терабайтные винты в EXT4 и потом возмущаются резервом рута — ССЗБ. EXT2 (и унаследовавшие ее систему хранения данных на диске ext3 и ext4) никогда не разрабатывалась для работы на больших дисках. Для этого, к примеру, разрабатывалась изначально XFS и более свежая BTRFS.
Makaronin
06.10.2017 17:11А утверждение «резервирует для root» как я понимаю не очень соответствует действительности.
Т.к резервирование происходит на этапе создания файловой ситсемы, а возможности root по записи в эту область просто одна из «необходимостей — вседозволенностей» данного уровня доступа. По мне логичный название данной статьи было бы «Ext4 хуже...». А переход к описанию возможностей root в данном вопросе это уже притянуто из-за «не очень полного» понимания автором сути вопроса.
zuborg
06.10.2017 14:03Самое смешное в этой истории (истерии? :) для меня в том, что рут к этому резерву вообще никакого отношения не имеет (ну, исключая то, что руту все же получится записать больше, чем остальным). Это место резервируется из соображений производительности — пустые области получаются большего размера, в них проще (и быстрее) находить свободные блоки для новых данных, ну и меньше фрагментация файлов, что для шпиндельных дисков крайне существенно. Современные SSD тоже имеют подобную систему — они показывают операционке меньший объем, чем установлено чипов, чтобы иметь резерв свободных блоков для новых данных или поврежденных блоков (которые ремапятся).
Так что на шпиндельных дисках стоит оставлять этот резерв 5-8 процентов, а на SSD можно вполне безопасно уменьшить до 1-2 процентов (небольшой резерв все же стоит делать, иначе при сильном заполнении диска будет больше нагрузка на проц и сильнее фрагментация файлов).Sly_tom_cat
06.10.2017 14:11Вы не правы. 5% про котрые статья — никакого отношения к производительности не имеет.
EXT4 (точнее сказать: EXT2 c наворотами и бантиками) сама по себе очень хорошо фрагментирует большие файлы просто потому что они не влезают в одну группу хранения. И никакие 5% ей не помогут.zuborg
06.10.2017 14:20Все-таки имеют )
Вы ж не забывайте, что 5% на современном 6ТБ диске и 5% на 60ГБ дисках времен, когда разрабатывались ext и другие фс — это две большие разницы.
Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.Sly_tom_cat
06.10.2017 14:31+2Просто не надо большие диски форматировать ext-ами. Они только на свои системные нужды отъедают ~1,8% сразу после форматирования (оно именно потому такое тормозное в EXT по сравнению например с форматированием XFS или BTRFS). Плюс 5% резерва рута (которые либо после надо убрать либо при форматировании ключами задушить в зародыше).
Для примера XFS на системные нужды, сразу после форматирования забирает ~0.06%.
Статическая алокация i-node в ext2-3-4 — тоже тот еще «подарок», все нормальные ФС уж давно динамически их аллокируют.iamsens
07.10.2017 12:26Скажите, «нормальные» это какие?
Sly_tom_cat
07.10.2017 20:24BTRFS, XFS, ZFS, RaiserFS/Raiser4, NTFS — тоже, хотя там оно не i-node называется и еще некоторые другие ФС.
Статическая аллокация inide в EXT — это атавизм тянущийся с самого первого релиза ФС EXT2. Все последующие (3 и 4) тянут за собой не только этот атавизм, но много других.
Нет, я не считаю EXT4 плохой ФС. Она вполне подходит для небольших разделов отведенных под корень системы (резерв рута в этом случае большой плюс, а не минус, как его преподносит автор статьи).
Но для больших и не корневых разделов EXT4 годится уже гораздо хуже, ИМХО.
Для больших разделов я бы посоветовал использовать XFS или BTRFS.
saboteur_kiev
08.10.2017 01:20ext4 умеет в динамические iNode
Sly_tom_cat
08.10.2017 10:03+1Нет. Все inode ext2/3/4 выделяются при форматировании и их число можно только утилитой изменить, но это никакая не динамика. Динамика это когда нужен новый inode он аллкируется из свободного пространства, а когда inode освобождается он деалокируется превращаясь в свободное место.
pansa
06.10.2017 23:54Ну, положим, XFS и ext вполне себе одногодки. ZFS вот очень крута и моложе, и может ворочать огромными разделами, и это даже больше, чем ФС. Однако, посмотрите, как она себя поведет при заполнении >85%.
Sly_tom_cat
07.10.2017 20:36+1Одногодки то они одногодки (почти) только вот XFS создавалась для больших дисков изначально. Это было в целях.
А для EXT — такой цели не стояло в принципе. Именно поэтому там группа распределения в 65535 блоков и в каждую группу прибито гвоздями заголовок, индексы распределения (или битовые поля в ext2-3) и пачка преалокированных i-node (которые кстати сказать могут использоваться для указания на данные не обязательно в текущей группе). И таких групп на небольшом разделе создаются стони, а на Террабайтных дисках там уже тысячи и десятки тысяч групп.
У XFS тоже есть группы только их на всю ФС создается 3-4 штуки (не зависимо от размера раздела) и служат они совсем для других целей нежели группы в EXT-ах. В XFS они имеют свои наборы метаданных, что позволяет вести асинхронную запись. Сколько групп в XFS на столько потоков можно распределить параллельные потоки записи.
По ZFS — ничего не скажу — не пробовал, я больше BTRFS интересуюсь в последнее время. Вот она на 100% заполнении вполне адекватно себя ведет за счет небольшого резерва под метаданные который именно на ситуацию с 100% заполнением ФС и рассчитан.pansa
08.10.2017 00:00Одногодки, практически 1 к 1 =)
Да я и не спорю, что XFS лучше подходит под большие разделы.
Меня смутило именно использование возраста, как критерия. И всё.
khim
07.10.2017 00:05Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.
На самом деле на многоТБ дисках и массивах резервировать нужно больше, а не меньше.
homm Автор
06.10.2017 14:16Разница с SSD в том, что в случае SSD вы платите за какой-то объем, который написан на коробке, его и получаете. Пусть там внутри хоть в 10 раз больше чипов. В случае же резервирования диска для рута, вы платите за диск определенного объема, но во многих случаях не можете им воспользоваться полностью.
sotnikdv
06.10.2017 16:35А потом вы при редактировании конфигов разрушите сервер, например. Для этого резервирования есть причина, дать руту запас на экстренные случаи.
Был 10 лет назад подобный гений, который при реально полном диске начал редактировать конфиги. Паттерну создать новый, удалить старый, переименовать следуют далеко не все.
iig
06.10.2017 18:25+1Эх, все уже сказано, сложно будет что-то добавить :(
Попытаюсь.
Если уж ухитрились выстрелить себе в ногу этим странным способом — удалить пару файлов, чтобы освободить место, можно попытаться с помощью утилиты debugfs. (Сорри, не проверял, сработает ли при 105% занятого места). Можно преобразовать ext3(4) в ext2 (tune2fs) .
demimurych
06.10.2017 22:17а еще, рут, совсем не обязательно, в современной linux системе, может все все.
justhabrauser
07.10.2017 01:06Неделя КО на канале…
Я Вам (КО) больше скажу — в линухе можно удалить файл (и он таки будет удален) — но читать с него (файла) данные можно до тех пор, пока этот файл открыт.
Еще можно получать логи ошибок уже после того, как / забит под завязку. Спустя много месяцев, ога. RAM потому что.
ntfs1984
08.10.2017 00:33-2Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт.
Дальше эту желтую статью читать не стал. Автор явно не в курсе, чего может root, и чего не может.
Пример:
[root@brix ntfs]# rm wifi.zip rm: cannot remove 'wifi.zip': Operation not permitted [root@brix ntfs]# whoami root [root@brix ntfs]# ls -l total 888 drwxr-xr-x 2 ntfs users 3488 Sep 21 00:59 Desktop drwxrwxrwx 2 root root 3488 Jan 11 2017 'Desktop Wallpapers' drwxr-xr-x 3 ntfs users 3488 Sep 28 23:35 Documents drwxr-xr-x 2 ntfs users 3488 Oct 7 01:18 Downloads drwxr-xr-x 2 ntfs users 3488 Oct 1 23:17 eric_wedding drwxr-xr-x 5 ntfs users 3488 Aug 7 07:48 freelancer-desktop-app lrwxrwxrwx 1 ntfs users 10 Sep 25 12:27 Music -> /ssd/music drwxr-xr-x 2 ntfs users 4096 Oct 6 21:58 Pictures drwxr-xr-x 2 ntfs users 3488 Sep 21 00:59 Public drwxr-xr-x 2 ntfs users 3488 Sep 21 00:59 Templates drwx------ 3 ntfs users 3488 Sep 25 21:41 tor-browser_en-US drwxr-xr-x 2 ntfs users 3488 Sep 21 00:59 Videos drwxr-xr-x 2 ntfs users 3488 Sep 21 02:08 web drwxr-xr-x 2 ntfs users 3488 Sep 27 22:28 wifi -rwxrwxrwx 1 ntfs users 835652 Sep 27 22:28 wifi.zip drwxr-xr-x 20 ntfs users 3488 Sep 26 02:22 www [root@brix ntfs]#saboteur_kiev
08.10.2017 01:22Файловая система подмаунчена как ro с удаленной машины? Ну так если рут, подмаунтите ее с rw правами, либо выдайте рутовые права именно там, где лежат файлы, а то больше похоже на троллинг.
Tomok
08.10.2017 10:36Спасибо за статью, теперь в моём DAS'е стало немножко больше места.
Правильно ли я понял, что эти 5% не нужны системе для дефрагментации, если на диске ещё достаточно места? Если в системе несколько разделов на разных физических дисках и в одном из разделов отключён этот 5%-ый резерв, будет ли система использовать 5% другого раздела для своих нужд?khim
08.10.2017 11:51По-моему вы слишком многое приписываете этим 5%. Они вообще никак не влияют на работу файловой системы. Ни положительно, ни отрицательно. Просто когда файловая система (любая) заполнена на 80%-90% в ней начинаются проблемы с фрагментацией. В каких-то файловых системах проблемы начинаются раньше, в каких-то позже, но забив диск «под завязку» тормоза вы получите в любой (а на некоторых, в частности XFS старых ревизий — так и данные начнут теряться). Так как людям об этом думать лень, то в ext2/3/4 было 5% под это зарезервировано под это дело. А на root'а это ограничение не распространяется, так как лучше уж дать системе возможность «тормозить», чем «виснуть».
9660
09.10.2017 06:19Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт.
Справедливости ради, все это неверно.
zmitrok62
09.10.2017 14:41Если существует резервирование 5% объема — значит кто-то посидел, подумал, нашел какие-то значимые причины и сделал. И тут появляется человек — «эффективное использование пространства» и отменяет.
А Вы не думали например, что сервисы при полностью забитом пространстве будут крашиться? Что Вы не сможете зайти по SSH на сервак, который в другой стране… Ну не надо думать что Вы умнее других.
Вы еще вместо автоматов в электрическом щитке — проволоки намотейте. Экономия, однако, автоматы не надо покупать.
ooki2day
А если я воспользуюсь руководством автора, мой винч забьет какой-нибудь майнервирусчтоугодно, как быть? Имеет ли обратное дествие команда sudo tune2fs -m 0 /dev/dm-0?
kornerz
или любое количество процентов вместо 3.
В дополнение, tune2fs работает только на ext2/ext3/ext4, для остальных файловых систем — не актуально.
ooki2day
Тогда следующий вопрос — сделали 0%, заполнили диск, делаем 3%. Что будет удалено? Изначально к этому и клонил:)
kornerz
Ничего не будет удалено — это просто опция файловой системы, управляющая отображением свободного/занятого места. В «правильных» условиях можно и 105% Used получить.
potan
Но для этого надо войти в систему, что при забитом диске может и не получиться.
tru_pablo
Ну, Миш! Написано же честно
potan
Я не вижу причин в 21 веке делить диск на системный и пользовательский раздел.
homm Автор
Вы серьезно? )
Случай раз: сервер бд. База на отдельном большом диске, система на маленьком. В случае чего можно прицепить к диску новую систему или к системе другой диск (в зависимости от типа чп)
Случай два: файловые сервера с автоскейлингом, которым нужен большой кеш. Во время запуска нового сервера быстро восстанавливается маленький образ системного диска и подключается пустой большой диск под кеш.
potan
СУБД, конечно, особый случай. Я больше про десктоп, на серверах вообще с разервной областью играться я бы не стал.
iig
А смысл этой игры на десктопе? Эти 5% могут пригодиться, если для приложений и демонов под не-root правами место кончилось (и они зависли/упали), а для root — еще нет. Можно ребутнуть (init и стартовые скрипты отработают), можно зайти под root локально и попытаться хотя бы что-то исправить…
aggeisoft
Ну классика же. Отдельный home. Переустанавливая/меняя систему на другую — не теряем данные и даже сохраняем настройки ПО.
По поводу % под рута. В текстовом режиме установки той же Ubuntu — это настраивается на этапе установки — и по собственному опыту скажу — надо оставлять минимум 1 % — при 100% заполнении диска — система может не загрузиться — придется использовать всякие livecd и прочее.
Busla
… и она скорее всего не лезет на раздел созданный несколько лет назад :-)
DrZlodberg
Всегда делю. Я не труъ админ и могу систему слегка поломать. Ну и сама она иногда… портится :) Да и обновление системы на следующий релиз автоматом как-то не очень идёт поверх старой. А тут просто форматнул системный и точно не грохнешь свою инфу. Накатил новую — и все настройки уже готовы. Да, есть минус, что системный не используется на полную, зато я всегда уверен и без этих колдунств, что там есть место.
LorHobbit
Причина наипрозрачнейшая: можно переустановить систему с нуля и при этом сохранить все свои данные и настройки. Например, в моём /home некоторые файлы тянутся аж с 2003 года, при том, что за это время у меня сменилось несколько дистрибутивов линукса и три системных блока.
И да, я про десктоп.
potan
Переустанавливал систему поверх существующей несколько раз. Правда однотипную Gentoo после Gentoo, Ububtu после Debian. Просто пропуская создание FS, проблем не было. Да и редкая это операция — переустановка системы.