> А какая журналируема ФС меньше всего процессор "жрет"?

JFS

Человек уже привел тесты на скази

http://oregonstate.edu/~kveton/fs/page2.php

> Угу . Звучит логично . Бороться с этим как-то можно ?

Нельзя. Ибо это не глюк, а фича.

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

Если нет UPS то сидеть на ext3 с data=journal

2
>Видел чудеса тюнинга на Oracle, когда не меняя запрос, только настройкой, повышали производительность на порядки :)
Немного про чудеса тюнинга
http://www.citforum.ru/database/oracle/linux_tuning/
>Может там просто какое-то неудачное совпадение для ReiserFS было, какой-нибудь худший случай :)
В реальной работе с Oracle ReiserFS не самое лучшее решение, процессорные ресурсы - это тоже ресурсы :-)

2Sun-ch (*) (11.05.2004 17:23:21)
При прочих равных условиях (скорость шпинделя, аппаратный кэш диска, скорость передачи данных) SCSI будет работать быстрее из-за особенностей реализации интерфейса.

> >Нули там бывают, если одновременно писать в кучу файлов (на одной ФС), которые рядом лежат ( в B-tree ), и в этот момент...

> Угу . Звучит логично . Бороться с этим как-то можно ?

1) Никак. Это не баг.

2) Выделять для /var, /tmp, /home отдельные разделы, а не валить все до кучи.

На reiserfs недавно словили ошибки (ядро 2.6.5) не фатальные конечно лечилось rebuild-tree, но раздел с данными перенес на XFS - посмотрим что она может. Причем словили разные ошибки на двух тачках одновременно, совпадение, конечно :) Reiserfs с мелкими файлами шустро работает, особенно впечатляет скорость копирования каталога /dev :) Но недавние ошибки напугали сильно, так как на пустом месте после нормального ребута.

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

"косяки на партиции" нужно репортить в reiserfs-dev@namesys.com, например.

noexec и nosuid для долбоебов либо ядро патчить надо.Иначе в морг.

На файлухах в journal=writeback mode (default в reiserfs без патчей и XFS), после unclean shutdown в файлах могут быть не только нули, но всякий мусор, куски других файлов и тп. Догадайся почему.

data=ordered вполне поможет от мусора после ребута.

А, да, только все забывают про write cache почему-то еще.

И чем поможет куча разделов от описанного опведения при journal=writeback? ;)

> data=ordered вполне поможет от мусора после ребута.

Лучше всего backup помогает :) И от мусора после reboot в том числе.

green: А что поможет если файл вдруг нулевого размера орет что-то так access видимо impossible или denied? :) Хотя и так понятно что файла мы уже не увидим, может блоки с ним потерял.

> и /boot нужно монтировать в read-only,

/boot вообще нах не надо монтировать (imho:)

а есть в XFS аналог chattr (ext) ?

Не помогает. Проверено, бекап есть, а мусор все равно появляется. А вот journal=ordered - помогает.

Случай который ты описываешь (если на reiserfs) напоминает запись в каталоке без самого файла на который эта запись должна указывать (куда пропал файл я телепатически сказать не могу, как найти файл - тоже, не глядя на конкретную fs). Потому что тогда тебе и ls скажет что permission denied на него, и размер его (то что он вроде как нулевой по твоим словам) ты увидеть не сможешь.

> 2Cannabinolus (*) (11.05.2004 15:32:00)

>>XFS надёжная ? Ну не знаю .. У меня она теряла данные регулярно и за милую душу ... >>Cannabinolus (*) (11.05.2004 12:53:21)

>>Значит я перепутал и то был рейзер . Очень может быть . >>Cannabinolus (*) (11.05.2004 15:32:00)

>Поздравляю Вас, господин, соврамши :-) Так все-таки, что это было? Может minix? :-)

>anonymous (*) (11.05.2004 15:56:04)

reiser, у мя тож такое было

Да, точно. /boot не монтировать. А /etc/mtab->/proc/mount.

А вот у меня на ext3 в корневом разделе половина файлов обнулилось при пропадании питания. Причем в это время ничего на компе не происходло. Раздел был почти под завязку полон кстати. Это правда что у ext есть свой уборщик мусора, который запускается при низкой загрузке? Иначе трудно объяснить почему такое происходит.

Никакого уборщика мусора в ext3, ясное дело, нету.

>Очень интересно, ext2 практически во всех тестах оказалась быстрее
>всех на Bonnie++
>Только не надо забывать, что у них были 15к шпиндели и крутой скази >рейд контроллер.
>Sun-ch (*) (11.05.2004 17:03:28)

ссаных крутые рейды едят либо FC2 либо ATA, но никак не сказю :)

> А вот у меня на ext3 в корневом разделе половина файлов обнулилось при пропадании питания.

И поделом! Не х.. в корне файло держать!

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

хороший ответ... нефиг трогать компер и тп...

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

Дурилка картонная, а УПС на что изобрели

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

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

2V0ID:

>fsck ее на плотно забитом партишене гиг в 100 займет пару суток

Пару часов и пару суток несколько отличатся:)

Хотя... на пьяную голову можно и спутать час с сутками:)

А ты проверь - и мы выясним, кто из нас пьяный 8)

про куски других файлов

> На файлухах в journal=writeback mode (default в reiserfs без патчей и XFS), после unclean shutdown в файлах могут быть не только нули, но всякий мусор, куски других файлов и тп.

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

P.S.:

Медицинский факт: в случае XFS там чаще всего оказываются именно нули.

> И чем поможет куча разделов от описанного опведения при journal=writeback? ;)

Тем, что похерятся файлы в /var, /tmp, но не в корне или /usr

2V0ID:

>А ты проверь - и мы выясним, кто из нас пьяный 8)

Уже проверяю:

винт 120Г, на нём один раздел /dev/hdd1 105G - ext2, на нём файл, созданный

dd if=/dev/zero of=/mnt/disk/file bs=128M count=832

CPU P4 2GHz, RAM 512M

отмонтирую раздел,

time e2fsck -p /dev/hdd1

результат сообщу позже (если окажусь неправ - признаю свою ошибку:))

помогает _от чего_?

> Проверено, бекап есть, а мусор все равно появляется. А вот journal=ordered - помогает.

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

2) производительность ФС в таком режиме оставляет желать лучшего.

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

экая ерунда. похерятся файлы с которыми велась работа в момент (или прямо перед) креша (в случае с мелкими файлами и reiserfs - даже просто чтение).

Целостность данных не будет обеспечена и при наличии backup, для случая новых файлов ;) Скорость создания бекапа уже ни на что не влияет? ;)

По поводу производительности - ты сравнивал производительность journal=writeback с journal=ordered? Я проверял ;)

>>>Уже проверяю:

Это вобщем-то самый тривиальный случай.(И самый простой для чека)

Имеется ввиду реальная файлопомойка с хорошим фрагом.

Но всё равно, будет любопытно глянуть на результат 8)

вопрсец ...

А какую файлуху выбираеш ты ?

Смотря для чего. Для себя, а так же для всяких важных данных, за которые я в ответе - reiserfs + правильные патчи. И по очень простой причине - если с с файловой системой случится что-то плохое (неважно по какой причине), про reiserfs я знаю намного больше чем про ext3/xfs/whatever и восстановить данные с reiserfs мне будет намного проще.

2V0ID:

>Это вобщем-то самый тривиальный случай.(И самый простой для чека)

Ну так кидай скрипт для создания более-менее реальной файлопомойки - пока есть пустой винт - проверю (самому интересно)...

Я не претендую на абсолютную истину, но проверялась неоднократно ФС на ext2 (правда раздел был поменьше, ок. 20Г, но машина значительно послабее и винт в разы медленнее, так меньше часа всегда "чекалась")

>От того что я баг рейзера перепутал с багой xfs суть дела не меняется : и там и там пропадают данные. Cannabinolus (Score: 109 MaxScore: 114) (*) (11.05.2004 17:19:54)

Ну не знаю, я испытывал пару раз проблемы как с ext3 так и с рейзером, а вот с разделом на xfs (у меня на нём mp3 и фильмы лежат) никаких пока боков не происходило, хоть машина и без упса, и электричество пару раз вырубалось во время прослушивания музыки :)

Гмм... слёту я его не рожу - а ничего готового припомнить не могу ...

> И по очень простой причине - если с с файловой системой случится что-то плохое (неважно по какой причине), про reiserfs я знаю намного больше чем про ext3/xfs/whatever и восстановить данные с reiserfs мне будет намного проще.

А где бы про это прочитать? С ext2 восстанавливал успешно, с ext3 тоже. А вот ReiserFS & XFS это мрак :(

Просьба RTFS не говорить :)

В моем случае это было именно RTFS + два года общения с правильными людьми (во времена когда я работал в NAMESYS).

2green

А чего за пачи ? Поподробней, pls ...

> В моем случае это было именно RTFS + два года общения с правильными людьми (во времена когда я работал в NAMESYS).

Ясно. Будем и дальше данные на ext3 хранить.

ReiserFS зато для /var/spool/squid и /var/spool/news отлично подходит, там файлов много маленьких, а если упадет то не жалко :)

ftp://ftp.suse.com/pub/people/mason/patches/data-logging

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

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