на ядре 2.4.20 от редхета(RH7.2) с ext3 много народу полягло, ибо они экспериментальную дыру включили %)

раз уж тут собрались спецы по выбору файловых систем, спрошу я у них совета. какую фс ставить на нотык с камнем p2 ~350 МГц и 160-ю метрами рамы? винта шесть гиг.

> Несколько раз терялись данные на ext3.
> Совсем, так что не лечилось. Ни разу на райзере.

lvcreate -L 100M -n aaa chimera
lvcreate -L 500M -n bbb chimera

mkfs.reiserfs /dev/chimera/aaa
mkfs.reiserfs /dev/chimera/bbb

mount -t reiserfs /dev/chimera/aaa /mnt/aaa
mount -t reiserfs /dev/chimera/bbb /mnt/bbb

cp /etc/* /mnt/aaa      # копируем /etc на маленький раздел
cp /boot/* /mnt/bbb     # копируем /boot на большой раздел

umount /mnt/aaa                              # отмонтируем
dd if=/dev/chimera/aaa of=/mnt/bbb/aaa.bin   # делаем образ
раздела aaa и сохраняем его как файл!

umount /mnt/bbb
reiserfsck --rebuild-tree /dev/chimera/bbb

mount -t reiserfs /dev/chimera/bbb /mnt/bbb

Теперь ls -l /mnt/bbb и...

Нет, мне ТАКОГО счастья не надо - все файлы
из образа легли как файлы на /dev/chimera/bbb!!!

> система представляет собой "объектное хранилище данных", а файловая структура - лишь один из плагинов для доступа к оным данным. дальше читай у Ганса.

Гансу надо меньше курить :-)

У любой палки 2 конца, а размеров одеяла часто не хватает:
на один бок потянешь - другой замерзает.

Рейзер делает logical block jornaling (т.е. несколько операций с журналом - в одну физическую операцию с диском) отсюда - он менее надёжен, но быстр

ext3 делает physical block jornaling (т.е. каждая операция -
на винт) отсюда большая надёжность, но меньшая производительность.

Выбирай, что больше подходит под твои задачи.

Поправьте ммння, если я не прав.

Терял данные на ext3 и ни разу на reiserfs и xfs.
Но стоит отметить что линукс выполняет у меня только десктопные задачи.

> Терял данные на ext3 и ни разу на reiserfs и xfs.

А ты попробуй сделать то, что я предложил :-)

>Терял данные на ext3 и ни разу на reiserfs и xfs

ну...с твоим-то опытом - неудивительно =)

Столько нездорового ажиотажа и массового возбуждения вокруг Reiser, что я начинаю задумываться о возвращении на ext3...

Ну нафлу... наспорили :) Вставлю и свои 4 копейки. Дело в том что с рейзером у меня был всего 1 глюк: ставил на ноут висту, попробовать. Ресайзнул reiserfs-раздел, и (нет бы подумать) ноут в hibernate. Через некоторое время включил, в инсталляторе висты создал на освободившемся месте NTFS-раздел. Посмотрел висту, гружусь опять в линукс... через 10 секунд после просыпания система виснет намертво (таблица разделов-то ни с того ни с сего изменилась), и после ресета просит --rebuild-tree. Я уже мысленно попрощался с данными, ан нет - 5 минут и все на своем месте. Не знаю, показывает это плюсы рейзера или минусы...

> Не к топику будет сказано, но в моей школе :) вынь95 стоит с тех пор как еще я ее лет пять назад туда поставил - на всех 16-ти компах ...

Стоит? А у меня оси работают, а не стоят.

> Без перезагрузки системы раширяется, но отмонтировать, а после раcширения, подмонтировать, нужно. >Тогда не канает. Простой пример - хорошо растущая база данных, с требованием бесперебойной работы. Подцепить на горячую винт получится. На ходу раздвинуть на него LV - тоже. А вот об отмонтировании раздела речи просто быть не может - работает же.

И что же ?? использую reiserfs & linux - все будет работать ? Мы про линукс говорим ? :) А как "с требованием бесперебойной работы" быть? Может все-таки поставить "ацтойную" солярку и нормальную железку и уж тогда работать бесперебойно ? :Ё

>раз уж тут собрались спецы по выбору файловых систем, спрошу я у них совета. какую фс ставить на нотык с камнем p2 ~350 МГц и 160-ю метрами рамы? винта шесть гиг.

reiser очень процзависим, так что вполне вероятно что будет сильно тормозить. где-то не так давно сравнивали фс на проце 500МГц - райзер отставал от всех. Судя по всему ему рекомендуется атлон/пень4. А у меня на к6-2 250 чудно работает ext2/3. Со всякими JFS, XFS связываться думаю не стоит.

> > > > Я терял несколько раз данные на Raiser и XFS и теперь ничто не заставит меня ими пользоваться. > > > Аналогично. > > Аналогично.

>Аналогично.

Аналогично

Мало того, добавлю что во-многих случаях (такое и у меня было и от других слышал) утилита восстановления нахрен не нужна, reiser падает мощно, со звоном и восстановлению не подлежит

Ню-ню...

В EMC в музее лежит диск объёмом 1Мб и физическим размером примерно с крайне неслабый чемодан -- почему бы на нём не потестировать? Или на raid0 из перфокарт?

Было бы интересно, потестить это на более серьёзном оборудовании с большим кэшом -- результаты без тестов предсказать нельзя, предсказать можно одно -- они будут удивительными.

Попробую на досуге.

>>Я терял несколько раз данные на Raiser и XFS и теперь ничто не заставит меня ими пользоваться. С Ext2-3 такого не было.

>Подтверждаю, основываяь на личном долгом опыте работы с ReiserFS 3.6 и ext3.

-1. Диаметрально противоположный опыт.

За 2 года работы на ext3 раз пять бились важные данные из них - три раза - после банального горячего резета. Один раз - убилась вся партиция (ап стену наверное :) ). Причем, система была рабочая и потому эксплуатировалась нежно и без надрыва. ;)

За три года работы с ReiserFS 3.x - ни разу ни малейшей потери, хотя эксплуатировалась система воистину жестоко - на домашней машине с нехилой постоянной нагрузкой (как ftp и mail-сервера одновременно + постоянное висение в DCC), регулярного испытаний новых unstable kernel и всяческих висючих xcomposite и другого OpenGL-ужаса в виде игр :) - в общем, огонь, вода и медные яйца.

Про ext2 даже говорить не хочу. С тем, что на ext2 Shaman007 ни разу не терял данных... ну это - как бы помягче... врать - не мешки ворочать... ;) Либо ext2 один раз пробовалась на 5 минут :) в пору первого знакомства с линукс :)

> А вот с ХФС проблемы были. Комп я ребучу в основном с ресета + часто >пропадает питание, часто "сигналят" светом етц. С ХФС пару раз >убивался раздел в попу. Лов лефел фотрматом лечилось. Восстанавливает >он из ног вон плохо.

101 раз...

1) Структура XFS такова, что вероятность восстановления после тяжёлых сбоев, очень высока

2) стандартные утилиты восстановления -- гавно, но и они прекрасно (в абсолютном большинстве случаев справляются). Только не забываем внимательно прочитать man xfs_repair !

3) *принципиальный* недостаток у XFS (JFS, и даже бывает, у NTFS) -- обнуление файла, открытого на запись во время внезапного сбоя. БИП -- вполне достаточное для нормальной эксплуатации, условие. Ну и, к сожалению, на "ненадёжном" питании, делать корень на XFS -- не самое мудрое решение, хотя примеров безсбойной работы машин с одним единственным разделом -- / на XFS и без упса -- тьма. Работает. Но можно и нарваться...

/GLeb

А ведь это ещё вопрос...

Реизер показал некие быстрые результаты...круто... Но по времени работы очевидно, что всё калбасня с файлами была в кэше файловой системы....на диск оно и не залетало... Цена такой файловой системы -- ноль:(

Вот если ты тесты были пусть с использованием кэша, но чтобы файлы всётаки реально падали на диск.... то было бы интересно.

Я запусттил сейчас тест на своей домашней машинке под fbsd-stable p$ 3.2G 1Gb ram. жду:)

Также запустил на sunfire 4900 на системных дисках(софтверное зеркали на сказёвых дисках). Когда он закончится, запущу это на лунах массива emc cx400.

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

Значит, рейсер4 умеет лучше обращаться с кэшем.

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

Видимо слабо кого-то интересует файловая система, размещённая в ram как место работы базы данных или почтовой системы?

Написано: Creation alone: 50000 files (12500 per second) _Любой_ диск не в состоянии выдать более 400tps. причём реально -- это не более 300. Вывод -- всё делается в ОЗУ/кешу.

Цена: 0.

В общем всё это инетересно не в ущерб надёжности.

Ни разу не терял данных ни на reiser 3.6, ни на XFS. Работают уже больше 3 лет, и ресеты, и выключения питания, и что угодно. От ext2 отказался давно, бесповоротно и полностью.

Запустил этот тест у себя. Вот некотаря инфа hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media Model Number: Maxtor 6Y080M0 Serial Number: Y249HQWE Firmware Revision: YAR51EW0

hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media Model Number: Maxtor 6Y080M0 Serial Number: Y248SG6E Firmware Revision: YAR51EW0

Эти два винта вотктнуты вот в такую железку: lspci | grep Promise 01:08.0 RAID bus controller: Promise Technology, Inc. PDC20371 (FastTrak S150 TX2plus) (rev 02)

Кароче RAID0 из них собран: dmraid -r /dev/sda: pdc, "pdc_ffafafdc", stripe, ok, 160086400 sectors, data@ 0 /dev/sdb: pdc, "pdc_ffafafdc", stripe, ok, 160086400 sectors, data@ 0

mkfs.ext3 /dev/mapper/pdc_ffafafdc3 mount /dev/mapper/pdc_ffafafdc3 /mnt/floppy/ Ext3 ========================================================================= Time: 1274 seconds total 1170 seconds of transactions (427 per second)

Files: 299815 created (235 per second) Creation alone: 50000 files (666 per second) Mixed with transactions: 249815 files (213 per second) 249759 read (213 per second) 241688 appended (206 per second) 299815 deleted (235 per second) Deletion alone: 49630 files (1711 per second) Mixed with transactions: 250185 files (213 per second)

Data: 148.30 megabytes read (119.20 kilobytes per second) 178.49 megabytes written (143.47 kilobytes per second)

mkfs.ext3 -O dir_index,has_journal,filetype /dev/mapper/pdc_ffafafdc3 mount /dev/mapper/pdc_ffafafdc3 /mnt/floppy/ -o noatime,data=journal Ext3 B-Tree + noatime,data=journal ========================================================================= Time: 593 seconds total 581 seconds of transactions (860 per second)

Files: 299815 created (505 per second) Creation alone: 50000 files (5555 per second) Mixed with transactions: 249815 files (429 per second) 249759 read (429 per second) 241688 appended (415 per second) 299815 deleted (505 per second) Deletion alone: 49630 files (16543 per second) Mixed with transactions: 250185 files (430 per second)

Data: 148.30 megabytes read (256.08 kilobytes per second) 178.49 megabytes written (308.22 kilobytes per second)

Люди, из всего того, что было обсуждено, можно сделать одно лишь заключение - дело, всё-таки, в судьбе! :) Не в ресетах или отключениях питания, не в типах файловых систем... Кому как повезёт, просто... Поэтому, берите в руки Бакулу (www.bacula.org) и вперёд.

P.S. Сам использую ext3 (/boot, /, /usr, /var, /chroot, /tmp, etc :) - стандартные системные разделы) + reiserfs (3.6) (mail spool, www, sql, squid, и т.п. partitions :)). LVM2.

mkfs.jfs /dev/mapper/pdc_ffafafdc3 mount -o noatime /dev/mapper/pdc_ffafafdc3 /mnt/floppy/ Time: 1155 seconds total 1052 seconds of transactions (475 per second)

Files: 299815 created (259 per second) Creation alone: 50000 files (5555 per second) Mixed with transactions: 249815 files (237 per second) 249759 read (237 per second) 241688 appended (229 per second) 299815 deleted (259 per second) Deletion alone: 49630 files (527 per second) Mixed with transactions: 250185 files (237 per second)

Data: 148.30 megabytes read (131.48 kilobytes per second) 178.49 megabytes written (158.25 kilobytes per second)

mount /dev/mapper/pdc_ffafafdc3 /mnt/floppy/ JFS ========================================================================= Creating files...Done Performing transactions..........Done Deleting files...Done Time: 1216 seconds total 1120 seconds of transactions (446 per second)

Files: 299815 created (246 per second) Creation alone: 50000 files (5000 per second) Mixed with transactions: 249815 files (223 per second) 249759 read (222 per second) 241688 appended (215 per second) 299815 deleted (246 per second) Deletion alone: 49630 files (577 per second) Mixed with transactions: 250185 files (223 per second)

Data: 148.30 megabytes read (124.88 kilobytes per second) 178.49 megabytes written (150.31 kilobytes per second)

mkfs.xfs /dev/mapper/pdc_ffafafdc3 mount /dev/mapper/pdc_ffafafdc3 /mnt/floppy/ Creating files...Done Performing transactions..........Done Deleting files...Done Time: 1137 seconds total 1066 seconds of transactions (469 per second)

Files: 299815 created (263 per second) Creation alone: 50000 files (3846 per second) Mixed with transactions: 249815 files (234 per second) 249759 read (234 per second) 241688 appended (226 per second) 299815 deleted (263 per second) Deletion alone: 49630 files (855 per second) Mixed with transactions: 250185 files (234 per second)

Data: 148.30 megabytes read (133.56 kilobytes per second) 178.49 megabytes written (160.75 kilobytes per second)

Добавлю есче что запускал всё это на совсем не серверной системе:

uname -a Linux localhost 2.6.14-nitro2 #2 PREEMPT Sun Feb 26 04:43:59 MSK 2006 i686 AMD Athlon(tm) XP 2500+ GNU/Linux

Athlon 2500+/1GB MEM/1GB Swap

ОСь стояла на другом разделе. К тому raid массиву на время прогона тестов обращалась только эта прога (postmart или как там её).

Если успею вечером погляжу что покажет ext2, reiser4 и vfat какойнибудь :))

*на другом винте*

Результаты точно таких же тестой буду выкладывать на coredumped.livejournal.com.

> 3) *принципиальный* недостаток у XFS (<skip>) -- обнуление файла, открытого на запись во время внезапного сбоя.

Полностью подтверждаю, я даже баг открывал на эту тему. Эта ошибка была еще в Irix-5.3-XFS

Главное достоинство это - xfs_growfs (xfs на lvm), добавляещь место на лету - не нужно перемонтировать.

>reiserfsck --rebuild-tree /dev/chimera/bbb

не строй из себя девочку... reiserfsck АГрессивно предлагает тебе сделать бекап...если не читаешь то что тебе прога пишет - ССЗБ(виндузятник:))

зы я такие операции некогда не делал, но все кто делал говорят, что всё ОК и данные не теряются

>Простой пример - хорошо растущая база данных, с требованием бесперебойной работы. Подцепить на горячую винт получится. На ходу раздвинуть на него LV - тоже. А вот об отмонтировании раздела речи просто быть не может - работает же.

Забавно у вас в конторе дела обстоят.

>> Не к топику будет сказано, но в моей школе :) вынь95 стоит с тех пор как еще я ее лет пять назад туда поставил - на всех 16-ти компах ...

>Стоит? А у меня оси работают, а не стоят.

гм :)) у мяня ось стоит :)) а с ней работают :))) а то получается "не нада думать, с нами тот кто все за нас решит" :)

>Полностью подтверждаю, я даже баг открывал на эту тему. Эта ошибка была еще в Irix-5.3-XFS

Это не баг, это так было задуманно, хотя по мне это было явно лишним. >В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла. Помимо очевидной потери данных, гипотетически это может иметь более серьезные последствия. В XFS имеется гарантия, что любые "недозаписанные" блоки заполнены нулями. Так как блоки с нулевыми байтами в системных файлах игнорируются, устраняется лазейка в безопасности.

>Главное достоинство это - xfs_growfs (xfs на lvm), добавляещь место на лету - не нужно перемонтировать. XFS умеет только увеличивать раздел, рейзер и увеличивать и уменьшать, причем как с отмонтированием так и без.

Линк насчет 0 в XFS http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs9_ru.html

> гм :)) у мяня ось стоит :)) а с ней работают :))) а то получается "не нада думать, с нами тот кто все за нас решит" :)

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

> Вообще-то, по требованиям RFC, почта __ДОЛЖНА__ (MUST) быть
> гарантированно записана на носитель после ответа о том, что
> произошла доставка.
>
> Поэтому странно видеть __журналируемые__ файловые системы вместо
> файловой системы с __синхронной__ записью.
>
> Оно, понятно, что синхронная запись - это ооооочень медленно, но,
> увы, стандарт есть стандарт.

Ты почитал бы про ФС вообще и что такое журналирование в часности. Нечего тут народ смущать своими "советами".

Почта у него на журналируемую систему не пишется. А то, что Oracle рекомендует именно ext3, тебя не смущает?

Почитай мануалы про системыные вызовы записи в ФС.

>у мяня ось стоит :)) а с ней работают :)))

человек должен думать, а машина работать (Цэ)

>А то очень неприятно сознавать...

комплексы? (-;

> а то получается "не нада думать, с нами тот кто все за нас решит" :)

а указанная строчка Высоцкого очень хорошо подходит к операционным системам. нефиг им думать. всё равно у меня это лучше получится (-:

> Тогда не канает. Простой пример - хорошо растущая база данных,
> с требованием бесперебойной работы. Подцепить на горячую винт
> получится. На ходу раздвинуть на него LV - тоже. А вот об
> отмонтировании раздела речи просто быть не может - работает же.

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

Пример: tablespace (логический уровень), который можно расширять динамически за счёт файлов (физический уровень). И как ты понимаешь,
не важно на каком они диске и в каком разделе. Так что это твой пример не канает.

> комплексы? (-;

Комплексы того же плана, которые возникают, когда тебе публично на улице плюнут в рожу. Свободный от комплексов Muromec утрётся и пойдёт дальше? :)

> человек должен думать, а машина работать (c)

попадалось как принцип IBM

>В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла.

notail спасет отца русской демократии

>Комплексы того же плана, которые возникают, когда тебе публично на улице плюнут в рожу

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

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

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

А чё, в Москве на улице плюнуть не могут? Да запросто. Что, всю жизнь сидеть дома и никого в квартиру не пускать?

> во-вторых, это вопрос скорее из области чести, достоинства и тому подобного.

Именно. Моё достоинство не позволяет мне жить ради железки. Пусть она лучше существует ради меня. Определённые операции по техобслуживанию я проводить согласен. Но не так, чтобы отнимали существенную часть моей жизни.

хех то человек должен думать, то думать уже не работа :)) где истина? :))))

> Линк насчет 0 в XFS http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs9_ru.html

> Однако, после повторного mkfs.xfs и игры с опциями mount, XFS смогла немного "обойти" по скорости ReiserFS

Ы, если поиграть с опциями в рейсерфс при мкфс и маунте (notail,noatime, вынести журнал на другой физический диск, или вообще nolog), то у хфс уже не будет шансов "немного обойти", даже если его тюнить.

Это как в рекламе: "Опустим ТВ-Парк в дистиллированную воду, а газету в соляную кислоту..."

>А чё, в Москве на улице плюнуть не могут? Да запросто

вот вы москали какие... не поеду я в Москву (-;

>Именно. Моё достоинство не позволяет мне жить ради железки. Пусть она лучше существует ради меня. Определённые операции по техобслуживанию я проводить согласен. Но не так, чтобы отнимали существенную часть моей жизни.

LOL! может всё-таки комплексы? "я не живу ради железки, я не живу ради железки, я не живу ради железки..." (-;

> LOL! может всё-таки комплексы? "я не живу ради железки, я не живу ради железки, я не живу ради железки..." (-;

Не. Эту мантру любят повторять гентушники. А мне некогда - другим делом занят. Да и желания нет :)

>человек должен думать, то думать уже не работа :)) где истина? :))))

работать в смысле ящики таскать, почту носить, тексты обрабатывать ( s/б&# ты $%#@!// ). короче, слава роботам!