Спасибо.

В некоторых случаях люди предпочитают скорость. Про XFS не скажу, а решение (возможность выбора режима журналирования) пользователем для reiserfs уже реализована. Патчи раздают по тому url который я привел пару сообщений назад

>>>>Ext2 - самая быстрая, поэтому её и использую....

>fsck ее на плотно забитом партишене гиг в 100 займет пару суток - проклянешь ее уже через пару часов 8)

У меня есть реальная партиция на 115G под ext2. Занято 113G, файлопомойка. Если мне не изменяет склероз, то fsck шёл меньше часа. То, что меньше двух часов -- точно.

Странно...

Не так давно (где-то год тому), я переделывал буржуям сайт (web-hosting) 4x главый ксеон + 2гига рама + SCSI raid на винтах 20000 RPM. Партиции там были нарезаны примерно по 120гиг. Дык вот - основная жалоба была на тормознутость чека (стояла ext2fs). Он мог больше суток заниматься сим благородным занятием, хотя скорость сброса на файловую систему (не на голый диск) была больше 100мб/сек. (Я уж не говорю о чтении).

Вот такие пироги...

Мне с трудом верится, что за этот год прогресс в области ext2 ушел так далеко, скорей всего под файлопомойкой подразумевается сотня-другая авишек...

20000 RPM

20000 RPM....

гм гм ... Дорогая вещь, надо полагать на заказ делали?

>reiserfs + правильные патчи.

список правильных патчей в студию ;)

BTW: на x86 я вот тоже выбираю reiserfs а вот на x86_64 - jfs ;)

>Но как может потеря файлов не быть багой, это что, нельзя исправить и разработчики идут на это ради повышения производительности??? Почему например с той же NTFS такого не происходит. На ней даже был случай, когда во время дифрагментации комп вырубался, когда свет врубали, опять дифргментация и опять свет вырубали и так 3 раза, и ничего с данными не было... В чём тут дело, спасибо за ответы...

В везении ;)

У меня коллега прошлым летом 2 раза XP переставлял с нуля - рядом велся ремонт и автоматы от кучи строительной техники вылетали по 2 раза в час ... упсы с некритичных компов специально поставили на сервера по паре штук на каждый ... видимо не зря ;)

20000RPM Угу - Seagate (и по моему IBM) в свое время вылезли на рынок с подобными дэвайсами 34/76 гиг - но также быстро бросили их производство - слишком дорого и хлопотно оказалось ...

> То есть случай когда свободные блоки заполнены не нулями ты начисто
> игнорируешь?
XFS маркирует экстенты при их выделении. deferred zeroing произойдёт, когда кто-то попытается замапить (vop_bmap) этот экстент для чтения.
Поэтому совершенно неважно, игнорировал предыдущий анонимус этот случай, или нет :)

Re: Re: Производительность файловых систем

nihrena ne vidno na kartinkah dazhe chitat ne stal

> Почему например с той же NTFS такого не происходит. На ней даже был случай, когда во время дифрагментации комп вырубался, когда свет врубали, опять дифргментация и опять свет вырубали и так 3 раза, и ничего с данными не было

с НТФС такого не происходит потому что это глючная поделка поганого мелкософта, который загнется уже через год максимум(ибо линукс рулит со страшной силой везде и всюду)... хотя с 1 годом это чето то я загнул :) ладно, тогда через 2 года МСу конец... стоп, че то опять сам себе не поверил :) ну хорошо, лет 20 на это уйдет, но Билли все равно проиграет :) НТФС это неправильно - это НЕ ЛИНУКС ВЕЙ!!! ну что с того, что иногда файлы теряются или портятся на рейзере, подумаешь важность какая... не придирайся по мелочам! зато ты юзаешь ПРАВИЛЬНУЮ ФС сделанную мега профессионалами с прямыми руками и правильной идеологией... а НТФС... ну ее нах, она же кривая от первого до последнего метафайла :)

Злой я вчера был, картинок насмотрелся, прошу простить.

>Читать умеешь? If the images are hard to read on your screen, >here's a tarball containing larger versions of them. >Короче тебе сюда: ...

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

>Если кого-то и убивать, то только тех, кто кричит не разобравшись.

Читать-то я, конечно, умею, но вот скажи мне, пожалуйста, это статья или preview к статье? Если preview, тогда я могу стерпеть, а вот если статья, то почему нельзя было сделать картинки в lossless формате?

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

Блин, но согласитесь, что на NTFS теряются данные много реже чем на остальных FS которые есть в Linux. Это почему так, что действительно разработчики больше упирают на скорость, чем на надёжность???

>Блин, но согласитесь, что на NTFS теряются данные много реже чем на остальных FS которые есть в Linux.

нет бога кроме аллаха.

to eliterr >Читать-то я, конечно, умею, но вот скажи мне, пожалуйста, это статья >или preview к статье? Если preview, тогда я могу стерпеть, а вот если >статья, то почему нельзя было сделать картинки в lossless формате?

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

кстати, с Reiser4 кто-то дело имел?

А у нас помимо vop_bmap еще и read(2) есть, вообще-то ;)

2anonymous:

>Почему например с той же NTFS такого не происходит.

Повезло, значит:)

Монтируй с sync будет надёжнее. ИМХО дефрагментация в NTFS именно так и делает: сбрасывает кэш перед обновлением метаданных

c Reiser-4 не совсем понятна ситуация - завис он похоже.

не проверял сколько занимает времени проверка ext2, но создание fs на разделе в 1.5Tb занимает 3 часа, у xfs пару секунд.

2V0ID:

Обещанные результаты "моего теста":

7.28user 5.68system 4:00.33elapsed 5%CPU

(это на ext2 c одним файлом 104G)

так броисишь скриптик для создания "файлопомойки"?

или хоть критерии для создания через rnd() (диапазон размеров файлов, вложенности каталогов, количесва файлов в каталоге)? Может по свободе сам что-то набросаю

2borisych:

>но создание fs на разделе в 1.5Tb занимает 3 часа

# time mke2fs /dev/hdd1 mke2fs 1.35 (28-Feb-2004) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 14663680 inodes, 29305198 blocks 1465259 blocks (5.00%) reserved for the super user First data block=0 895 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. 0.18user 6.00system 1:04.29elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (188major+1389minor)pagefaults 0swaps

Итого: 112G за 1 минуту 4 секунды У Вас 3 часа на разделе большем в 15 раз? забавная арифметика:)

Гм..Насколько я помню вышеописанный случай - было следущее:

Глубина от корня 5-6 (в корне было примерно полторы штуки дир)

файлов в каталоге нижнего уровня 50-500 (выше не помню)

Размер файлов 0-100к байт

Вопрос в том как создать хорошую фрагментацию на диске. Простого и элегантного решения я не вижу. Удалять и создавать по новой - будет долго...

Про больше суток

>raid на винтах 20000 RPM. Партиции там были нарезаны примерно по 120гиг. Он мог больше суток заниматься сим благородным занятием.

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

> А еще нужно выделять для /tmp и прочего. / и /boot нужно монтировать в read-only, а для /var, /tmp и прочего /mnt ставить noexec и nosuid. Это помогает при сбоях и повышает безопасность.

noexec в плане безопасности -- что мёртвому припарки

2green: где щас работаешь (или хоть область работы примерно какая)? Давно из namesys "того"? Сорри за оффтопик.. ЗЫ: green, как разработчика reiserfs спрашиваю, а в каком из дистро линукса используемый набор патчей "самый правильный"? А в каком "самый неправильный" (типа слака, наверно?)?

Из NAMESYS "того" 30го сентября 2003го года.Работаю в той же области, только в Таврическом Национальном Университете ;)

Самый правильный набор reiserfs патчей приложен к ядрам у SuSE, как не сложно догадаться. Знаю что у RH и Slackware никаких reiserfs патчей не приложено вообще (у RH reiserfs вообще считается неподдерживаемой файловой системой), у Debian вроде бы тоже никаких патчей нету.

Впрочем все эти правильные патчи сейчас активно пошли в 2.6 (в текущем 2.6 bk уже вроде как они все, ну или почти все есть)

>Знаю что у RH и Slackware никаких reiserfs патчей не приложено вообще

И чё? Типа может быть сурпрайз?

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

Я -- нет, я вроде как и пытался привести пример, когда блок, принадлежавший ранее одному файлу, попадет в другой, а вот XFS, похоже, игнорирует :)

> А у нас помимо vop_bmap еще и read(2) есть, вообще-то ;)
Для тех, кто в танке. Прочитай, для чего xfs_bmap используется, и открой для себя удивительный мир Unix, который, как известно, НЕ LINUX :)

Подсказка: bmap имеет непосредственное отношение к read(2)/write(2)/mmap(2) etc.

Не-а. Все строго в пределах ожидаемого. writeback journal mode, no quota, no EA/xattr support...

Что-то по прочтению сырцов от XFS у меня сложилось впечатление что unwritten extent - это нечто сродни unallocated extents в reiser4, то есть за ними не стоит никаких реальных дисковых блоков. В таком случае не нужно парить мне мозги, это не тот случай про который я говорю.

Рассматриваемый случай заключается в следующем (и имеет место быть только в случае journal=writeback): У нас есть некий файл, в этот некий файл мы пишем (в ранее неаллоцировнную область, будь то дырка или просто append), данные в памяти, пришло время записи на диск. Происходит выделение блоков (прямо сейчас как в случае с xfs или некоторое время назад, как в случае с reiserfs), затем метаданные пишутся на диск (с этими самыми уже выделенными блоками), а затем все падает и данные на диск уже не попадают, в результате имеем ситуацию с файлом, часть содержимого которого - то что раньше было в выделенных для него на диске блоках.

(Да, если сначала писать данные, а потом метаданные к ним относящиеся, то такая проблема не возникнет, однако такой режим называется journal=ordered и ни XFS ни reiserfs без специальных патчей так не умеют).

А ваш "удивительный" мир юникс я не могу открыть, потому как cырцов нету ;)

А типа скази сто лет умеют tagged queueing, SCB транзакции ?

Ну именно TQ scsi вроде как достаточно давно умеют, но связи с рассматриваемым вопросом я не вижу.

Контроллер не запишет метаданные до завершения

транзакции с данными.

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

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

green:

reiserfs: using ordered data mode Reiserfs journal params: device hdd1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 reiserfs: checking transaction log (hdd1) for (hdd1) Using r5 hash to sort names

Однако ошибки я поимел несмотря ни на какой ordered data mode.

IDE. WriteCache on и powerloss ? так чего ж вы хотели? Берите правильные патчи для ide cache flush или как оно там называлось-то, или writecache выключайте.

лучшая файловая система - система без файлов :) вернее база данных с таблицами

В чем различие от файловой системы наподобие ext2? Там тоже таблицы ;) Тоже база данных, можно сказать, индексы всякие... ;)

Лучшая рыба - это колбаса

> лучшая файловая система - система без файлов :) вернее база данных с таблицами

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

как так — не возникает?

> Да, если сначала писать данные, а потом метаданные к ним относящиеся, то такая проблема не возникнет,

Объясните пожалуйста, какая разница -- потеряются ли как данные, так и метаданные, либо только данные?

Все равно данные (скорее всего) будут в противоречивом состоянии (с точки зрения приложения, писАвшего в файл)...

Непротиворечивость данных это другая проблема.

Разница же очень простая. Либо мы видим какие-то более-менее валидные данные которые когда-то в этом файле жили, либо мы видим те же данные, плюс после них еще несколько блоков мусора, например. Причем совершенно произвольного (например старую копию /etc/shadow ;) )

> Непротиворечивость данных это другая проблема.

У меня сложилось впечатление, что именно эта проблема и обсуждается.

> Либо мы видим какие-то более-менее валидные данные которые когда-то в этом файле жили

Нет, мы видим данные, которые когда-то жили в этом файле. Про их непротиворечивость ничего не известно.

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

И какая разница, как именно испорчены данные -- то ли тем, что не хватает нескольких блоков, то ли тем, что в этих блоках мусор?