> Если почитать умную книжку разработчиков FreeBSD на момент выхода FreeBSD 5.2, то
> можно узнать, что от прежней UFS осталось только 10% кода.А если почитать и другие ресурсы, можно узнать что в UFS не стали переделывать базовое устройство ФС потому что это было некому делать. Поэтому господа некрофилы решили делать что получится из того что есть. В результате получился какой-то изврат: разработчики на то чтобы ставить костыли нашлись, а на то чтобы дисковые структуры менее архаично сделать - почему-то нет. Глупо, но факт.
>> от мерса - мерсом он от этого не стал. Странно, правда?
> Странно то, что линуксоиды до сих пор не могут взять в толк, что смена
> поколений UFS не делает их совместимыми сверху вниз. UFS2 отличается
>от UFS1 даже больше, чем Ext4 отличется от Ext2.
Да хрен там - основные дисковые структуры оставили более-менее те же самые. Как раз потому что переделывать весь дизайн капитально всем было влом.
>> Так я и говорю - окаменелость.
> UFS2 стала готовой к промышленному использованию только в FreeBSD 6.0. А это
> — ноябрь 2005 года (примерно через два года, когда стала рабочей
> и довольно надёжной Ext3 в Linux). Так кто там "окаменелость"? UFS2,
> которая появилась на два года позже Ext3?
Понимаешь, жигуленок в гараже - можно и в 2011 году собрать. От того что у него дата выпуска 2011 год - жигуленком он быть не перестанет. Он жигуленок по _технологичности_ а не по дате выпуска. Вот по уровню технологий примененных в дисковых структурах - это каменный век. Просто заметь что все остальные дружно не юзают блочные аллокаторы уже много лет. Примерно с начала 2000х годов тенденция отказа от них пошла. Ну как диски стали становиться реально большими, так они и стали неэффективны по сравнению с экстентами.
> Новая архитектура UFS2 позволяет значительно оттюнить производительность I/O не
> прибегая к отдельным патчам и костылям
Логика додика, быдлотюнящего жигуленок без базового понимания процессов в ДВС. Сколько его ни тюнь, а ничего приличного на выходе не получится. Потому что на уровне базовых деталей - не фонтан.
> (в случае использования менеджера томов). Например, в UFS2 улушен механизм
> хэширования каталогов,
Вай-вай. Надо же. А ничего что в 2011 году не хеширует каталоги ну разве что FAT какой-нибудь? (И то - в принципе можно в памяти хеш на лету строить, хоть это и криво).
> убраны ненужные глобальные блокировки, повышена надёжность хранения данных
> за счёт нового механизма транзакций на уровне драйвера SATA-II/SAS.
Даже если жигуленку прикрутить магнитолу и сигналку - он от этого жигуленком быть почему-то не перестанет.
>> до создателей EXTов дотумкало уже что экстенты - штука хорошая. А
>> до бздельников как до жирафов, что в ufs что в zfs.
> В UFS2 размещение данных в последовательностях осуществляется по возможности в пределах
> одной группы цилиндров
Фич экстентов не в том что там последовательно распихиваются данные. Это может (и должна) делать почти любая ФС. Соль экстентов в том что на адресацию большого непрерывного блока записывается мелкий объем метаданных, описывающий экстент. А традиционные блочные аллокаторы метят как занятый _каждый_ блок. Поскольку блоков может быть много - пометка занятости может занять дохрена времени. В UFS это не было сделано, поэтому и каменный век. Результаты многих бенчей - недвусмысленно намекают о том кто есть кто.
> (даже для метаинформации этих данных, чего нет в Ext*) и используется
> пространство фрагментов блоков данных — в экстентах надобности
> нет, фрагментация минимальна.
Экстенты рулят не потому что они как-то лучше борятся с фрагментацией. А потому что позволяют адресовать большие непрерывные блоки компактнее и быстрее, не метя каждый адресуемый блок как занятый. Борьба с фрагментацией идет в ином месте. А этот уровень всего лишь описывает размещение данных. Заметь, одно и то же размещение без проблем записывается как экстентом так и лобовой пометкой блоков как занятые. Просто второй вариант займет больше времени в случае больших непрерывных блоков (к которым и должна стремиться ФС, по соображениям борьбы с фрагментацией и минимального оверхеда).
> В ZFS переменный размер блоков от 128 килобайт, в экстентах нужды нет.
А ZFS это вообще пепелац.
1) С фрагментацией эти лютые перцы вообще кажется не считают нужным бороться. Это при том что CoW к фрагментации более склонен, как раз из-за "copy в сторонку" (по определению будет фрагмент). Как я понимаю - сани просто технично забили на проблему болт и при сборке мусора от снапшотов вообще не парятся особо какой-то там дефрагментацией и пересбором того что осталось в непрерывные блоки. Как я понимаю, просто оставляется та вермишель которая вышла. Это конечно упрощает слегка логику удаления снапшотов, но файловая система то неизбежно придет в состояние вермишели постепенно. CoW этому поможет. И да, в btrfs до тех кто ее делал очень вовремя дошло, что подгребая мусор можно и дефрагнуть все эти макароны до кучи, раз уж полезли это переколупывать.
2) А блоки переменной длины - за экстенты не очень то и считаются. Как раз по причине соотношения объема метаданных и данных при записи длинных непрерывных блоков данных. Это всего лишь блочный аллокатор, слегка на стероидах, но общие мерзостные свойства оного от этого никуда не деваются. Учтя когда ZFS проектировался - простительно, но с тех пор инженерная мысля слегка ушла вперед, а экстенты зарулили блочные аллокаторы.
>> В чем-то это будет даже верно.
> Это не в чём-то верно, это верно де-факто и де-юре.
Это не полностью верно по причине того что сделали экстенты, основательно перекроив устройство ФС на довольно базовом уровне, с потерей обратной совместимости. Зато вся эта хирургия привела старпера в чувство и он стал довольно резво бегать теперь. Ради чего все это и затевалось. В кои-то веки EXT больше не считается тормозом.
>> а ZFSу в силу энтерпрайзности его тормоза кой-как затыкают набивая десятки гиг оперативы.
> В ZFS оперативка используется для кэширования. Если оперативная память на боевом сервере
> не занята, а процессор нагружен постоянно на 20% и меньше, то
> это плохое вложение средств в вычислительный комплекс и инфраструктуру.
Понимаешь ли, изен, только клоуны покупают сервера для обслуживания нужд файловой системы, потому что это слегонца маразм :))). Файловая система - техническая сущность. Нужная для работы сервера как неизбежное зло. Примерно как трубы нужны для того чтобы унитаз работал. Идеальная файловая система в вакууме - не занимает место на диске под себя, не грузит проц на свою обработку и всегда работает со скоростью RAW доступа к диску. Реальная ФС - попытка как-то приблизиться к идеалу, с теми или иными компромиссами.
> И это далеко не то же самое, что "давайте постоянно считать Super PI"
> и "искать корни систем уравнений с n-неизвестными, чтобы загрузить процессор и
> ОЗУ на 120%". Здесь дело в определении узких мест и своевременном
> реагировании на их появление
Чаще всего узким местом является I/O. И ZFS'у тут совершенно нечего показать. Он быстр только если все уместилось в кеш (хаха, как и любая другая ФС). С таким подходом можно вообще все в рамдиске хранить. Проблема лишь в том что HDD используют в основном потому что данные имеют противное свойство: они в оперативу целиком ну никак не умещаются, сколько ее ни воткни. Объемы оперативы почему-то сильно меньше объема HDD.
> — ZFS справляется с этим превосходно: освобождает кэш в ОЗУ для ресурсоёмких
> операций, а потом опять забирает —
Кэп намекает что так работает любой вменяемый менеджер дискового кеша, и почему-то такое поведение можно пронаблюдать как минимум в линуксе и без ZFS :)))
> оперативная память используется ВСЯ. Чего не скажешь от традиционных решениях.
Нюню? Это где это такой поганый менеджер кеша что он не в состоянии использовать свободную оперативку под кеширование при ее наличии? Как миниум в линуксе такого кретинизма не замечено - там кеш ведет себя именно так как ты и описал выше. Лол.
> Наверно поэтому для них придумана вся эта шумиха вокруг виртуализации и гибкого
> распределения ресурсов,
Эй, мы не договаривались что ты будешь жрать вещества в процессе написания коментов?! Виртуализация обычно используется потому что современный сервак с сотнями оперативы и гроздями процов - зачастую сильно мощнее чем требует один сетевой демон. Поэтому пилят на кучу отдельных виртуальных серверов. Ну как бы культурные люди не валят все сетевые сервисы в одну помойку - по соображениям минимизации последствий от взломов/факапов/сноса у софта крыши/административных ошибок. Т.е. лимитирование и полисовка потребления ресурсов + мощная изоляция сервисов друг от друга, почти как выносом на отдельные железки. И просто по удобству администрирования. Админить и мониторить несколько простых как топор и хорошо подконтрольных систем - проще чем одного переростка, в котором проблематично контролировать текущие процессы и чем он там сейчас занят вообще.
> чтобы загрузить процессор и память на 100%, запуская несколько
> виртуальных машин на одном процессоре/в одном пространстве памяти несмотря на то,
> что организация самой витуализации потребляет 10-20% вычислительных ресурсов.
Капитан намекает что если некий сервак загружен на 80-90%, виртуализовывать его оставляя на той же железке и правда как-то тупо (а зачем?) и чревато (действительно можно тормознуть почем зря). Зато если сервак загружен на 20%, пусть он в той же позе станет загружен на 22 или даже 24% (учтем 10-20% оверхеда, ок). Но остальные то 70 с гаком процентов будут свободны для использования иными сервисами, как "якобы отдельная машина". Ну то-есть думать надо головой, а не другими частями тела. Ну ничего, парни из Яндекса вам кажется доступно все объяснили - как-то вот так: http://habrahabr.ru/blogs/os/124563
[...]
> на LVM-снапшоте делаются? Или это не снапшоты вовсе, а просто образ
> файловой системы в определённый момент времени,
Капитан сообщает что под снапшотом и понимается состояние чего либо на некий момент времени. Для ФС - состояние ФС на этот момент времени. Чего не так то? И зачем вообще сдался dump/restore?
> который годен лишь, чтобы на него посмотреть и выбросить, чтобы не тормозить
> I/O всей дисковой подсистемы? Ась?
Снапшоты нужны в основном
1) Чтобы снять бэкап без изменения состояния файловой системы в этом процессе (если файл будет меняться прямо при его чтении бэкапной программой - в бэкап попадет черт знает что, смесь старой и новой версий, которая вообще работать не обязана)
2) Как средство отката в случае тех или иных факапов.
С таким даже LVM справится. Хотя я и не стал бы орать что его реализация снапшотов такой уж супер-пупер. BtrFS будет лучше, что не удивительно - оно вообще сплошной набор снапшотов по сути :)
>> Не, если у кого зад просит приключений с свежаком и патчами - это вариант, но можно
>> же и без острых ощущений, а?
> Можно. Без острых ощущений — просто используете современные технологии и ффсё.
Позволю себе отметить что UFS современной технологией ни разу не является. Почему я так считаю - изложено выше.
