Красота! Уже в 2009 году - диск в 2 террабайта. Прикольная статейка, так вот и не заметишь, как все выросло :)

>Красота!

да уж, красота. fsck займет всего 2 недели :)

Такое впечатление, что новость является подстрочником или автопереводом с помощью Промпта. Вроде все слова понятны, но в предложение как-то не складываются...

опять "свежая" новость на лоре от 5 июля...

> опять "свежая" новость на лоре от 5 июля...

не надо ворчать :) некоторые в отпуске были

да, это проблема...
скоро диски будут размером в терабайты, но скорость доступа увеличится
только в 5 раз, а время сика только в 1.2 раза.

т.е. щас для того чтобы зачитать весь винт (типа dd if=/dev/sda of=/dev/null bs=128k) нужно меньше часа, а в будущем это будет порядка 3-4 часов.
fsck ваще будет отрабатывать недели на рейдах, ext3 никуда не годится.
недавно слетел рейд на кернел.орг, так там все из бэкапов накатили,
fsck хотел фачить аж 2 недели ).

нужны новые фс, в которых эти факторы будут учтены.
может Ганс Рейзер че придумает?

Сижу на 80Гигах, всё устраивает плюс 20 гигов временно занимает венда.

Зачем кому-то 2Терабайта? Гигазы порнухи, нелегальных фильмов и музыки хранить? Когда смотреть-то и слушать? 24/7/365 чтоли?

То есть из 80 - 20 отдано венде.

>диск в 2 террабайта

Т.е. "землебайта"?

>Зачем кому-то 2Терабайта?

Видео высокой чёткости, например. Или ты до сих пор 320x240 смотришь? Текстуры новых игр. Кеши GoogleEarth. Обработка домашних видеозаписей. И т.д. и т.п.

У меня сейчас под завязку забиты 80+80+80+120 = 360Гб. Это при том, что я те же фильмы (обычные, не высокой чёткости) на DVD храню... А надёжность DVD как бы всем известна. Сотню-другую дисков легко бы на винт перенёс. Итого - уже под терабайт набегает _сегодня_. А что завтра? Или опять "640 кБ хватит на всё"?

Ну когда будут на компе фильмы с Blue-Ray и HD-DVD хранить тогда и понадобятся такие винты ))

>Кеши GoogleEarth.

googleearth не тру

тру это - ww2d с плагином под гугльерс карты:)

Офигенное чтиво. Да, проблемы с ФС грядут..

По поводу винтов. У меня 200+200+80 - забито под завязку. и HDTV-аниме в том числе. Коллекция ISOшников дистрибутивов (на болванках хранить-то не особо удобно, да и небезопасно), аниме, фильмы, много tru pagan-black...

Планируется ещё 2*500 когда они подешевеют. то есть, видимо, в следующем году.

ИЗ ФС я думаю для мультимедии вполне xfs годится. Для раздела с документами/мелкими файлами - reiser 4.1 какой нибудь.

> Или опять "640 кБ хватит на всё"?

Ага! Транспьютеры и нанотехнологии в массы.

> да, это проблема... > скоро диски будут размером в терабайты, но скорость доступа увеличится > только в 5 раз, а время сика только в 1.2 раза.

> т.е. щас для того чтобы зачитать весь винт (типа dd if=/dev/sda of=/dev/null bs=128k) нужно меньше часа, а в будущем это будет порядка 3-4 часов. > fsck ваще будет отрабатывать недели на рейдах, ext3 никуда не годится. > недавно слетел рейд на кернел.орг, так там все из бэкапов накатили, fsck хотел фачить аж 2 недели ).

> нужны новые фс, в которых эти факторы будут учтены. > может Ганс Рейзер че придумает?

мерси за выжимку первой страницы :), я выложу сюда перевод второй и третьей как переведу, to be continued вобщем...

> Такое впечатление, что новость является подстрочником или автопереводом с помощью Промпта. Вроде все слова понятны, но в предложение как-то не складываются...

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

> опять "свежая" новость на лоре от 5 июля...

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

Виндавозник АААААА!!!!!!!!

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

Опять-же миф о надёжности жёстких дисков. DVD - покупайте Verbatim и не парьтесь. Последнее время и винты валяться гроздями, так что за неимением редундаиции рискуете батенька не меньше болваночников, а даже и больше. На 3 года гарантиии не смотрите - заменят вам на такой-же грошовый диск, а данные с 200 гигов то тютю. А Болванка одна вылетит - чай 4 гига выгрузить не проблема.

Сначала нужно эту отрасль раскрутить. DVD извините уже настолько хорошего качества, что покупать blue-ray как-то не прёт. Чтобы Вася П. разницу почувствовал это надо иметь Hi-End аппаратуру, спец. оборудованное помещение и некое понятие о качестве картинки и звука.

Может я и ретроград, но уровень качества двухслойного DVD на 95% удовлетворяет рынок (остальные 5 просто не знают чего хотят) и будет удовлетворять ещё лет 10 по крайней мере.

Дурак ты.

Интересно, что много внимания уделено ZFS. A reiser4, который тоже имеет интересные фичи вообще не упоминается. Интересно, почему разработчиков 4-ого рейзера не было на конференции.

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

> Сижу на 80Гигах, всё устраивает плюс 20 гигов временно занимает венда. > Зачем кому-то 2Терабайта? Гигазы порнухи, нелегальных фильмов и музыки хранить? Когда смотреть-то и слушать? 24/7/365 чтоли?

Каждому свое... кто оракел заводит, кто порнуху в его базы пихает ;)

> По поводу винтов. У меня 200+200+80 - забито под завязку. и HDTV-аниме в том числе. Коллекция ISOшников дистрибутивов (на болванках хранить-то не особо удобно, да и небезопасно), аниме, фильмы, много tru pagan-black...

Зайти что-ли в гости с карманным NAS'ом о 3.6Тб... никогда еще аниме в HDTV не видел... :)

> ИЗ ФС я думаю для мультимедии вполне xfs годится. Для раздела с документами/мелкими файлами - reiser 4.1 какой нибудь.

Еретик! Рейзер 3.6 - наше фсио! %)

> Вот скажи чё ты держишь на трети терабайта? Не, мне реально интересно. Порно-Киностудию чтоли организовал? > Опять-же миф о надёжности жёстких дисков. DVD - покупайте Verbatim и не парьтесь. Последнее время и винты валяться гроздями, так что за неимением редундаиции рискуете батенька не меньше болваночников, а даже и больше. На 3 года гарантиии не смотрите - заменят вам на такой-же грошовый диск, а данные с 200 гигов то тютю. А Болванка одна вылетит - чай 4 гига выгрузить не проблема.

Да все просто, объемное кино и образы ДВД-х. Мозг не резиновый и любит читать книжки и листать мангу, а вот кино в больших количествах не воспринимает ;) Посему оное накапливается на стораджах, когда не лень поднимается сеть и оное растаскивается другими юзерами... буфер, короче.

Самое правильное кино болванится, особо старое и ценное - болванится избыточно... все как положено...

> Сначала нужно эту отрасль раскрутить. DVD извините уже настолько хорошего качества, что покупать blue-ray как-то не прёт. Чтобы Вася П. разницу почувствовал это надо иметь Hi-End аппаратуру, спец. оборудованное помещение и некое понятие о качестве картинки и звука. > Может я и ретроград, но уровень качества двухслойного DVD на 95% удовлетворяет рынок (остальные 5 просто не знают чего хотят) и будет удовлетворять ещё лет 10 по крайней мере.

+1

И еще в силу распространения x264... Можно еще больше повысить "плотность" записи, сохраняя качество. А 192КГц 24 бит аудио и всякие HDTV извраты - попросту избыточны, т.к. прирост количества полезной информации ничтожен, а требования (и цены на железо) растут неслабо, плюс теряется совместимость со старыми железяками.

>Вот скажи чё ты держишь на трети терабайта? Не, мне реально интересно. Порно-Киностудию чтоли организовал?

Я выше перечислял.

>Опять-же миф о надёжности жёстких дисков. DVD - покупайте Verbatim и не парьтесь.

А ты в курсе, что Verbatim своих болванок не делает? Все они - сторонних производителей. И раз на раз - не приходится.

Вообще - падёж дисков уже приобретает всё более массовый характер.

А вот в случае винта - никто не мешает просто перекопировать на резервный винт. Благо, при снижении цен на терабайтники это будет не шибко накладнее (вон, на Савке сейчас 300Гб стоит $115)

>На 3 года гарантиии не смотрите - заменят вам на такой-же грошовый диск, а данные с 200 гигов то тютю.

Бэкапы таки отменили? Или миррор?

>А Болванка одна вылетит - чай 4 гига выгрузить не проблема.

Откуда? От Господа Бога? 4гига болванка - это несколько тысяч семейных цифровых фоток. Или пара месяцев сбора документов для диссертации (у друга - историка для дисера сейчас уже около сотни гигов сканов документов)

>DVD извините уже настолько хорошего качества, что покупать blue-ray как-то не прёт. Чтобы Вася П. разницу почувствовал это надо иметь Hi-End аппаратуру, спец. оборудованное помещение и некое понятие о качестве картинки и звука.

Посмотри, чем завалены прилавки магазинов уже год, если не полтора. На 1900x1200 20" мониторе (цена которых уже ниже, чем у 17" два года назад) смотреть средний DVD - это изврат. Всё плывёт и мылится... А HDTV на DVD уже не лезет. Даже по битрейту. У тебя DVD выдаёт 25мбит/с? У меня - нет.

>Мозг не резиновый и любит читать книжки и листать мангу, а вот кино в больших количествах не воспринимает ;) Посему оное накапливается на стораджах, когда не лень поднимается сеть и оное растаскивается другими юзерами... буфер, короче.

О! Тоже +1 :) У меня, правда, поскольку места на винте катастрофически не хватает, болванится всё в количестве 2..3 болванки в неделю. И лежат сейчас несмотренных болванок 20... :)

Был бы винт хотя бы 500Гб - лежало бы там :)

> О! Тоже +1 :) У меня, правда, поскольку места на винте катастрофически не хватает, болванится всё в количестве 2..3 болванки в неделю. И лежат сейчас несмотренных болванок 20... :) > Был бы винт хотя бы 500Гб - лежало бы там :)

Дык :) Места то валом и никакая это не проблема, самый задрипанный роутер несет на борту зеркало о сотне гиг... а вот нормального контента в тех завалах маловато... у меня мечта вообще - нарыть безлимитный варезник со складом старых исторических китайских историй-махаловок (типа про школы боевых исскуств, пропащих и непутевых сыновей, учителей-отшельников примотанных лианами к самоходным кирпичам округлой формы и т.п. извраты), вот где клад %)) И в пару сему варезнику - автоматическую писалку с батареей на сотню сменных ДВД-х :)

И писать, писать, писать... а потом уйти в отпуск, свалить на юг со стораджом в кармане и валяясь на горе все это смотреть +)

Интересная переписка в тему (правда на английском):

Filesystems, Politics and the Kernel

http://kerneltrap.org/node/6876

Ставьте XFS - работаю более 5 лет на нём, в своё время прикручивал его руками к ядру(патчил), щас накладывать вообще ничего ненужно. Всё есть в ядре!

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

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

Всем доволен и она меня ниразу не подводила, а даже и спасала, когда тот же Рейзер и я уже не говорю о костыле под названием Ext3 - ненадёжны и ужастны.

> А Болванка одна вылетит - чай 4 гига выгрузить не проблема.

Болванка не вылетит , возникнут bad-sectors кое-где, умный mplayer при проигрывании фильма просто пропустит несколько секунд фильма, и даже можешь этого не заметить.

С HDD же кроме bad-sectors есть опасность потерять все сразу из-за электроники, или механических повреждений. Уроните несколько раз DVD болванку и винчестер для пробы.

> Всем доволен и она меня ниразу не подводила, а даже и спасала, когда тот же Рейзер и я уже не говорю о костыле под названием Ext3 - ненадёжны и ужастны.

А я вот читал что XFS может гробить данные при отключениях питания на x86 железе, так как писалась в расчете на другое железо, которое питание на вичестер как-то помягче отключает или что-то типа того.

Так что лучше на надежном ext3 посижу.

>Ставьте XFS - работаю более 5 лет на нём Новые приколы относительно XFS

XFS: corruption fix Fix nused counter. It's currently getting set to -1 rather than getting decremented by 1. Since nused never reaches 0, the "if (!free->hdr.nused)" check in xfs_dir2_leafn_remove() fails every time and xfs_dir2_shrink_inode() doesn't get called when it should. This causes extra blocks to be left on an empty directory and the directory in unable to be converted back to inline extent mode.

это Changelog от 2.6.17.7

а это про тормоза в ветке ядра 2.6.17

http://www.ussg.iu.edu/hypermail/linux/kernel/0605.2/1741.html

Сам столкнулся. Собрал дистр. Федоры с новым ядром, установка на XFS 50мин. Попробовал старый вариант с 2.6.15 установка 24мин. Думайте сами, решайте сами (не я)

Добрый сэр, угадаете что тут можно сказать? :) Правильно - "боян" ;)

Задолбал этот пиарщик Райзер, сейчас сует 4.0, через пару месяцев начнет пиарить 4.1, потом вообще 5.0 объявит... и не занимается поддержкой нифига, как уже было правильно замечено, а отдуваются OSS разработчики.

> Болванка не вылетит , возникнут bad-sectors кое-где, умный mplayer при проигрывании фильма просто пропустит несколько секунд фильма, и даже можешь этого не заметить. > С HDD же кроме bad-sectors есть опасность потерять все сразу из-за электроники, или механических повреждений. Уроните несколько раз DVD болванку и винчестер для пробы.

Смеялсо :)

Прям сижу и вижу, как будут проверяться многокилобаксовые ленточные приводы от Санок - на...нуть по ним кувалдой пару раз от души и с крыши билдинга отправить в неуправляемый полет, если не накрылись - ваахххх, military-grade стабильность и надежность :)

Tempest-винты как? тоже сектора терять будут? ;)

>Сам столкнулся. Собрал дистр. Федоры с новым ядром, установка на XFS >50мин. Попробовал старый вариант с 2.6.15 установка 24мин. Думайте >сами, решайте сами (не я)

Я с РедХата 6.1 начинал.... XFS такие тормоза никогда не показывала что аж в два раза. Юзал и Федорку и другие системы - XFS там работает и шустро, максимум 2-4% отличия и всё. (надо ещё железо настраивать hdparm'ом правильно) Как было в вышеприведённых постах сказано - главное ---- надёжность файловой системы, с чем у XFS отлично. А что что ошибки есть - увы, они есть во всем и на то и делает обновления и тому подобное. Ошибки правяться, данные на месте, у меня порой на серверах LA доходит под 25-45 и спокойно XFS справляется (железо не сказёвое). Так что Ext3 - я никогда не поставлю, ибо после ребута, оно почти 50 на 50 что не поднимит сервак до Левела 3, когда сеть стартанёт, и когда можно удалённо поработать. А XFS - всегда это у меня делала и делает. Ещё раз - ну работает, глюков не замечано, пашёт давно!!! Стоит и Оракл! Так что в топку новые системы...

The 2006 Linux File Systems: день первый

День Первый: Данные
-------------------
Первый день конфы был посвящён обзору данных об аппаратном обеспечении, существующим архитектурам файловых систем и проблемам пользователей. Участники конфы:

Val Henson, Intel - разработчик ZFS
Zach Brown, Oracle - разработчик OCFS2
Arjan van de Ven, Intel - давний "поддержатель" (или шпалоподбивочная машина, как переводит это лингво :) ) дистрибутива ядра и Линукс хакер вообще
Andreas Dilger, Cluster File Systems - разработчик Lustre
James Bottomley, SteelEye - поддерживающий Linux SCSI
Chris Mason, SuSE - разработчик Reiserfs
Christoph Hellwig, разработчик (представился сам) XFS, JFS, VxFS, и файловых систем вообще
Mark Fasheh, Oracle - разработчик OCFS2
Ric Wheeler, EMC2 - архитектор систем хранения
Theodore Ts'o, IBM - разработчик ext2/3
Mingming Cao, IBM - разработчик ext3
Felix Blyakher, SGI - разработчик XFS

На второй день конфы заглянул Линус Торвальдс.

Ремонт Файловой Системы
-----------------------
Мы начнём разъяснение с намечающегося временного кризиса fsck и увеличивающейся частоты неремонтопригодных ошибок ввода/вывода, как описано во введении обзора. Давайте сначала осмотрим что действительно делает fsck. Fsck может быть разделена на три главные задачи: ремонт, восстановление и обновление.

Ремонт. Fsck был изначально написан для ремонта после "грязного" монтирования файловой системы, возможно после отказа системы или потери связи с диском. Например блок может быть адресован косвенным блоком, но не быть помеченным в блоковом битмапе. Журналируемые ФС формализовали процесс ремонта в таком случае, перетаскивая иногда ремонтный код из fsck, например XFS разделила fsck на внутриядерный журнальный код воспроизведения и утилиту называемую xfs_repair.

Восстановление. Вполне логично расширить fsck для устранения несогласованности в ФС вызванной аппаратной/программной ошибкой или другой порчей данных. Эти ошибки менее предсказуемы, чем в случае чистого ремонта, но многие из повсеместно встречающихся ошибок могут быть исправлены. Для восстановления fsck должен зачитать все метаданные всей файловой системы.

Обновление. Наконец fsck используется при прохождении всей ФС для поиска скрытых ошибок и их исправления прежде, чем они станут слишком плохими. Это задача различных таймаутов fsck в ext2/3 (фиксированное число монтирований или определённое число дней после последней проверки). Это использование fsck намного более приемлимо, если оно может быть сделано фоновым.

Большинство ФС концентрируются на ускорении ремонта, но восстановление и обновление становятся всё более важными. Сегодня восстановление ФС может занять несколько дней и дальше будет только хуже. Во многих случаях нечитаемые данные также плохи как потерянные, что хуже, потеря файла и его восстановление из бекапа за несколько часов или невозможность зачитать любые файлы несколько дней?

Одно из решений сегодня - разбить диск на много небольших ФС, которые мб восстановлены индивидуально. К сожалению это приводит к усложнению администрирования и более частым ошибкам ENOSPC (нет места), поскольку файлы и директории не могут пересекать границы ФС. Хуже того, ошибка одной ФС может привести к отказу всего ядра и недоступности вообще всех данных.

Часто предлагаемый обходной путь - оптимизация fsck. Возможно узкое место в самой fsck и нужно добавить упреждающее чтение и переупорядочивание блоков и улучшить немного алгоритмы. Однако большая часть очевидных оптимизаций уже сделана в ext2/3. Долгосрочное решение требует удвоения производительности каждый год, для того чтобы успевать за разрывом между ёмкостью дисков, пропускной способностью и временем поиска - недоступная (unsustainable) цель.

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

Диски и Ошибки
--------------
Этот тип ошибок дакже влияет на архитектуру ФС. Перещёлкивание битов в силу физических причин в среде носителя нам знакомо и в наши дни диски имеют внутренние чексуммы для обнаружения таких ошибок. Вообще бессмысленно пытаться повторять операцию чтения на уровне ОС, поскольку в точке где ОС видит ошибки такого рода, они уже не исправляются.

Однако, другой класс ошибок не может быть обнаружен или исправлен с помощью внутренних чексумм диска. Классифицируются такие ошибки как "high-flying writes" и "over-powered seeks", "phantom writes" и "misdirected reads and writes". В основном диск не записывает данные, но утверждает, что делает это (при "high-flying writes" - головка слишком высоко над поверхностью и не меняет состояния битов), или завершает ввод-вывод на неправильном блоке ("over-powered seeks" - означает, что головка оказалась на неправильном месте в начале операции ввода-вывода). Внутренние чексуммы не могут обнаружить таких ошибок, поскольку чексуммы соответствуют локальным данным, которые или старые, или неправильные. Поэтому ОС необходимо иметь чексуммы на более высоком уровне. Сановская ZFS использует этот подход и кладёт чексуммы в косвенные блоки, что решает большинство проблем с неправильным или фантомным вводом-выводом без ухудшения производительности. Чексуммы такого рода решат много проблем с паникой/отказом, вызванных проверкой попорченных метаданных ФС.

Другой интересный класс ошибок есть результат отказов RAID или volume manager. Часто отказы будут происходить в размерах стрипов, например, когда 64KB данных заканчиваются нулём(-ями) (прим перев - как же, как же помню, как засунул сказёвый интерфейс к RAID в неполноценный писиайный слот на асусовской материнке, а потом удивлялся, почему правильно читаются только маленькие файлы 8-/ ). Некоторые системы в действительности нарезают побайтово, что приводит к потерянным байтам через регулярные интервалы.

Поскольку ошибки ввода-вывода общее явление, имеет смысл копировать важные данные, как это уже сделано с суперблоком. Однако для того чтобы это имело смысл, данные должны "подчищаться" (scrubbed) - регулярно проверяться не попортилась ли копия и перезаписывать правильные данные перед тем как вторая копия попортится. Выступление (http://www.stanford.edu/class/ee380/Abstracts/060531.html) Mary Baker убеждает в этом при помощи модели, предсказывающей среднее время потери данных с подчисткой (scrubbing) и без. В промоделированной ею системе среднее время потери варьируется от менее чем года без подчистки, до 16 лет с подчисткой, в зависимости от частоты подчистки. Даже с двумя копиями данных их потеря удивительно общее явление вследствие парадокса дня рождения, демонстрируемого вопросом "Сколько людей вам надо знать, чтобы иметь 50% шанс совпадения у двоих из них дня рождения?" Ответ 23, поскольку шанс пропорционален квадрату числа людей (прим перев - похоже скоро теорвер станет штатным инструментом разработчика софта вообще и ФС в частности, пора освежать знания ;) ). "Сюрприз дня рождения", когда диски из одного набора ломаются в течение нескольких дней вследствие сходных дефектов производства, также увеличивает вероятность потери данных до удивительно высокого значения даже со многими копиями.

The 2006 Linux File Systems: день первый (продолжение)

Одна из проблем в реализации ФС, это большое разнообразие в качестве и доп средствах доступных на дисках разных производственных линий. Однако консолидирование индустрии (Seagate-Maxtor-Quantum) и производственных линий, когда диски зачастую отличаются только прошивкой, влияет положительно на бюджетные диски, поскольку большие корпоративные потребители покупают бюджетные диски и настаивают на лучшем качестве.

Другое измениние в аппаратуре дисков заключено в кешировании и переупорядочивании ввода-вывода. Возвращаясь к временам, когда была спроектирована FFS, максимальная скорость была возможна только для для чтения через-блок, поскольку диск должен был провернуть один блок под головкой перед тем, как ОС могла выполнить следующую операцию ввода-вывода (с этих времён есть поле указывающее задержку поворота во многих реализациях FFS). Затем диски начали поддерживать множественные ожидающие операции ввода-вывода и диски и ОС делали упреждающее чтение одного или более блоков, делаю последовательное чтение наиболее быстрым. Сейчас диски вычитывают целые треки в свою кеш-память (порядка 8 мегабайт), что заставляет вести себя любые операции ввода-вывода над тем же треком или группой близких треков так, как будто то бы они были последовательными на диске. Оптимальное размещение ушло от через-блок к последовательно-к-соседу достаточно хорошо (прим перев - а вы думали суперскалярный и out-of-order подходы только в процессоростроении используют? разработчики дисков тоже не лаптем щи хлебают).

Мы обсудили влияние наличия некоторой формы флеш или долговременной памяти доступной или на диске или в основной системе. Это часть того, что делает файл-серверы Network Appliances такими шустрыми - они кешируют запись на флеш и сразу возвращаются вместо ожидания, когда запись совершится на диске. Самый лёгкий способ это использовать флеш как кеш на запись блоков - физическое журналирование на отдельном устройстве. Или можно было бы хранить на флеше только метаданные, но это приводит к single point of failure - потере содержимого флеша означает потерю всей ФС и ограничивает отношение размера метаданных к размеру данных. Проектирование ФС в предположениии доступности флеша где-то в системе рисковано, учитывая что флеш доступен долгие годы, но не интегрирован как стандартный системный компонент. Скорость записи и число циклов записи перед отказом (100 000 - 1 000 000) также ограничивают зависимость системы от флеша. Вобщем ФС должна использовать преимущества флеш, но не требовать его наличия.

Повторяющаяся тема в наших обсуждениях это желание расширить интерфейс к диску. Даже простые диски это небольшие компьютеры сегодня, не говоря о RAID или многотерабайтных SAN серверах, и могут легко обработать более сложные запросы нежели "записать блок 37". Это слишком широкая тема для охвата здесь, но ключевым шагом является встреча архитекторов ФС и производителей дисков для обсуждения того какие интерфейсы были бы полезны.

Уроки Существующих ФС
---------------------
Один из уроков требует надёжной идентификации метаданных. Одно из преимуществ фиксированного числа инодов в статическом размещении заключено в том, что ошибиться смешав данные с метаданными намного более трудно и поэтому восстановить ФС намного легче. Идентификация потенциальных инодов только на основе magic number это прямой путь к отказу: рассмотрите ситуацию с файлом содержащим изображение ФС созданное через loopback - данные файла будут выглядееть как иноды. Метаданные должны идентифицироваться некоторого рода внеполосным механизмом, таким как дескрипторы группы блоков или спецзаголовки. При восстановлении ФС статическое расположение метаданных имеет серьёзные преимущества, задвигающие его недостатки (случайное истощённое пространство или недостаток инодов).

Другой урок дал понимание того, что номер поколения ФС помогает различать метаданные и данные, которые были когда-то метаданными на этом же диске. Если метаданные статичны, то они могут были обнулены при создании ФС, что делает создание затратным и медленным. Один из способов ускорить создание ext2/3 без добавления поколения ФС заключается в добавлении параметра к информации о группе блоков описывающей какая часть таблицы инодов инициализирована, так что fsck знает что нужно игнорировать остаток таблицы. Маркерный блок "Инициализировано до сюда" добавляет избыточность и безопасности к этой схеме.

Часто главная цель дизайна ФС заключается в уменьшении размера метаданных. Однако ряд исследований за последнее десятилетие показал, что многие диски заполнены только наполовину. Считая что избыточность метаданных помогает при восстановлении ФС, очевидно, что использование большего места для метаданных с целью уменьшения вероятности потери данных это важная уступка.

Одно из исключений к правилу место-на-диске-дёшево это маленькие файлы. Многие ФС неэффективны при хранении небольших файлов, причём маленькие файлы составляют большую часть файлов во многих ФС. Мы слышали о большом гос потребителе который хочет хранить миллионы файлов размеров около килобайта; некто указал, что большинство сорсов хранятся в файлах менее 4KB. Некоторые оценили размеры файлов на ноутбуках и обнаружили результаты:

<= 1 KB - 25-30%
<= 2 KB - 40-45%
<= 3 KB - 50-60%
<= 4 KB - 55-65%

Это то что создатели FFS обнаружили в 1984, использование 4KB блоков заполняет около 45% диска - вот почему они реализовали 1KB фрагменты (что осталось не сделанным в ext2/3). Новые ФС должны проектироваться для эффективного хранения маленьких файлов.

Одно из решений - упаковывать маленькие файлы вместе в один блок. Однако одна из возникающих в этом случае проблем это переписывание данных принадлежащих неизменяемым файлам, что увеличивает вероятность их порчи (прим перев - ну-ка. где там ФС всех времён и народов - РейзерФС?). Это также непросто реализовать и добавляет в код склонности к ошибкам.

Архитектуры Главных ФС
----------------------
Мы вкратце осмотрели архитектуры главных ФС и присущие им проблемы. Простые FFS-подобные ФС (первоначальная Berkeley FFS и ext2) просты, высокопроизводительны, легковосстанавливаемы, но требуют полного fsck после каждого сбоя, не имеют гарантии согласованности данных и формализованной защиты от порчи диска.

Архитектура наиболее популярных современных ФС журналируемая, такая как в ext3, reiserfs и многие другие. Журналируемые ФС добавили лог недавних транзакций к ФС, который пишется последоательно на зарезервированное место на диске. Главная ФС не модифицируется до записи всей транзакции в лог. Это позволяет быстрое восстановление после отказа, поскольку незавершённые операции переигрываются по логу. Проблемы с журналированием включают проблему двойной записи (в лог и в конечное местоположение) и проблемы производительности от ограниченного, "соревновательного" места для журнала. Также журналирование не помогает при порче диска.

Лого-структурированные ФС вызвали большое шевеление в комьюнити исследующих ФС но никогда не перескочили в массовое использование. Главное в понимании этих ФС заключено во-первых в том, что запись апдейтов в виде лога превращает группу произвольных операций записи в одну большую потоковую запись, которая номного более эффективна, и во-вторых в том что раз данные записаны в лог, зачем их нужно перезаписывать ещё раз? Такая ФС это по-существу один большой лог транзакций, с апдейтами добавляемыми в конец. Данные никогда не перезаписываются в месте размещения - лого-структурированные ФС это один из видов ФС с идеологией копирование-на-запись (COW). Главная проблема с лого-структурированными ФС то, что они требуют больших свободных кусков на диске, создаваемых тредом-чистильщиком (прим перев - мафиозная такая ФС, главное чтобы пользователь под руку не попался). Аллокированные блоки надо перетаскивать из частично свободных кусков и в другие куски. Издержки от наличия треда-чистильщика высоки даже после многолетних оптимизаций. Также вычисление необходимого места для завершения апдейта сложная задача (даже для записи ранее аллокированного блока), поскольку COW ФС не может освободить блок до окончания записи новой копии и число блоков необходимых для завершения операции непредсказуемо. Наконец, принудительное реаллокирование блоков требует "хорошего" аллокирования на каждую запись тогда как ФС с идеологией апдейт-на-месте требуют принятия такого решения только один раз.

Лёгкие апдейты были усовершенствованием Berkeley FFS которая сохраняла формат на диске устраняя нужду запускать fsck перед монтированием после отказа. Лёгкие апдейты тщательно упорядочивают апдейты ФС так, что если система отказывает в любое время, то ФС согласована за исключением что некоторые блоки и иноды "протекли" - помечены как аллокированные являясь свободными. Фоновый fsck, запускаемый на образе ФС, находит несвязанные блоки и помечает их свободными снова. Обратной стороной лёгких апдейтов является их чрезвычайная сложность в понимании и реализации, плюс каждая операция ФС требует её собственного специально спроектированного кода апдейта. Насколько нам известно, существует только одна реализация лёгких апдейтов.

Наиболее недавняя тенденция в архитекруре ФС это COW ФС, как типизируется WAFL (Write Anywhere File Layout, внутренняя ФС Network Appliance) и ZFS (новая ФС Соляриса). Эти ФС конструируются как дерево блоков. Каждый раз когда блок изменяется, новый блок аллокируется и цепочка блоковых указателей указывающих на него апдейтится - также вызывая появление копий этих блоков (прим перев - сложновато как-то, не находите?). Когда согласованный набор апдейтов записывается на диск, корневой блок атомарно апдейтится чтобы указывать на новое дерево блоков, которое включает текущую информацию об аллокировании. Такая структура делает образы (snapshots) чрезвычайно простыми в реализации и централизует код согласующий ФС. Недостатки схожи с некоторыми недостатками лого-структурированных ФС - принудительное реаллокирование на каждую запись и неопределённость в размере требуемого для завершения операции. Также хорошая синхронная производительность требует некоторый журнал усложняющий реализацию.

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

Таким образом закончился первый день конференции, в мраке и смерти (как сказал лингво, Black Sabbath). Только надежда на второй день конференции и обещанный мозговой штурм поднимали наш дух.

заметили, да? женщинам хочется взять в руки швабру и тряпку (Mary Baker с докладом про подчистку), а правильным пацанам соответственно растолкать старые носки под диваны и надеть новые (COW ФС с новыми копиями), вот так мышление различается по половому признаку на уровне ФС ;)))

>Уроните несколько раз DVD болванку и винчестер для пробы.

Тогда уже не болванку, а ящик с сотней болванок. Как говорится, ощутите разницу.

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

:D

filin, спасибо.

Молодец, спасибо =)

>нужны новые фс, в которых эти факторы будут учтены.

Дык уже - Sun ZFS!

>может Ганс Рейзер че придумает?

Этого - в попку живьем!

> Tempest-винты как? тоже сектора терять будут? ;)

Ты о чем вообще ?
Я о хранении больших обьемов десктопных данных , типа фильмов,
к которым не нужен доступ более чем к нескольким гигабайтам в день, а то и в неделю.

Иначе и предлагать диски не стал бы.
А ты о каких-то серверных не домашних по цене решениях.

>> Уроните несколько раз DVD болванку и винчестер для пробы.

> Тогда уже не болванку, а ящик с сотней болванок. Как говорится, ощутите разницу.

я думаю болванки сильно не пострадают , а винт может полностью отказать.

> Но в том-то и дело, что на винчестере несравнимо проще делать бэкапы и проверять автосохранность.

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


или можно и на винт и на болванки писать.

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