Comments 140
Имеет ли обратное дествие команда
sudo tune2fs -m 3 /dev/dm-0или любое количество процентов вместо 3.
В дополнение, tune2fs работает только на ext2/ext3/ext4, для остальных файловых систем — не актуально.
Но для этого надо войти в систему, что при забитом диске может и не получиться.
Ну, Миш! Написано же честно
Это может быть полезно для системного диска, который большую часть времени не забит под завязку и там действительно что-то может понадобиться руту.
Я не вижу причин в 21 веке делить диск на системный и пользовательский раздел.
Вы серьезно? )
Случай раз: сервер бд. База на отдельном большом диске, система на маленьком. В случае чего можно прицепить к диску новую систему или к системе другой диск (в зависимости от типа чп)
Случай два: файловые сервера с автоскейлингом, которым нужен большой кеш. Во время запуска нового сервера быстро восстанавливается маленький образ системного диска и подключается пустой большой диск под кеш.
СУБД, конечно, особый случай. Я больше про десктоп, на серверах вообще с разервной областью играться я бы не стал.
А смысл этой игры на десктопе? Эти 5% могут пригодиться, если для приложений и демонов под не-root правами место кончилось (и они зависли/упали), а для root — еще нет. Можно ребутнуть (init и стартовые скрипты отработают), можно зайти под root локально и попытаться хотя бы что-то исправить…
Ну классика же. Отдельный home. Переустанавливая/меняя систему на другую — не теряем данные и даже сохраняем настройки ПО.
По поводу % под рута. В текстовом режиме установки той же Ubuntu — это настраивается на этапе установки — и по собственному опыту скажу — надо оставлять минимум 1 % — при 100% заполнении диска — система может не загрузиться — придется использовать всякие livecd и прочее.
По поводу % под рута. В текстовом режиме установки той же Ubuntu — это настраивается на этапе установки — и по собственному опыту скажу — надо оставлять минимум 1 % — при 100% заполнении диска — система может не загрузиться — придется использовать всякие livecd и прочее.
Всегда делю. Я не труъ админ и могу систему слегка поломать. Ну и сама она иногда… портится :) Да и обновление системы на следующий релиз автоматом как-то не очень идёт поверх старой. А тут просто форматнул системный и точно не грохнешь свою инфу. Накатил новую — и все настройки уже готовы. Да, есть минус, что системный не используется на полную, зато я всегда уверен и без этих колдунств, что там есть место.
Причина наипрозрачнейшая: можно переустановить систему с нуля и при этом сохранить все свои данные и настройки. Например, в моём /home некоторые файлы тянутся аж с 2003 года, при том, что за это время у меня сменилось несколько дистрибутивов линукса и три системных блока.
И да, я про десктоп.
И да, я про десктоп.
А потом у вас однажды кончится свободное место и удалить с файловой системы вы уже ничего не сможете, потому что no space left on device.
Вы говорите так навскидку, или увас есть какое-то знание о внутреннем устройстве файловых систем ext?
Навскидку. По-умолчанию у вас зарезервировано 5% от размера файловой системы. Вы полностью использовали все 95% файловой системы и теперь при любой операции, в том числе удалении файлов/директорий вы получите сообщение о том, что не осталось свободного места на устройстве. Теперь, для того, чтобы удалить ненужные файлы, можно уменьшить размер зарезервированного места, удалить файлы и, опционально, вернуть назад резерв. А теперь представьте, что у вас нет зарезервированного места в файловой системе и расположена она на блочном устройстве, где нет возможности увеличить размер файловой системы.
Вроде как удаление файла может вызвать ошибку «не достаточно места» только на btrfs и zfs при использовании снапшетов, а на ext* всегда возможно. Или я отстал от жизни и ext3 уже как-то по новому себя ведет?
Как мимокрокодил могу предположить, что потенциально вирус-майнер-патч Бармина мог забить не только все место на диске, но и всю ОЗУ. Попытка удалить файл требует загрузить исполняемый файл rm или любой другой обладающий данной функцией, но ОЗУ вся занята. Скинуть своп на диск мы не можем, так как тот тоже переполнен.
Своп всегда можно скинуть на диск, потому что он или отдельный раздел, или файл фиксированного размера. Если же для него не отключили copy-on-write в какой-нибудь btrfs, то админ — сам себе злобный буратино.
Что ещё за «заполнить всё ОЗУ»? o_0
Во-первых, никакого всего ОЗУ не существует, каждый процесс видит только свою виртуальную память.
Во-вторых, придёт злой OOM-killer и убьет засранца =)
Во-первых, никакого всего ОЗУ не существует, каждый процесс видит только свою виртуальную память.
Во-вторых, придёт злой OOM-killer и убьет засранца =)
а журнал же записать? не?
EXT4 (она же ext2 с наворотами) дарит просто кучу проблем при 100% заполнении.
И это я говорю не потому что хорошо разбираюсь во внутреннем устройстве EXT2-3-4, XFS, BTRFS, NTFS,… а потому что уже сталкивался с такой ситуацией на практике.
И это я говорю не потому что хорошо разбираюсь во внутреннем устройстве EXT2-3-4, XFS, BTRFS, NTFS,… а потому что уже сталкивался с такой ситуацией на практике.
Поздравляю вас. Только что вы получили смешную ситуацию — если полностью забить диск, то вы не сможете даже подключиться удаленно к серверу. Не говоря уж о том, что это место используется и самой ОС для работы с файловой системой периодически в целях избежания фрагментации (ситуация стала не так остра в ext4).
если полностью забить диск
Если полностью забить системный диск. Пожалуйста, пишите точнее.
Невозможность входа — да, только для системных разделов. Либо для /home, если используется графическая оболочка какая-либо.
Но фрагментация будет грозить любому диску. Хотя бы процент оставить необходимо. Иначе скорость ФС может упасть сильно.
Но фрагментация будет грозить любому диску. Хотя бы процент оставить необходимо. Иначе скорость ФС может упасть сильно.
SSD/ramdisk фрагментация не грозит
SSD грозит другая проблема. Если не останется свободных erase-блоков (размер которых может достигать нескольких мегабайт), придётся полностью перезаписывать блок для записи даже одного байта. Хотя обычно SSD держит определённый объём зарезервированным аппаратно, но при активной записи его может и не хватить.
Например, мой (довольно пожилой) смартфон начинает невыносимо тормозить, если осталось менее 1 ГБ свободного места, помогает только вайп. Видимо, контроллер недостаточно умён, чтобы производить дефрагментацию на физическом уровне и из-за фрагментации ФС оказываются занятыми все erase-блоки.
ramdisk в Linux — это что-то новенькое (для тех кто в танке: tmpfs — это не ramdisk), а вот забив диск под завязку вы можете устроить такую фрагментацию, что и SSD не спасёт (скорости рандомного доступа и на SSD не так велики, как вам кажется — особенно для пользовательских SSD, не оптимизированных под базы данных).
А чем, на ваш взгляд, отличается tmpfs от ramdisk? И то, и другое — способ выделить часть ОЗУ для хранения файлов. А что туда записывать и куда смонтировать — это уже отдельный вопрос, причём настраиваемый пользователем.
ramdisk — это выделенный под хранение файлов кусок памяти. Поверх которого «разводится» стандартная файловая система. У него фиксированный размер и когда его ёмкость «подходит к концу» на нём начинается фрагментация (хотя её последствия, конечно, не так страшны как для диска реального).
tmpfs — это просто «обьекты в памяти», которые делают вид, что они на диске, но которым «законодательно запрещено» занимать более 50% памяти. Так как для них, на самом деле, используется вся доступная память, то проблем с фрагментацией при заполнении tmpfs быть не может. А вот если занять всю память… мой рекорд — переключение с графической на текстовую консоль (где уже можно найти какую-нибудь программу и убить её) за 45 минут. Машинка не повисла, не умерла… она просто работала — то действие, которое обычно занимает секунды заняло почти час…
tmpfs — это просто «обьекты в памяти», которые делают вид, что они на диске, но которым «законодательно запрещено» занимать более 50% памяти. Так как для них, на самом деле, используется вся доступная память, то проблем с фрагментацией при заполнении tmpfs быть не может. А вот если занять всю память… мой рекорд — переключение с графической на текстовую консоль (где уже можно найти какую-нибудь программу и убить её) за 45 минут. Машинка не повисла, не умерла… она просто работала — то действие, которое обычно занимает секунды заняло почти час…
Для windows есть программы, которые создают точно такие же динамические диски (например, ImDisk и Primo Ramdisk). Так что разницы в этом плане нет никакой.
Так что разницы в этом плане нет никакой.Разница принципиальна. У вас либо есть secondary storage, либо его нет. Например если мы взяли и отобразили файл в память — скольку у нас будет копий данных? В случае с дисковой файловой системой, в том числе с файловой системой, размещённой на диске в памяти ответ — таких копий будет две: одна — где-то в недрах page cache, другая — на, собственно, блочном устройстве. Что выглядит несколько глупо (для тех целей, для которых обычно применяется tmpfs), но иногда может иметь смысл. Так как вы, немного поработав с этим устройством, сможете его размонтировать и залить «как есть» на флешку. Или переслать на другуй компьютер. Да мало ли что может захотеться сделать с диском!
А в tmpfs никакого диска нет. Ну вот совсем нет — и всё. Cо всеми вытекающими.
P.S. Классический ramdisk в Linux, разумеется, тоже есть. Просто он редко испоьзуется. Но бывает и такое. Скажем если вы хотите создать образ дискеты или ещё что-нибудь подобное. Но это редко случается. В большинстве случаев достаточно tmpfs.
Что за бред? Вы троллите?
Смысл рамдиска не в количестве копий, а в том, как с этим диском работает софт.
Если я перегружаю сервер, включаю рамдиск, данные которого грузятся с образа на диске — ежу понятно, что у меня есть образ на диске и потом появится файл в памяти.
Но если я сервер не перегружаю — все программы, которые хотят прочитать данные с «диска», будут смотреть на ramdrive, и следовательно скорость работы возрастает.
Я не могу просто так держать программу в памяти, если я ее много раз запускаю и закрываю, но если я создаю виртуальное устройство, на которое кладу файлы программы — то я могу это делать, и программа не будет ничего подозревать.
Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.
Смысл рамдиска не в количестве копий, а в том, как с этим диском работает софт.
Если я перегружаю сервер, включаю рамдиск, данные которого грузятся с образа на диске — ежу понятно, что у меня есть образ на диске и потом появится файл в памяти.
Но если я сервер не перегружаю — все программы, которые хотят прочитать данные с «диска», будут смотреть на 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.
Это не я выдумываю — это вот прямо на страничке с описанием того, что такое файловая система написано: 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/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. Не слишком новенькое?
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.
«Нет. Если даже забить /dev/shm «под завязку», так что там ни байта завести нельзя будет — тормоза не возникнут. Потому что это не — ramdisk»
Это бред =)
Файловая система начинает себя плохо вести по большой части из-за фрагментации. И эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным. А это как раз флешки, ssd и конечно рамдиски.
Определение рамдиска это не «потому что он не тормозит при заполнении», а потому что он расположен в памяти (в ram).
Кроме того, под линукс хватает сторонних программ для организации виртуального рам-диска, который вы можете отформатировать в любую любимую ext2, zfs и т.д.
Просто в Linux есть поддержка рамдиска из коробки, в виде ramfs и tmpfs, которые внутри — одно и тоже, с разницей которую я пояснил выше.
Это бред =)
Файловая система начинает себя плохо вести по большой части из-за фрагментации. И эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным. А это как раз флешки, 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. И все.
Все остальное — это уже классификация, насколько полно поддерживается весь интерфейс обычных дисковых устройств и отдельный тюнинг.
Прошу прощения, нор прямо по вашей ссылке черным по белому написано
«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 — чтоб уж совсем никакой путаницы не было.
Это просто уже различные реализации ram disk.
Ссылки в википедии не являются строгими признаками классификации, это просто для тех, кто не знает что такое disk drive — для них ссылка. Но мы то знаем, что это такое, и возможно даже больше, чем это описано на википедии.
Насчет «четко и отдельно», похоже нужно перевести и эту фразу, потому что IMHO вы просто не понимаете ее значения:
«Эта статья — про виртуальные диски, которые эмулируются при помощи ПО. Для хардварных устройств, которые используют RAM, смотрите SSD, для файловой системы без эмуляции диска — смотрите tmpfs».
Другими словами, под ramdisk называется диск, который эмулируется софтом в оперативной памяти компьютера.
Если взять планки RAM и поместить их на отдельное устройство, мы получим SSD.
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 нельзя замаунтить?
$ 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, этого уже достаточно.
Не нравится — используйте стороннее решение, возможно платное. Но считать при этом эту технологию не рамдиском — бред.
Это — дополнительный функционал.
То, что имеет значение — это то, что рамдиск хранится в оперативной памяти, а не в отдельном устройстве. Это единственный и основной признак классификации рамдиска. Все остальные вещи — типа эмуляция интерфейса блочного устройства, возможность использования нужной вам файловой системы — это второстепенное. 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. Да, спасибо за минус в карму, но от меня минуса не дождетесь.
(del)
Опоздал =]
Опоздал =]
«Но если у вас файловый сервер, к которому подключены 10 винтов по 2 терабайта, вы же просто в никуда отдаете целый терабайт места.»
эм… на файловом сервере просто так подключены диски?
сдается мне они таки в 10 или 5ый рейд собраны например…
итого никакого терабайта… ну 0,5 или 0,66 может…
эм… на файловом сервере просто так подключены диски?
сдается мне они таки в 10 или 5ый рейд собраны например…
итого никакого терабайта… ну 0,5 или 0,66 может…
А рейд просто так подключен на файловом сервере?
Сдается мне, он таки отформатирован в ext3/ext4 например.
Итого — именно 5% от 10*2 терабайта, поделить на расходы 10-го или 5-го рейда, может наскрестись под терабайт.
Сдается мне, он таки отформатирован в ext3/ext4 например.
Итого — именно 5% от 10*2 терабайта, поделить на расходы 10-го или 5-го рейда, может наскрестись под терабайт.
ну… лучше использовать аппаратный рейд-контроллер.
в итоге при 10ом рейде из 10 2тб винтов система у нас будет видеть одно устройство на 10тб. и когда мы его отформатируем… то от этого 5% будет 0.5тб, а никак не 1, если бы просто монтировали 10 2тб винтов, с которых да 10*0.1тб…
в итоге при 10ом рейде из 10 2тб винтов система у нас будет видеть одно устройство на 10тб. и когда мы его отформатируем… то от этого 5% будет 0.5тб, а никак не 1, если бы просто монтировали 10 2тб винтов, с которых да 10*0.1тб…
Это действительно имеет значение? 5% останутся 5% при любом размере диска.
Какая разница какой контроллер для рейда использовать? размер диска от организации рейда не зависит, только от его уровня. И в любом случае мы в конечном счете создаем файловую систему с теми же 5%, вне зависимости там один диск или рейд на сто дисков.
вот именно! 5% от массива, но не 5% от объема входящих в него дисков.
а страйп на файловом сервере я думаю никто использовать не будет.
я об этом
пс: а контроллер… некоторые программные под никсами у меня выглядели не как одно устройство, а именно как контроллер и винты отдельно были… и только при установке дров…
а страйп на файловом сервере я думаю никто использовать не будет.
я об этом
пс: а контроллер… некоторые программные под никсами у меня выглядели не как одно устройство, а именно как контроллер и винты отдельно были… и только при установке дров…
1. Про то, что диски собраны в рейд — вы придумали сами, и тут же на фоне этой выдумки начали сочинять про разницу между 1 тб и 500 гб.
2. Даже лишние 500 гб — тоже весьма немаленький объем.
3. Страйп на файловом сервере — как раз вполне даже адекватный вариант. Это же не массив для корпоративного приложения или базы данных. Файловый сервер — чаще всего файлопомойка. И даже если это общий диск с файлами пользователей, бывает вполне достаточно регулярного бэкапа, вместо 5-го рейда.
4. Какая разница сколько там устройств. 5% резервируются на конечной файловой системе, неважно где она была создана — на единичном диске или массиве или рамдиске (кстати рамдиске).
2. Даже лишние 500 гб — тоже весьма немаленький объем.
3. Страйп на файловом сервере — как раз вполне даже адекватный вариант. Это же не массив для корпоративного приложения или базы данных. Файловый сервер — чаще всего файлопомойка. И даже если это общий диск с файлами пользователей, бывает вполне достаточно регулярного бэкапа, вместо 5-го рейда.
4. Какая разница сколько там устройств. 5% резервируются на конечной файловой системе, неважно где она была создана — на единичном диске или массиве или рамдиске (кстати рамдиске).
У вас арифметика какая? По модулю 10? Как у вас 10 винтов по 2 ТБ дали RAID объемом 10 ТБ ??? 10*2=10 ??? Вот тут у вас расчеты и поехали. А так 5% все тот же 1 терабайт. Комментаторы, вы хоть пересчитывайте числа в чужих комментах.
А просто не надо бездумно ничего делать. Если форматируете в EXT4 то уберите резерв рута (если он не нужен конечно). А если форматирует в XFS, например, то уже никаких резервов не будет.
Пора открывать раздел «Хабр для самых маленьких».
Этой статьей можно его достойно открыть. Только сменить желтушное название на более подходящее по смыслу «Как я сам сделал открытие написанное в первой главе любого руководства по администрированию Linux не читая их и сразу написал про это статью на самый большой ИТ ресурс России».
Этой статьей можно его достойно открыть. Только сменить желтушное название на более подходящее по смыслу «Как я сам сделал открытие написанное в первой главе любого руководства по администрированию Linux не читая их и сразу написал про это статью на самый большой ИТ ресурс России».
Пока не могу плюсовать, но люто голосую за коммент выше!
Я бы назвал раздел «Последний шанс самоутвердиться для тех, кто уже все знает» )
Благодарю за совет! А что за пистон, чем хорош?
Гибкостью :)
Ещё есть это https://github.com/PistonDevelopers
Увы и ах!
Оказывается если к коротенькому комментарию с ServerFault
добавить заголовок с сайта газеты Жизнь,
то получается целая статья для хабра образца 2017 гэ
Все таки 5% оправданы на системном разделе, как определенного рода защитный буфер от возможности выпалить в «no space left on device».
Автору стоило бы наверное проверить и другие варианты использования и последствий своих манипуляций.
Автору стоило бы наверное проверить и другие варианты использования и последствий своих манипуляций.
Автор, открыл для себя резервирование блоков на ext(2|3|4) файловой системе. Похвально.
О боже ты мой! Всегда хотел увидеть, как выглядит тот самый man. Так вот оно как… :)
Российский
Ох. Похоже вы просто не поняли, при чем тут Михалков. Вот: http://www.bbc.com/russian/russia/2010/10/101026_mikhalkov_dvd_tax.shtml
Ну и чем же root хуже Никиты Сергеевича?
Из вашего-же поста следует, что аппетит у root-a есть и его можно уменьшить, что вообще-то не секрет не разу, но не суть…
… иное дело аппетиты Михалкова, которого эпизодически пытаются согнать с кормушки, но даже если этот день случиться, проблемы это никак не решает. Какие маны тут курить, в какой консоль чего вводить? Михалков — хуже root-a!
Из вашего-же поста следует, что аппетит у root-a есть и его можно уменьшить, что вообще-то не секрет не разу, но не суть…
… иное дело аппетиты Михалкова, которого эпизодически пытаются согнать с кормушки, но даже если этот день случиться, проблемы это никак не решает. Какие маны тут курить, в какой консоль чего вводить? Михалков — хуже root-a!
Мигалков вроде сдриснул из «фонда кино»,
но зато «налог на болванки»
распространили на «умные часы»
по предложению Минкульта:
daily.afisha.ru/news/11527-v-rossii-nachnut-vzimat-avtorskiy-sbor-s-umnyh-chasov
Следующий — «налог на IT» для Малофея.
но зато «налог на болванки»
распространили на «умные часы»
по предложению Минкульта:
daily.afisha.ru/news/11527-v-rossii-nachnut-vzimat-avtorskiy-sbor-s-umnyh-chasov
Следующий — «налог на IT» для Малофея.
Такими темпами хабр скоро в лайфру превратится: «Скандалы интриги расследования ext2/3/4 безнаказанно пожирает дисковое пространство! Хватит это терпеть!!! „
Какой позор, автор считает, что создатели Linux дураки?
По опыту скажу, что ни раз сталкивался с ситуацией, когда этот небольшой резерв очень помогал, например загзипить какие-то данные. И вообще место для маневра нужно не только на системном диске. Очень редко требуется полная утилизация диска, чтобы положить в 0 и забыть. Для рабочих систем обычно если 80% заполнения => чистка или расширение.
Выглядит как бедный бизнес, который не может позволить себе несколько % в резерв, но при этом потеряв гораздо больше на последствиях.
По опыту скажу, что ни раз сталкивался с ситуацией, когда этот небольшой резерв очень помогал, например загзипить какие-то данные. И вообще место для маневра нужно не только на системном диске. Очень редко требуется полная утилизация диска, чтобы положить в 0 и забыть. Для рабочих систем обычно если 80% заполнения => чистка или расширение.
Выглядит как бедный бизнес, который не может позволить себе несколько % в резерв, но при этом потеряв гораздо больше на последствиях.
Думал почему то что об этом известно достаточно давно, ведь при установке (во всяком случае в консольном режиме), на стадии разбивки диска указывается опция выбора процентного выделения резервного размера для рута.
Хотя пользы от него и правда не очень много, теоретически произойти может всякое и дополнительное свободное место для суперпользователя может спасти сервер, дав возможность админу свободу действий даже при полностью забитом диске, при возникновении какой то непредвиденной ошибки с заполнения всего диска.
Хотя пользы от него и правда не очень много, теоретически произойти может всякое и дополнительное свободное место для суперпользователя может спасти сервер, дав возможность админу свободу действий даже при полностью забитом диске, при возникновении какой то непредвиденной ошибки с заполнения всего диска.
Место резервирует не Linux а файловая система ext4!!!!
Учите матчасть чтобы не писать такие безграмотные статьи!
Поставьте систему на btrfs/xfs/… список можно долго продолжать. И у вас не будет 5% резерва на рута.
Но резерв на рута оставлен не просто так а со смыслом. Он нужен для записи логов когда ваш ком уже умирает от полного заполнения корневого раздела. Т.е. вы хотя бы сможете потом узнать что и как и почему умерло.
Ну а то что многие форматируют свои терабайтные винты в EXT4 и потом возмущаются резервом рута — ССЗБ. EXT2 (и унаследовавшие ее систему хранения данных на диске ext3 и ext4) никогда не разрабатывалась для работы на больших дисках. Для этого, к примеру, разрабатывалась изначально XFS и более свежая BTRFS.
Учите матчасть чтобы не писать такие безграмотные статьи!
Поставьте систему на btrfs/xfs/… список можно долго продолжать. И у вас не будет 5% резерва на рута.
Но резерв на рута оставлен не просто так а со смыслом. Он нужен для записи логов когда ваш ком уже умирает от полного заполнения корневого раздела. Т.е. вы хотя бы сможете потом узнать что и как и почему умерло.
Ну а то что многие форматируют свои терабайтные винты в EXT4 и потом возмущаются резервом рута — ССЗБ. EXT2 (и унаследовавшие ее систему хранения данных на диске ext3 и ext4) никогда не разрабатывалась для работы на больших дисках. Для этого, к примеру, разрабатывалась изначально XFS и более свежая BTRFS.
Благодарю, дополнил статью
А утверждение «резервирует для root» как я понимаю не очень соответствует действительности.
Т.к резервирование происходит на этапе создания файловой ситсемы, а возможности root по записи в эту область просто одна из «необходимостей — вседозволенностей» данного уровня доступа. По мне логичный название данной статьи было бы «Ext4 хуже...». А переход к описанию возможностей root в данном вопросе это уже притянуто из-за «не очень полного» понимания автором сути вопроса.
Т.к резервирование происходит на этапе создания файловой ситсемы, а возможности root по записи в эту область просто одна из «необходимостей — вседозволенностей» данного уровня доступа. По мне логичный название данной статьи было бы «Ext4 хуже...». А переход к описанию возможностей root в данном вопросе это уже притянуто из-за «не очень полного» понимания автором сути вопроса.
Самое смешное в этой истории (истерии? :) для меня в том, что рут к этому резерву вообще никакого отношения не имеет (ну, исключая то, что руту все же получится записать больше, чем остальным). Это место резервируется из соображений производительности — пустые области получаются большего размера, в них проще (и быстрее) находить свободные блоки для новых данных, ну и меньше фрагментация файлов, что для шпиндельных дисков крайне существенно. Современные SSD тоже имеют подобную систему — они показывают операционке меньший объем, чем установлено чипов, чтобы иметь резерв свободных блоков для новых данных или поврежденных блоков (которые ремапятся).
Так что на шпиндельных дисках стоит оставлять этот резерв 5-8 процентов, а на SSD можно вполне безопасно уменьшить до 1-2 процентов (небольшой резерв все же стоит делать, иначе при сильном заполнении диска будет больше нагрузка на проц и сильнее фрагментация файлов).
Так что на шпиндельных дисках стоит оставлять этот резерв 5-8 процентов, а на SSD можно вполне безопасно уменьшить до 1-2 процентов (небольшой резерв все же стоит делать, иначе при сильном заполнении диска будет больше нагрузка на проц и сильнее фрагментация файлов).
Вы не правы. 5% про котрые статья — никакого отношения к производительности не имеет.
EXT4 (точнее сказать: EXT2 c наворотами и бантиками) сама по себе очень хорошо фрагментирует большие файлы просто потому что они не влезают в одну группу хранения. И никакие 5% ей не помогут.
EXT4 (точнее сказать: EXT2 c наворотами и бантиками) сама по себе очень хорошо фрагментирует большие файлы просто потому что они не влезают в одну группу хранения. И никакие 5% ей не помогут.
Все-таки имеют )
Вы ж не забывайте, что 5% на современном 6ТБ диске и 5% на 60ГБ дисках времен, когда разрабатывались ext и другие фс — это две большие разницы.
Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.
Вы ж не забывайте, что 5% на современном 6ТБ диске и 5% на 60ГБ дисках времен, когда разрабатывались ext и другие фс — это две большие разницы.
Хотя да, я согласен в том, что 5% на больших многоТБ дисках и массивах — это уже перебор, действительно, резерв в 5% уже не актуален.
Просто не надо большие диски форматировать ext-ами. Они только на свои системные нужды отъедают ~1,8% сразу после форматирования (оно именно потому такое тормозное в EXT по сравнению например с форматированием XFS или BTRFS). Плюс 5% резерва рута (которые либо после надо убрать либо при форматировании ключами задушить в зародыше).
Для примера XFS на системные нужды, сразу после форматирования забирает ~0.06%.
Статическая алокация i-node в ext2-3-4 — тоже тот еще «подарок», все нормальные ФС уж давно динамически их аллокируют.
Для примера XFS на системные нужды, сразу после форматирования забирает ~0.06%.
Статическая алокация i-node в ext2-3-4 — тоже тот еще «подарок», все нормальные ФС уж давно динамически их аллокируют.
BTRFS, XFS, ZFS, RaiserFS/Raiser4, NTFS — тоже, хотя там оно не i-node называется и еще некоторые другие ФС.
Статическая аллокация inide в EXT — это атавизм тянущийся с самого первого релиза ФС EXT2. Все последующие (3 и 4) тянут за собой не только этот атавизм, но много других.
Нет, я не считаю EXT4 плохой ФС. Она вполне подходит для небольших разделов отведенных под корень системы (резерв рута в этом случае большой плюс, а не минус, как его преподносит автор статьи).
Но для больших и не корневых разделов EXT4 годится уже гораздо хуже, ИМХО.
Для больших разделов я бы посоветовал использовать XFS или BTRFS.
Статическая аллокация inide в EXT — это атавизм тянущийся с самого первого релиза ФС EXT2. Все последующие (3 и 4) тянут за собой не только этот атавизм, но много других.
Нет, я не считаю EXT4 плохой ФС. Она вполне подходит для небольших разделов отведенных под корень системы (резерв рута в этом случае большой плюс, а не минус, как его преподносит автор статьи).
Но для больших и не корневых разделов EXT4 годится уже гораздо хуже, ИМХО.
Для больших разделов я бы посоветовал использовать XFS или BTRFS.
ext4 умеет в динамические iNode
Ну, положим, XFS и ext вполне себе одногодки. ZFS вот очень крута и моложе, и может ворочать огромными разделами, и это даже больше, чем ФС. Однако, посмотрите, как она себя поведет при заполнении >85%.
Одногодки то они одногодки (почти) только вот XFS создавалась для больших дисков изначально. Это было в целях.
А для EXT — такой цели не стояло в принципе. Именно поэтому там группа распределения в 65535 блоков и в каждую группу прибито гвоздями заголовок, индексы распределения (или битовые поля в ext2-3) и пачка преалокированных i-node (которые кстати сказать могут использоваться для указания на данные не обязательно в текущей группе). И таких групп на небольшом разделе создаются стони, а на Террабайтных дисках там уже тысячи и десятки тысяч групп.
У XFS тоже есть группы только их на всю ФС создается 3-4 штуки (не зависимо от размера раздела) и служат они совсем для других целей нежели группы в EXT-ах. В XFS они имеют свои наборы метаданных, что позволяет вести асинхронную запись. Сколько групп в XFS на столько потоков можно распределить параллельные потоки записи.
По ZFS — ничего не скажу — не пробовал, я больше BTRFS интересуюсь в последнее время. Вот она на 100% заполнении вполне адекватно себя ведет за счет небольшого резерва под метаданные который именно на ситуацию с 100% заполнением ФС и рассчитан.
А для 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», так и root'а можно ограничить (многими способами) так, что от его «суперсилы» останутся «рожки да ножки».
SElinux, capabilties, контейнеры и прочее.
В результате сейчас может быть как обычный пользователь, умеющий «кое-что из того, что обычно делал root», так и root'а можно ограничить (многими способами) так, что от его «суперсилы» останутся «рожки да ножки».
SElinux, capabilties, контейнеры и прочее.
Казалось бы, причем тут Лужков Михалков?
Неделя КО на канале…
Я Вам (КО) больше скажу — в линухе можно удалить файл (и он таки будет удален) — но читать с него (файла) данные можно до тех пор, пока этот файл открыт.
Еще можно получать логи ошибок уже после того, как / забит под завязку. Спустя много месяцев, ога. RAM потому что.
Я Вам (КО) больше скажу — в линухе можно удалить файл (и он таки будет удален) — но читать с него (файла) данные можно до тех пор, пока этот файл открыт.
Еще можно получать логи ошибок уже после того, как / забит под завязку. Спустя много месяцев, ога. RAM потому что.
Спасибо за статью, теперь в моём DAS'е стало немножко больше места.
Правильно ли я понял, что эти 5% не нужны системе для дефрагментации, если на диске ещё достаточно места? Если в системе несколько разделов на разных физических дисках и в одном из разделов отключён этот 5%-ый резерв, будет ли система использовать 5% другого раздела для своих нужд?
По-моему вы слишком многое приписываете этим 5%. Они вообще никак не влияют на работу файловой системы. Ни положительно, ни отрицательно. Просто когда файловая система (любая) заполнена на 80%-90% в ней начинаются проблемы с фрагментацией. В каких-то файловых системах проблемы начинаются раньше, в каких-то позже, но забив диск «под завязку» тормоза вы получите в любой (а на некоторых, в частности XFS старых ревизий — так и данные начнут теряться). Так как людям об этом думать лень, то в ext2/3/4 было 5% под это зарезервировано под это дело. А на root'а это ограничение не распространяется, так как лучше уж дать системе возможность «тормозить», чем «виснуть».
Рут – это мифическое существо в экосистеме Linux. Он может всё: зайти в любой каталог, удалить любой файл, завершить любой процесс, открыть любой порт.
Справедливости ради, все это неверно.
ext2-3-4? а нас, БСДМщиков забыли? =) а нас-то оно как?
Если существует резервирование 5% объема — значит кто-то посидел, подумал, нашел какие-то значимые причины и сделал. И тут появляется человек — «эффективное использование пространства» и отменяет.
А Вы не думали например, что сервисы при полностью забитом пространстве будут крашиться? Что Вы не сможете зайти по SSH на сервак, который в другой стране… Ну не надо думать что Вы умнее других.
Вы еще вместо автоматов в электрическом щитке — проволоки намотейте. Экономия, однако, автоматы не надо покупать.
А Вы не думали например, что сервисы при полностью забитом пространстве будут крашиться? Что Вы не сможете зайти по SSH на сервак, который в другой стране… Ну не надо думать что Вы умнее других.
Вы еще вместо автоматов в электрическом щитке — проволоки намотейте. Экономия, однако, автоматы не надо покупать.
Как это исправить
Жаль что с Михалковым так не поступить
Вы пропускаете важный момент — когда OOM Killer приходит кого-то убить он считает что root-процессы важнее и стремиться их не трогать!
Доброго утра, товарищи!
У меня в 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 не показывает.
Перезагрузка наверно поможет отключить удалённый файл отпроцесса.
Но это как-то не прилично ж.
Как свободное место из под этого удалённого файла вернуть в систему без перезагрузки?
Sign up to leave a comment.
Root хуже Михалкова