ещё одна... я из тех что уже есть и то не могу выбрать...

Недавно xfs умерла на рейде. После сбоя питания и восстановления периодически всё рушилось с ошибкой 22. Файлы в lost'n'found не удалялись... Что-то расхотелось мне экспериментировать, вернулся к ext3.

зы фича под названием crash counts звучит многообещающе =)

И как она показывает себя в боевых условиях?

З.Ы. Раньше юзал рейзер, потом ext3, теперь jfs. Последний - ИМХО самый быстрый.

>И как она показывает себя в боевых условиях?

Там же написано что это Ph.D. Каких нафиг боевых условиях?

Во-во, я тоже шел по пути reiserfs => ext3 => xfs => jfs

мне кажется, что crash counts должен по определению равнятся нулю.. либо стремится к нему. а так как-то смешно получается..

> мне кажется, что crash counts должен по определению равнятся нулю.. либо стремится к нему. а так как-то смешно получается..

Он и будет стремиться, если поставишь нормальный бесперебойник. ФС тут не при чём. :)

А я правильно понял, что по местной традиции никто не прочитал, что же такое этот самый crash counts?

> А я правильно понял, что по местной традиции никто не прочитал, что же такое этот самый crash counts?

Счётчик такой, увеличивается при монтировании, уменьшается при размонтировании.

хех а я почти на оборот ext3->reiserFS пока всё ок, не жалуюсь.

ОФФТОП: а что там на счёт рейзера то слышно ? опровдали или как?

По теме: ктонить юзал сие чудо? И что даёт этот ... count???

Benchmarks:

http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/benchmarks/

Колонка Spad/* обозначает работу FS под ОС Spad, разрабатываемую автором.

Очень неплохие результаты.

>Счётчик такой, увеличивается при монтировании, уменьшается при размонтировании.

И при чём здесь бесперебойник и стремление к нулю, в таком случае? :)

Всё-так crash counts, как вы сами верно подметили, - это не количество сбоев.

Да ладно вам цепляться к терминологии. :) Здесь crash - некорректное завершение работы системы. А вы что подумали? :)

>New method to maintain consistency across crashes --- crash counts.

Как храниться -- понятно. А вот как это используется при восстановлении -- ни слова.

>Files are embedded directly in directory structure (unless hardlink is created). Thus, ls -la command doesn't have to seek to inodes.

Сползаю пацтул... Или он имел в виду inode, засунутый в каталог? Это мы, впрочем, тоже проходили... А если потребуется создать хардлинк? А потом удалить его? Сколько времени займёт такая операция?

>Free space is described in lists of extents rather than bitmaps like in most common filesystem. If a filesystem becomes too fragmented, list of free extents is converted to bitmap.

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

Чудо в перьях... Велосипедист фигов...

> ещё одна... я из тех что уже есть и то не могу выбрать...
> Недавно xfs умерла на рейде. После сбоя питания и восстановления периодически всё рушилось с ошибкой 22. Файлы в lost'n'found не удалялись... Что-то расхотелось мне экспериментировать, вернулся к ext3.
> зы фича под названием crash counts звучит многообещающе =)

Раньше мерялись пиписьками и аптаймом - теперь будут crash-count'ами ;)

И самый прикольный вопрос: p4-3GHz - это здорово и классно, сказевый мегарейд унутре - вообще шоколадно, но как оно будет на p1-120 с памятью типа "edo-ram" при прочих равных бегать?

А то знаем мы такого велосипедостругателя, Хансом Райзером зовущегося и номером "4" грозящегося всех зарулить...

имхо +1 :)

>как оно будет на p1-120 с памятью типа "edo-ram" при прочих равных бегать?

Никак. Нормальные люди такое старье подарили бомжам давно. А ненормальные могут и с 2.2.26 и ext2 сидеть - самое оно для такого железа.

> Как храниться -- понятно. А вот как это используется при восстановлении -- ни слова.

> Сползаю пацтул... Или он имел в виду inode, засунутый в каталог? Это мы, впрочем, тоже проходили... А если потребуется создать хардлинк? А потом удалить его? Сколько времени займёт такая операция?

> Он, наверное думает, что так будет сильно быстрее?

http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/download/INTERNALS читали?

http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/benchmarks/ смотрели?

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

А что там с Хансом, кстати ? Каковы последние новости с фронтов? Я личную жизнь имею в виду.

Скоростные тормоза.

> attempt to bring ... good performance

> uses hash instead of btrees for directory organization

Не совсем понимаю как соотносятся эти два пункта. Каким образом ассоциативные массивы позволят нам искать быстрее деревьев? Дайте ссылку для более подробного изучения матчасти.

Про Ганса: что у него с личной жизнью доподлинно неизвестно, жена пропала без вести 3 сентября. Сейчас Ганс ожидает заседания суда, которое состоится 28 ноября.

И насколько мощьный этот спад? Золото скупать?

>Сейчас Ганс ожидает заседания суда, которое состоится 28 ноября. Вот это, собственно, инетересовало. Спасибо.

> Каким образом ассоциативные массивы позволят нам искать быстрее деревьев? Дайте ссылку для более подробного изучения матчасти.

Среднее время поиска для хэша - O(1), для балансированного дерева - O(log(n)), поэтому на больших массивах хэш заведомо выигрывает.

http://en.wikipedia.org/wiki/Associative_array#Efficient_representations

офф

> Про Ганса: что у него с личной жизнью доподлинно неизвестно, жена > пропала без вести 3 сентября. Сейчас Ганс ожидает заседания суда, > которое состоится 28 ноября.

а кого судят-то?

Ханса Рейзера :(

Жену, как утверждают, свою грохнул...

>Никак. Нормальные люди такое старье подарили бомжам давно. А ненормальные могут и с 2.2.26 и ext2 сидеть - самое оно для такого железа.

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

ЗЫ И чем ядра 2.4-2.6 плохи для старых машин?

> Ханса Рейзера :(

фигасе.. :( ну ни пуха ему..

Может, "кеширование", а не "хеширование"?

> А что там с Хансом, кстати ? Каковы последние новости с фронтов? Я личную жизнь имею в виду.

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

Валяюсь. Мало того что никто не прочитал как обычно инфу по линку, так еще и анонс блин: "Для быстрого восстановления целостности после краха, вместо журналирования, используется технология "crash counts";"

Directory entry is valid if cct[entry->cc] >= entry->txc --- if not valid, it skipped just as if it didn't exist when scanning directory.

Это теперь так называется быстрое восстановление "целосности" после краха? Если число транзакций над директорией > числа успешно завершенных транзакций (т.е. крах был на момент записи в эту директорию), то при следующем монтировании директория просто пропускается, т.е. пропадает. Охеренное восстановление целосности.

>Недавно xfs умерла на рейде.

http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

xfs для SGI железа ;)

Название заставляет задуматься стоит ли ставить её вообще куда нибудь.. назвал бы уж Pod`em что ли вместо Spad-а )

Почитал про ейные internals. Не фонтан.

В новости сказано "Плавающий размер блоков, начиная с 512 байт" - тут не ясно, речь то ли об экстентах, то ли "Variable block size from 512 bytes to machine page size" - то, что уже есть... кстати, размер страницы (4К на x86) для некоторых случаев маловат будет.

Filesystem has current crash count [disk_cc], that is incremented with each mount and decremented with each unmount (thus, it counts crashes) ... New entries are written with values (entry->cc = memory_cc, entry->txc = memory_cct). So they are seen as valid in current directory scans, but in case of crash, disk will contain one-less value: disk_cc[entry_cct] == entry->txc - 1, so they will be invalid.

Попросту говоря, всё, что было создано, переименовано etc. между монтированиями - будет просто потеряно нафиг. Что при больших аптаймах довольно неприятно. Конечно, это наверняка будет переделано от монтирований до sync'ов - но временные промежутки между sync'ами опять-таки могут быть очень велики, причем появляется значительный оверхед на скан/апдейт ВСЕХ структур на диске при sync'е. А значит, раздел с большим количеством файлов нехило так подвиснет при этом.

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

Дальше, инодов нет, а fnode_block has 512 bytes - такой здоровый, а занят непонятно чем. Из отсутствия инодов следует необходимость эмуляции хардлинков несколькими fnode'ами -> усложнение кода. Используется хэширование, а не B-tree, в результате при коллизиях оно становится весьма неэффективным, плюс дополнительные сложности кодеру при реализации указателей на текущую позицию для стандартных функций (telldir(), seekdir(), etc.). Что мешало свистнуть идею из NTFS, непонятно, если уж разделение каталогов и инодов так не нравилось.

Sparse files are not supported. - вот это ОЧЕНЬ серьезный минус.

Из отсутствия инодов следует невозможность открытия файлов по номеру инода для NFS. И fnode тут не помогут, потому что их номера могут меняться из-за использующейся эмуляции хардлинков.

Each fnode can have up to 176 bytes of extended attributes.

Ну как украли, чесслово. Что туда впихнешь серьезное?..

The attributes are identified by a name (3 bytes), length (1 byte) and content. Unlike in other filesystems, extended attributes are not meant to be changeable by the user, they are meant to be set by the filesystem driver to deal with specifics of a given operating systems.

Точно, украли. Нафиг они такие нужны, если пользователю недоступны? Куда ACLи пихать будем? Ладно, может драйвер их еще возьмет, но длина маловата для серьезного списка.

Symlink length is limited to 172 characters - мда.

When the apage fills up, it is split. If it is too fragmented (such that bitmap would be more efficient than this list), it is converted to a bitmap.

За что боролись, за то и напоролись.

The groups and zones have no disk structures associated with them --- they are kept only in memory and their purpose is to prevent fragmentation.

И как бы нет, и как бы есть, но не для того, для чего у всех (минимизация передвижения головок при seek'е), а для фиктивного уменьшения фрагментации, ну да...

Резюме: фтопку.

//nuclight

> Дайте ссылку для более подробного изучения матчасти.

http://portal.acm.org/citation.cfm?id=320092&dl=ACM&coll=portal

Анонимусы жгут!!!

> xfs для SGI железа ;)

На ноуте пользовать можно. Нужно конечно быть осторожнее, чем в случае с ext3, но отключение педалью POWER без при отсутствии нагрузки на диск XFS переживает без проблем.

Spad - отличное название!

Но худшее - O(N) ЕМНИП, деревья гарантируют логарифмическое время поиска. Вообщем см. 3 том Кнута.

> http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc > xfs для SGI железа ;)

Там дальше и про fsck.reiser весёлая история :)

Тут недавно пробегала новость, что сановскую zfs на какую-то из BSD портируют. Возникает закономерный вопрос: А КАК ЖЕ ЛИНУКС ??? Наш маленький зоопарк файловых систем без zfs будет неполон !

Сыроватая какая-то наработка.. Пока ещё..

Текст новости скопирован с http://www.opennet.ru/opennews/art.shtml?num=8902

Ну-с, весьма не плохо. Щас затестим. Как раз винтик валяется ненужный =)

Ну в общем довольно ыбстро. Но преимуществ пока особых перед допустим xfs/reiser/etc не вижу. Щас буду тестить скорость извлечения архивчега с сорцами ядра.

spad:

real 0m35.743s user 0m30.900s sys 0m3.660s

reiserfs 3.6 :

real 0m39.905s user 0m31.030s sys 0m3.990s

xfs: real 1m22.194s user 0m30.040s sys 0m3.400s

Винтики по скорости примерно одинаковые. xfs на мелких файлах сливает полностью. Щас будем тестить time cp file1 file2

Удаление:

xfs:
arceny@arceny /drive2 $ time rm -rf linux-2.6.18/

real    0m41.116s
user    0m0.010s
sys     0m1.480s


reiserfs 3.6:
arceny@arceny ~/tmp $ time rm -rf linux-2.6.18/

real    0m1.862s
user    0m0.020s
sys     0m1.780s


spadfs:
arceny@arceny /mnt/gentoo $ time rm -rf linux-2.6.18/

real    0m0.831s
user    0m0.000s
sys     0m0.410s

размер файла 695,6 мб

reiserfs 3.6
arceny@arceny ~/tmp $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m29.399s
user    0m0.010s
sys     0m2.610s
arceny@arceny ~/tmp $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m26.570s
user    0m0.000s
sys     0m2.580s
arceny@arceny ~/tmp $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m27.647s
user    0m0.020s
sys     0m2.530s


xfs:
arceny@arceny /drive2/ISO/ALT $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m28.685s
user    0m0.100s
sys     0m2.330s
arceny@arceny /drive2/ISO/ALT $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m28.839s
user    0m0.020s
sys     0m1.790s
arceny@arceny /drive2/ISO/ALT $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m33.118s
user    0m0.030s
sys     0m1.840s

spadfs:
arceny@arceny /mnt/gentoo $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m22.342s
user    0m0.050s
sys     0m1.580s
arceny@arceny /mnt/gentoo $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m22.077s
user    0m0.030s
sys     0m1.590s
arceny@arceny /mnt/gentoo $ time cp compact-3.0.4.iso compact-3.0.4.iso.2

real    0m22.865s
user    0m0.000s
sys     0m1.570s

Однако, хорошие результаты-то! =)
Файлопомойкой можно потестить =)

> А что там с Хансом, кстати ? Каковы последние новости с фронтов? Я личную жизнь имею в виду.

Не могу знать, вашбродь - свечку не держал, лопату не прятал.