The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Сравнение производительности файловый систем на пр..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"OpenNews: Сравнение производительности файловый систем на пр..."  
Сообщение от opennews on 21-Апр-08, 09:58 
Sander Marechal неудовлетворенный производительностью аппаратного RAID контроллера 3ware 9550XSU (не fake-raid, нормальный SATA RAID ценовой категории около 300$) провел серию измерений производительности (http://www.jejik.com/articles/2008/04/benchmarking_linux_fil.../) файловых систем XFS, Ext3, ReiserFS и JFS.


Изначально была поставлена задача сравнения производительности программного и аппаратного RAID, но в процессе работы с 3ware 9550XSU обнаружились крайне низкая производительность на операциях записи данных при отключенном режиме "write cache" (на карте не был установлен BBU), что в конце-концов привело к переходу на программный RAID (mdadm), который также лишен необходимости использования при замене сбойных дисков только накопителей идентичного объема.


Вместо использования тестовых комплектов Bonnie++ (http://www.coker.com.au/bonnie++/) и IOzone (http://www.iozone.org/), было решено создать свой набор тестов, основанных на эмуляции выполнения та...

URL: http://www.jejik.com/articles/2008/04/benchmarking_linux_fil.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=15425

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Сравнение производительности файловый систем на программном ..."  
Сообщение от shadowcaster on 21-Апр-08, 09:58 
Автор статьи абсолютно некорректно понял рекомендации 3ware. Платы 3ware, как асболютно адекватные raidы, отключают встроенный кэш дисков, которые к ним подключены. Это обеспечивает сохранность данных и снижает скорость при отключении write cache. При наличие BBU (battery backup unit) это _гарантирует_ сохранность данных. Но, если BBU нет, можно включать write  cache. Сохранность данных будет не хуже, чем на обычных отдельностоящих дисках - они все с кешем 8-16мб, и, как все догадались, этот кеш не скидывается на винт при потере питания :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Антон (??) on 21-Апр-08, 10:09 
А разве Linux периодчески не дергает диски на предмет принудительного сброса кэша ? По идее целостность с обычным диском должна быть выше, так как опреционка знает когда лучше сбросить кэш на диск, чтобы минимизировать возможные повреждения или хотябы узнать потом об их наличии, иначе после каждого отрубания питания всречались бы целостные с точки зрения ОС файлы с недописанными данными.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Sabitov on 21-Апр-08, 10:23 
Ну, во-первых ОСь озадачена производительностью, а не целостностью. Иначе бы она писала на диск без всяких буферов байт за байтом. И была бы супер надежность :) А во-вторых, на своем нотере (gentoo+xfs) я получал несколько раз ситуацию, когда с точки зрения XFS все нормально, а emerge отказывается работать, т.к. его служебные файлы покорёжены. А получается это в ходе апдейта на одной батарее. Батарея кончается, нотер умирает, и происходит это, как правило, когда система диску крутит...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Serge Matveev email on 21-Апр-08, 10:48 
А потому что "всё нормально" с точки зрения XFS может означать "последние открытые на запись файлы забиты нулями". И мало того, это фича, которую собирались сделать отключаемой.

Так что люди, использующие XFS без UPS не должны волноваться за сохранность своих данных ;-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Сравнение производительности файловый систем на программном ..."  
Сообщение от ледо on 21-Апр-08, 14:19 
Очнись. Эту проблему уже пофиксили года 2 назад.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Serge Matveev email on 21-Апр-08, 14:30 
>Очнись. Эту проблему уже пофиксили года 2 назад.

Версию ядра можно услышать?


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Evgeniy (??) on 22-Апр-08, 11:54 
В какой версии ядра ?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "вот уж тут xfs ни при чём"  
Сообщение от Michael Shigorin email(ok) on 21-Апр-08, 13:07 
Ринат(?), ну так ноутбук, xfs, генту, сборка и конец заряда -- в сумме называется "ССЗБ".

Не делайте emerge на батарейке.  Или хоть собирайте на reiserfs, её и mkfs'нуть недолго при развале дерева.  Если уж так хочется грызть именно эту морковку.

XFS == UPS.  И _прекрасно_ работает при выполнении этого условия. (конец батарейки != UPS ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Michael Shigorin email(ok) on 21-Апр-08, 13:02 
Это про write barriers и вроде как ещё не шибко расползлось по разным fs.  В частности, когда народ радостно ринулся заюзать фичу в xfs -- полетели репорты о диких тормозах.  Деталей не помню, но на практике PC+SATA+Linux+XFS работало не совсем так, как SGI+SCSI+IRIX+XFS. :)

Дровишки наверняка устарели, но "jfyi".

На месте неудовлетворённого автора озадачился бы экспериментом в 3ware+writeback и при желании -- сопоставлением разваливабельности рейда при тестовых нештатных выключениях такого варианта и md raid1.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Сравнение производительности файловый систем на программном ..."  
Сообщение от shadowcaster on 21-Апр-08, 16:02 
"Переодичски дергает" и "минимизировать" != "отключает cache" и "гарантирует". Поверьте, контроллер 3ware тоже данные в кеше не хранит 2 дня.  :) BBU нужен исключительно для аварийных ситуаций (потеря питания) для _гарантированной_ сохранности целостности данных.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Сравнение производительности файловый систем на программном ..."  
Сообщение от szh (ok) on 21-Апр-08, 16:38 
grep -A1  -i barr /usr/src/linux/Documentation/filesystems/ext3.txt

grep -A3 "enable barriers by default" /usr/src/linux/fs/ext3/super.c

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Аноним (??) on 21-Апр-08, 16:36 
XFS с UPS рулит, что и требовалось доказать. Жаль только, что автор noatime не включил, дурень.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Сравнение производительности файловый систем на программном ..."  
Сообщение от Аноним (??) on 21-Апр-08, 17:56 
Не верю!(С)
У автора классический ФГ^W "Горе от ума". Зачем отключать wb-cache на __контроллере__? Тогда уж и для софт рэйда sync-режим! Но в чём глубокий смысл ???
И JFS слишком уж подозрительно сливает. У меня на всех нагрузках, какие только нашёл - если не лучшая, то вполне перпимая - а туууууут ....
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Сравнение производительности файловый систем на программном ..."  
Сообщение от fresco (??) on 23-Апр-08, 13:02 
Зря не верите. JFS у мну тоже сливала, причем как-то не логично -- т.е. именно там, где должна была, судя по дизайну, вести.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру