The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Сравнение производительности файловый систем на программном RAID1 в Linux, opennews (?), 21-Апр-08, (0) [смотреть все]

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

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

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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