Комментарии 140
Имеет ли обратное дествие команда
sudo tune2fs -m 3 /dev/dm-0
или любое количество процентов вместо 3.
В дополнение, tune2fs работает только на ext2/ext3/ext4, для остальных файловых систем — не актуально.
Это может быть полезно для системного диска, который большую часть времени не забит под завязку и там действительно что-то может понадобиться руту.
Вы серьезно? )
Случай раз: сервер бд. База на отдельном большом диске, система на маленьком. В случае чего можно прицепить к диску новую систему или к системе другой диск (в зависимости от типа чп)
Случай два: файловые сервера с автоскейлингом, которым нужен большой кеш. Во время запуска нового сервера быстро восстанавливается маленький образ системного диска и подключается пустой большой диск под кеш.
А смысл этой игры на десктопе? Эти 5% могут пригодиться, если для приложений и демонов под не-root правами место кончилось (и они зависли/упали), а для root — еще нет. Можно ребутнуть (init и стартовые скрипты отработают), можно зайти под root локально и попытаться хотя бы что-то исправить…
По поводу % под рута. В текстовом режиме установки той же Ubuntu — это настраивается на этапе установки — и по собственному опыту скажу — надо оставлять минимум 1 % — при 100% заполнении диска — система может не загрузиться — придется использовать всякие livecd и прочее.
И да, я про десктоп.
Вы говорите так навскидку, или увас есть какое-то знание о внутреннем устройстве файловых систем ext?
Во-первых, никакого всего ОЗУ не существует, каждый процесс видит только свою виртуальную память.
Во-вторых, придёт злой OOM-killer и убьет засранца =)
И это я говорю не потому что хорошо разбираюсь во внутреннем устройстве EXT2-3-4, XFS, BTRFS, NTFS,… а потому что уже сталкивался с такой ситуацией на практике.
если полностью забить диск
Если полностью забить системный диск. Пожалуйста, пишите точнее.
Но фрагментация будет грозить любому диску. Хотя бы процент оставить необходимо. Иначе скорость ФС может упасть сильно.
SSD грозит другая проблема. Если не останется свободных erase-блоков (размер которых может достигать нескольких мегабайт), придётся полностью перезаписывать блок для записи даже одного байта. Хотя обычно SSD держит определённый объём зарезервированным аппаратно, но при активной записи его может и не хватить.
Например, мой (довольно пожилой) смартфон начинает невыносимо тормозить, если осталось менее 1 ГБ свободного места, помогает только вайп. Видимо, контроллер недостаточно умён, чтобы производить дефрагментацию на физическом уровне и из-за фрагментации ФС оказываются занятыми все erase-блоки.
tmpfs — это просто «обьекты в памяти», которые делают вид, что они на диске, но которым «законодательно запрещено» занимать более 50% памяти. Так как для них, на самом деле, используется вся доступная память, то проблем с фрагментацией при заполнении tmpfs быть не может. А вот если занять всю память… мой рекорд — переключение с графической на текстовую консоль (где уже можно найти какую-нибудь программу и убить её) за 45 минут. Машинка не повисла, не умерла… она просто работала — то действие, которое обычно занимает секунды заняло почти час…
Так что разницы в этом плане нет никакой.Разница принципиальна. У вас либо есть secondary storage, либо его нет. Например если мы взяли и отобразили файл в память — скольку у нас будет копий данных? В случае с дисковой файловой системой, в том числе с файловой системой, размещённой на диске в памяти ответ — таких копий будет две: одна — где-то в недрах page cache, другая — на, собственно, блочном устройстве. Что выглядит несколько глупо (для тех целей, для которых обычно применяется tmpfs), но иногда может иметь смысл. Так как вы, немного поработав с этим устройством, сможете его размонтировать и залить «как есть» на флешку. Или переслать на другуй компьютер. Да мало ли что может захотеться сделать с диском!
А в tmpfs никакого диска нет. Ну вот совсем нет — и всё. Cо всеми вытекающими.
P.S. Классический ramdisk в Linux, разумеется, тоже есть. Просто он редко испоьзуется. Но бывает и такое. Скажем если вы хотите создать образ дискеты или ещё что-нибудь подобное. Но это редко случается. В большинстве случаев достаточно tmpfs.
Смысл рамдиска не в количестве копий, а в том, как с этим диском работает софт.
Если я перегружаю сервер, включаю рамдиск, данные которого грузятся с образа на диске — ежу понятно, что у меня есть образ на диске и потом появится файл в памяти.
Но если я сервер не перегружаю — все программы, которые хотят прочитать данные с «диска», будут смотреть на ramdrive, и следовательно скорость работы возрастает.
Я не могу просто так держать программу в памяти, если я ее много раз запускаю и закрываю, но если я создаю виртуальное устройство, на которое кладу файлы программы — то я могу это делать, и программа не будет ничего подозревать.
Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.
Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.И именно этого не происходит при использовании tmpfs. Там нет диска. Никакого. Ни физического, ни виртуального. Это файловая система, работающая без диска.
Это не я выдумываю — это вот прямо на страничке с описанием того, что такое файловая система написано: 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.
кроме того, nfs это еще одна виртуализация, а не файловая система. Ибо на самом источнике — есть конкретная файловая система, которая и занимается хранением файлов и остальных файловых сущностей. nfs всего лишь предоставляет им доступ.
В то время, как tmpfs/ramfs — самодостаточны.
IMHO, вы слишком много читаете и воспринимаете буквально, забывая, что мир меняется и функционал, и уровень виртуализации.
Например на каком-то кластере может работать рейд, на котором работает lvm на котором лежит образ для виртуалки на virtualbox, на котором поднят например линукс, на котором лежит оракл, в котором используется оракловский ASM. В результате, на каком диске/файловой системе лежит какой-нить конкретный tablespace?
Не стоит слишком строго классифицировать.
То же деление на скриптовые и компилируемые языки тоже давно кануло в небытие.
кроме того, nfs это еще одна виртуализация, а не файловая система.
Это абсолютно не важно. С точки зрения системы, которая монтирует NFS, удалённого диска не существует. Она не может никак знать, что там за ФС и какой накопитель (а может быть, и нет накопителя, если на удалённой стороне используется tmpfs).
Просто есть некий чёрный ящик, который «из ничего» достаёт файлы и каталоги по запросам (на самом деле запросы приводят к генерации сетевого трафика, но это уже детали реализации NFS, в случае tmpfs сетевого трафика не будет).
Надо мыслить абстрактно :-)
1. Загляните в /dev/shm — 90%, что у вас это уже есть. Готовый к использованию юзерский рамдиск.
2. tmpfs это именно рамдиск, единственные два момента — по дефолту она автоматом разрастается и свопиться. Но можно ее замаунтить под именем ramfs, в этом случае она свопиться на диск не будет, а ограничение размера задать во время маунта.
Что забавно, так это то что именно tmpfs появилась на базе ramfs, еще в ядре 2.4, лет 15 уже как в ходу. А сам проект ramfs существовал еще раньше, на базе shmfs. Не слишком новенькое?
tmpfs это именно рамдиск, единственные два момента — по дефолту она автоматом разрастается и свопиться.Для тех, кто в танке: любая файловая система начинает «плохо себя вести», когда у неё не остаётся «пространства для дыхания» — любая. ext2fs, NTFS, fat, любой zfs… в том числе если она на рамдиске. А вот ramfs/tmpfs — они, как бы, рамдиском не являются и от этой проблемы не страдают.
Загляните в /dev/shm — 90%, что у вас это уже есть. Готовый к использованию юзерский рамдиск.Нет. Если даже забить /dev/shm «под завязку», так что там ни байта завести нельзя будет — тормоза не возникнут. Потому что это не — ramdisk.
Это бред =)
Файловая система начинает себя плохо вести по большой части из-за фрагментации. И эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным. А это как раз флешки, ssd и конечно рамдиски.
Определение рамдиска это не «потому что он не тормозит при заполнении», а потому что он расположен в памяти (в ram).
Кроме того, под линукс хватает сторонних программ для организации виртуального рам-диска, который вы можете отформатировать в любую любимую ext2, zfs и т.д.
Просто в Linux есть поддержка рамдиска из коробки, в виде ramfs и tmpfs, которые внутри — одно и тоже, с разницей которую я пояснил выше.
эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным.Ферритовые кольца в наше время не актуальны. И даже если использовать что-то подобное — то будут накладные расходы на поиск следующего блока. На фрагментированном диске у вас тупо будет больше экстентов и на работу с ними уйдёт больше времени.
А это как раз флешки, 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 и т.д.И вот там — вы можете получить разные забавные эффекты при заполнении оного. Но для большинства систем — это не актуально…
Прошу прощения, нор прямо по вашей ссылке черным по белому написано
«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. И все.
Все остальное — это уже классификация, насколько полно поддерживается весь интерфейс обычных дисковых устройств и отдельный тюнинг.
И все.Не всё. Для тех, кто не понимает что обозначают слова «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 — чтоб уж совсем никакой путаницы не было.
Ссылки в википедии не являются строгими признаками классификации, это просто для тех, кто не знает что такое disk drive — для них ссылка. Но мы то знаем, что это такое, и возможно даже больше, чем это описано на википедии.
Насчет «четко и отдельно», похоже нужно перевести и эту фразу, потому что IMHO вы просто не понимаете ее значения:
«Эта статья — про виртуальные диски, которые эмулируются при помощи ПО. Для хардварных устройств, которые используют RAM, смотрите SSD, для файловой системы без эмуляции диска — смотрите tmpfs».
Другими словами, под ramdisk называется диск, который эмулируется софтом в оперативной памяти компьютера.
Если взять планки RAM и поместить их на отдельное устройство, мы получим SSD.
tmpfs — конкретная реализация рамдиска в линукс без эмуляции устройства заслужила отдельную статью.
Если же вы интерпретируете текст иначе, мы можем спорить вечно.
Другими словами, под 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
— это таки диск, то для неё это должно быть возможно тоже.Ну и? Как мне это сделать? Не подскажете?
Например стриммеры — символьные. Хотите сказать кассету со стриммера нельзя побайтово перелить?
Почему вы считаете, что tmpfs нельзя замаунтить?
$ mkdir test
$ sudo mount -t tmpfs -o size=512m tmpfs test
dd — просто работает со всеми блочными устройствами, а не избирательно только с дисками.
ramfs и tmpfs — отличаются тем, что сразу реализуют rmadisk для конкретных нужд — хранить файлы. А не создают виртуальное блочное устройство для работы с dd. Но это не означает, что они перестают относиться к рамдискам.
Почему каждый диск обязан быть блочным устройством?Потому что, чёрт побери, это определение дискового устройства.
Почему вы считаете, что 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 — не диск.
Они на разных уровнях абстракции работают…
В общем, простите, но с вами продолжать разговор бессмысленно. Вы прицепились к слову суффиксу диск, и не видите всего слова рамдиск, который лишь эмулирует функциональность носителя информации, и совершенно не обязан эмулировать ВЕСЬ функционал.
То есть вы докапываетесь до мелочей, а не до сути. На этом откланяюсь.
Рамдиск по определению не должен хранить данные при перегрузке.Может и хранить. Я сам лично видел RAMdisk, который таки хранил данные при перезагрузке — так как у машинки батарейка на модуле памяти была и память при перезагрузке не очищалась.
То есть вы докапываетесь до мелочей, а не до сути.А какова сущность диска в вашем случае? Чем отличаеться файловая система от диска и каковы их свойства?
В моём мире — всё просто: диск — есть диск, он может быть гибким, оптическим и даже виртуальным, но это — блочное устройство, обращение к данным на нём происходит на уровне секторов.
А файловая система — это более высокоуровневое понятие, тут секторов уже нет, есть файлы. Она может быть дисковой, сетевой и виртуальной. В частности tmpfs — виртуальная файловая система для хранение временных данных.
А вашем мире что такое диск? Что такое RAMdisk? И что такое, наконец, файловая система? Почему вдруг у вас файловая система стала диском?
Только не надо говорить что «RAMdisk — это такая хрень», а «файловая система — это такая шняга», пожалуйста… потому что неясно как вы собираетесь что-то вообще обсуждать не имея определений, а имея только «суть, которую не выразить словами».
Зная принципы реализации этого функционала, можно четко понимать какой тип файловой системы, какие диски, какое ПО использовать в конкретном случае.
Если же брать ваше — то в каждом конкретном случае использовать диск? почему? какой? зачем нам просто невнятное «блочное устройство»?
Нужно понимать принципы реализации, и отталкиваться от них, а не от устаревшей классификации.
Всю терминологию стоит использовать с оговорками, поскольку четкое определение редко когда может охватить ВСЕ существующие реализации в силу устаревания.
Если же брать ваше — то в каждом конкретном случае использовать диск? почему? какой? зачем нам просто невнятное «блочное устройство»?Потому что «над ним» мы можем развести ту файловую систему, какая нам нужна. В Windows 2000, к примеру, не было символических ссылок, а в Windows 7 — они есть. На работу RAMdisk'а всё это не влияет никак.
Можно snapshot'ы снимать через LVM и так далее. Весь арсенал средств, работающих с блочными устройствами — к вашим услугам.
Всю терминологию стоит использовать с оговорками, поскольку четкое определение редко когда может охватить ВСЕ существующие реализации в силу устаревания.Это правда, конечно, но в данном случае польза от использования терминологии понятна, а вред — сомнителен. В то же время исскусственное помещение
tmpfs
в раздел дисков (пусть и виртуальных) немедленно поднимает вопрос о применимости подобной конструкции…Это — дополнительный функционал.
То, что имеет значение — это то, что рамдиск хранится в оперативной памяти, а не в отдельном устройстве. Это единственный и основной признак классификации рамдиска. Все остальные вещи — типа эмуляция интерфейса блочного устройства, возможность использования нужной вам файловой системы — это второстепенное. ramfs/tmpfs поддерживают POSIX, этого уже достаточно.
Не нравится — используйте стороннее решение, возможно платное. Но считать при этом эту технологию не рамдиском — бред.
Это единственный и основной признак классификации рамдиска.Тогда у вас в каждом процессе свой, индувидуальный ramdisk благодаря fmemopen. И procfs/sysfs у вас тогда — тоже RAMdisk'и.
ramfs/tmpfs поддерживают POSIX, этого уже достаточно.О как? То есть у вас в Windows теперь вообще RAMdisk'ов нет — пока вы Ubuntu не поставите?
Обратите внимание, что
tmpfs
только в заголовке соотвествующей статьи — в теле фигурируют NTFS
, HFS
, /dev/ram
— но никак не tmpfs
.Знаете почему? Потому что ссылка на
tmpfs
оттуда была удалёна — с комментарием tmpfs isn't a RAM drive, it's a file system that lives in virtual memory, as the hatnote indicates — it doesn't dedicate a chunk of memory for use as a fake disk partition.RAMdisk — это RAM + disk. И оба компонента должны присутствовать.
RAMdisk — это RAM + disk. И оба компонента должны присутствовать.
В той же википедии, где вы ссылаетесь, вот вам другая ссылка — список софта, с помощью которых можно создать виртуальный диск в памяти:
en.wikipedia.org/wiki/List_of_RAM_drive_software
И dev/ram и ramfs и tmpfs там перечислены.
На текущий момент не существует официальной спецификации каким может и каким не может быть
ramdisk. И нет комитета, который бы утвердил этот термин со всех сторон.
Есть просто обобщенный термин, который в первую очередь описывает возможность пользоваться памятью вместо внешнего storage устройства, поэтому зря вы докапываетесь то дого, что самостоятельно домыслили.
p.s. Да, спасибо за минус в карму, но от меня минуса не дождетесь.
Опоздал =]
эм… на файловом сервере просто так подключены диски?
сдается мне они таки в 10 или 5ый рейд собраны например…
итого никакого терабайта… ну 0,5 или 0,66 может…
Сдается мне, он таки отформатирован в ext3/ext4 например.
Итого — именно 5% от 10*2 терабайта, поделить на расходы 10-го или 5-го рейда, может наскрестись под терабайт.
в итоге при 10ом рейде из 10 2тб винтов система у нас будет видеть одно устройство на 10тб. и когда мы его отформатируем… то от этого 5% будет 0.5тб, а никак не 1, если бы просто монтировали 10 2тб винтов, с которых да 10*0.1тб…
Это действительно имеет значение? 5% останутся 5% при любом размере диска.
а страйп на файловом сервере я думаю никто использовать не будет.
я об этом
пс: а контроллер… некоторые программные под никсами у меня выглядели не как одно устройство, а именно как контроллер и винты отдельно были… и только при установке дров…
2. Даже лишние 500 гб — тоже весьма немаленький объем.
3. Страйп на файловом сервере — как раз вполне даже адекватный вариант. Это же не массив для корпоративного приложения или базы данных. Файловый сервер — чаще всего файлопомойка. И даже если это общий диск с файлами пользователей, бывает вполне достаточно регулярного бэкапа, вместо 5-го рейда.
4. Какая разница сколько там устройств. 5% резервируются на конечной файловой системе, неважно где она была создана — на единичном диске или массиве или рамдиске (кстати рамдиске).
Этой статьей можно его достойно открыть. Только сменить желтушное название на более подходящее по смыслу «Как я сам сделал открытие написанное в первой главе любого руководства по администрированию Linux не читая их и сразу написал про это статью на самый большой ИТ ресурс России».
Я бы назвал раздел «Последний шанс самоутвердиться для тех, кто уже все знает» )
Благодарю за совет! А что за пистон, чем хорош?
![image](https://habrastorage.org/getpro/habr/comment_images/e8f/501/988/e8f501988d0c34b3722c98efca0fb2a4.jpg)
Ещё есть это https://github.com/PistonDevelopers
Увы и ах!
Оказывается если к коротенькому комментарию с ServerFault
добавить заголовок с сайта газеты Жизнь,
то получается целая статья для хабра образца 2017 гэ
Автору стоило бы наверное проверить и другие варианты использования и последствий своих манипуляций.
Российский
Ох. Похоже вы просто не поняли, при чем тут Михалков. Вот: http://www.bbc.com/russian/russia/2010/10/101026_mikhalkov_dvd_tax.shtml
Из вашего-же поста следует, что аппетит у root-a есть и его можно уменьшить, что вообще-то не секрет не разу, но не суть…
… иное дело аппетиты Михалкова, которого эпизодически пытаются согнать с кормушки, но даже если этот день случиться, проблемы это никак не решает. Какие маны тут курить, в какой консоль чего вводить? Михалков — хуже root-a!
но зато «налог на болванки»
распространили на «умные часы»
по предложению Минкульта:
daily.afisha.ru/news/11527-v-rossii-nachnut-vzimat-avtorskiy-sbor-s-umnyh-chasov
Следующий — «налог на IT» для Малофея.
По опыту скажу, что ни раз сталкивался с ситуацией, когда этот небольшой резерв очень помогал, например загзипить какие-то данные. И вообще место для маневра нужно не только на системном диске. Очень редко требуется полная утилизация диска, чтобы положить в 0 и забыть. Для рабочих систем обычно если 80% заполнения => чистка или расширение.
Выглядит как бедный бизнес, который не может позволить себе несколько % в резерв, но при этом потеряв гораздо больше на последствиях.
Хотя пользы от него и правда не очень много, теоретически произойти может всякое и дополнительное свободное место для суперпользователя может спасти сервер, дав возможность админу свободу действий даже при полностью забитом диске, при возникновении какой то непредвиденной ошибки с заполнения всего диска.
Учите матчасть чтобы не писать такие безграмотные статьи!
Поставьте систему на btrfs/xfs/… список можно долго продолжать. И у вас не будет 5% резерва на рута.
Но резерв на рута оставлен не просто так а со смыслом. Он нужен для записи логов когда ваш ком уже умирает от полного заполнения корневого раздела. Т.е. вы хотя бы сможете потом узнать что и как и почему умерло.
Ну а то что многие форматируют свои терабайтные винты в EXT4 и потом возмущаются резервом рута — ССЗБ. EXT2 (и унаследовавшие ее систему хранения данных на диске ext3 и ext4) никогда не разрабатывалась для работы на больших дисках. Для этого, к примеру, разрабатывалась изначально XFS и более свежая BTRFS.
Благодарю, дополнил статью
Т.к резервирование происходит на этапе создания файловой ситсемы, а возможности root по записи в эту область просто одна из «необходимостей — вседозволенностей» данного уровня доступа. По мне логичный название данной статьи было бы «Ext4 хуже...». А переход к описанию возможностей root в данном вопросе это уже притянуто из-за «не очень полного» понимания автором сути вопроса.
Так что на шпиндельных дисках стоит оставлять этот резерв 5-8 процентов, а на SSD можно вполне безопасно уменьшить до 1-2 процентов (небольшой резерв все же стоит делать, иначе при сильном заполнении диска будет больше нагрузка на проц и сильнее фрагментация файлов).
EXT4 (точнее сказать: EXT2 c наворотами и бантиками) сама по себе очень хорошо фрагментирует большие файлы просто потому что они не влезают в одну группу хранения. И никакие 5% ей не помогут.
Вы ж не забывайте, что 5% на современном 6ТБ диске и 5% на 60ГБ дисках времен, когда разрабатывались ext и другие фс — это две большие разницы.
Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.
Для примера XFS на системные нужды, сразу после форматирования забирает ~0.06%.
Статическая алокация i-node в ext2-3-4 — тоже тот еще «подарок», все нормальные ФС уж давно динамически их аллокируют.
Статическая аллокация inide в EXT — это атавизм тянущийся с самого первого релиза ФС EXT2. Все последующие (3 и 4) тянут за собой не только этот атавизм, но много других.
Нет, я не считаю EXT4 плохой ФС. Она вполне подходит для небольших разделов отведенных под корень системы (резерв рута в этом случае большой плюс, а не минус, как его преподносит автор статьи).
Но для больших и не корневых разделов EXT4 годится уже гораздо хуже, ИМХО.
Для больших разделов я бы посоветовал использовать XFS или BTRFS.
А для EXT — такой цели не стояло в принципе. Именно поэтому там группа распределения в 65535 блоков и в каждую группу прибито гвоздями заголовок, индексы распределения (или битовые поля в ext2-3) и пачка преалокированных i-node (которые кстати сказать могут использоваться для указания на данные не обязательно в текущей группе). И таких групп на небольшом разделе создаются стони, а на Террабайтных дисках там уже тысячи и десятки тысяч групп.
У XFS тоже есть группы только их на всю ФС создается 3-4 штуки (не зависимо от размера раздела) и служат они совсем для других целей нежели группы в EXT-ах. В XFS они имеют свои наборы метаданных, что позволяет вести асинхронную запись. Сколько групп в XFS на столько потоков можно распределить параллельные потоки записи.
По ZFS — ничего не скажу — не пробовал, я больше BTRFS интересуюсь в последнее время. Вот она на 100% заполнении вполне адекватно себя ведет за счет небольшого резерва под метаданные который именно на ситуацию с 100% заполнением ФС и рассчитан.
Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.На самом деле на многоТБ дисках и массивах резервировать нужно больше, а не меньше.
Разница с SSD в том, что в случае SSD вы платите за какой-то объем, который написан на коробке, его и получаете. Пусть там внутри хоть в 10 раз больше чипов. В случае же резервирования диска для рута, вы платите за диск определенного объема, но во многих случаях не можете им воспользоваться полностью.
Эх, все уже сказано, сложно будет что-то добавить :(
Попытаюсь.
Если уж ухитрились выстрелить себе в ногу этим странным способом — удалить пару файлов, чтобы освободить место, можно попытаться с помощью утилиты debugfs. (Сорри, не проверял, сработает ли при 105% занятого места). Можно преобразовать ext3(4) в ext2 (tune2fs) .
а еще, рут, совсем не обязательно, в современной linux системе, может все все.
В результате сейчас может быть как обычный пользователь, умеющий «кое-что из того, что обычно делал root», так и root'а можно ограничить (многими способами) так, что от его «суперсилы» останутся «рожки да ножки».
SElinux, capabilties, контейнеры и прочее.
Я Вам (КО) больше скажу — в линухе можно удалить файл (и он таки будет удален) — но читать с него (файла) данные можно до тех пор, пока этот файл открыт.
Еще можно получать логи ошибок уже после того, как / забит под завязку. Спустя много месяцев, ога. RAM потому что.
Спасибо за статью, теперь в моём DAS'е стало немножко больше места.
Правильно ли я понял, что эти 5% не нужны системе для дефрагментации, если на диске ещё достаточно места? Если в системе несколько разделов на разных физических дисках и в одном из разделов отключён этот 5%-ый резерв, будет ли система использовать 5% другого раздела для своих нужд?
Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт.
Справедливости ради, все это неверно.
ext2-3-4? а нас, БСДМщиков забыли? =) а нас-то оно как?
А Вы не думали например, что сервисы при полностью забитом пространстве будут крашиться? Что Вы не сможете зайти по SSH на сервак, который в другой стране… Ну не надо думать что Вы умнее других.
Вы еще вместо автоматов в электрическом щитке — проволоки намотейте. Экономия, однако, автоматы не надо покупать.
Как это исправить
Жаль что с Михалковым так не поступить
Доброго утра, товарищи!
У меня в FreeBSD был 16-гигабайтный файл /var/db/swap/swap-16GB.
Он использовался в качестве дополнительного свопа:
mdconfig -a -t vnode -f /var/db/swap/swap-16GB -u 0
swapon /dev/md0
Понадобилось мне этот файл убрать.
Предварительно я его перестал использовать в качестве свопа:
swapoff /dev/md0
mdconfig -d -f /var/db/swap/swap-16GB
Ну и затем миднайт командером спокойно этот файл удалил.
Но не смотря на эти действия команда df не показала мне больше свободного места на диске.
Шукал по интернетам причину.
Многие пишут про то, что файл держится каким-то процессом.
А каким? (и почему, если я корректно остановил использование этого файла).
Ну почему - это пол беды (не самый важный вопрос).
А вот каким процессом держится файл - это может пригодиться.
Народ советует в выводе lsof погрепать (deleted).
Может быть в линуксах такое и работает. У меня FreeBSD и никаких (deleted) lsof не показывает.
Перезагрузка наверно поможет отключить удалённый файл отпроцесса.
Но это как-то не прилично ж.
Как свободное место из под этого удалённого файла вернуть в систему без перезагрузки?
Root хуже Михалкова