The OpenNET Project / Index page

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



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

Оглавление

Хостинг-оператор Anchor протестировал Btrfs на готовность к ..., opennews (?), 26-Апр-13, (0) [смотреть все]

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


7. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +/
Сообщение от Аноним (-), 27-Апр-13, 00:38 
Почему не используешь EXT4 или NTFS ?))
Ответить | Правка | Наверх | Cообщить модератору

8. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +12 +/
Сообщение от Аноним (-), 27-Апр-13, 01:52 
С чего вы взяли, что он не использует NTFS?
Ответить | Правка | Наверх | Cообщить модератору

17. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –11 +/
Сообщение от iZEN (ok), 27-Апр-13, 08:14 
> Почему не используешь EXT4 или NTFS ?))

EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263
На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516 — журнал нужно обязательно отключать и монтировать в read-only, а то скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей контроллера флешатины).

NTFS успешно использую на корпоративной рабочей станции.


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

19. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +16 +/
Сообщение от www2 (ok), 27-Апр-13, 08:58 
Пруфлинк не прокатит, т.к. не ясно в чём было дело - в глюке оборудования, кривых руках настройщика, убунте или в самом деле в фс. Однако, зная что soko1 - бсдешник, предполагаю что в первую очередь в кривых руках, вторая возможная причина - в оборудовании. То, что чел не попытался разобраться в чём было дело, а сразу пошёл кричать о глючности линукса, кагбэ намекает, чего стоит этот пруфлинк.

Я по собственному опыту знаю, что глючат все файловые системы, особенно если бывают проблемы с оборудованием или электричеством. У меня и UFS2 ломалась (ещё в те времена, когда бсдешники кричали о том что журнал не нужен и есть Soft Updates - чекалось по полтора часа в фоне), и NTFS ломалась, и FAT32 ломалась и ReiserFS ломалась и Ext3 ломалась. Из них, естественно, самая ненадёжная - FAT32. Для ReiserFS практически отсутствуют инструменты для восстановления, когда уж совсем всё поломалось так, что даже fsck не может справиться. Поэтому на винде - NTFS, на Linux - Ext3 или Ext4 (на домашнем компе стоит, на серверах - Ext3). На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти, в итоге скорость записи упала в разы, откатились обратно.

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

78. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +/
Сообщение от Аноним (-), 28-Апр-13, 17:42 
>На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J

Я на DFBSD мигрирую на Hammer, бо после пары факапов UFS доверия уже нет. Хотя Hammer тоже мне сюрприз подкинул - понадеявшись на дефолтные настройки, я прохлопал исчерпание места на диске.:)

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

95. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +2 +/
Сообщение от Andrew Kolchoogin (?), 29-Апр-13, 11:20 
> На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт
> неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти,
> в итоге скорость записи упала в разы, откатились обратно.

"No silver bullet". (C)

Универсальной файловой системы на все случаи жизни нет и не будет. Реализуемые файловой системой свойства -- это всегда результат некоей торговли. И ценность торгуемых свойств очень сильно зависит от парадигмы отношения к хранимым на ФС данным.

Например, если исходить из парадигмы "данные бесценны" (то есть, принципиально никаким способом не восстанавливаемы -- например, являются результатами метеорологических наблюдений), тогда кагбэ чихать на стоимость ОЗУ -- надо 4 гигабайта под кэш для файлухи, значит, поставим. Надо 16 -- поставим 16. В этой парадигме разговорчики а-ля "ну, вероятность потери данных при сбое равна ... " считаются оппортунизмом. :)

Если же таких требований к данным не предъявляется, можно и не использовать ZFS. При наличии процедуры регулярного резервного копирования плевать с балкона, какая ФС. :) Ну, потратится время на восстановление с бэкапа, да... Ну, что-то там потеряется, что в промежутке между бэкапами было...

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

119. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +1 +/
Сообщение от AlexAT (ok), 29-Апр-13, 20:23 
> Например, если исходить из парадигмы "данные бесценны"

То начинать надо не с ZFS, да и заканчивать не ей. Репликация и только репликация, + контроль ошибок на всех уровнях _до_ диска.

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

144. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +/
Сообщение от Аноним (-), 30-Апр-13, 16:15 
>> Например, если исходить из парадигмы "данные бесценны"
> То начинать надо не с ZFS, да и заканчивать не ей. Репликация
> и только репликация, + контроль ошибок на всех уровнях _до_ диска.

Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности и оверхеду?

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

151. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +1 +/
Сообщение от ананим (?), 30-Апр-13, 17:43 
Вот куда-куда, а под rdbms (и oltp, и dss) кладут zfs только полные дауны.
Ответить | Правка | Наверх | Cообщить модератору

152. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +1 +/
Сообщение от AlexAT (ok), 30-Апр-13, 18:07 
> Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах
> OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности
> и оверхеду?

Выше правильно ответили - положить ZFS да и вообще CoW под RDBMS может только конченый идиот. Потому что параметр latency будет совершенно непредсказуемым.

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

22. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +4 +/
Сообщение от AlexAT (ok), 27-Апр-13, 10:32 
Маргиналы такие маргиналы.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

41. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –1 +/
Сообщение от nagualemail (ok), 27-Апр-13, 17:34 
>> Почему не используешь EXT4 или NTFS ?))
> EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да
> и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263
> На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516
> — журнал нужно обязательно отключать и монтировать в read-only, а то
> скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают
> при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей
> контроллера флешатины).
> NTFS успешно использую на корпоративной рабочей станции.

NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :)))

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

46. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +1 +/
Сообщение от Аноним (-), 27-Апр-13, 18:32 
> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :)))

"Фрибздшники" палятся.

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

49. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –1 +/
Сообщение от Карбофос (ok), 27-Апр-13, 19:35 
ой! если бы там дело в дефрагментации было...
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

79. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –3 +/
Сообщение от Аноним (-), 28-Апр-13, 17:44 
> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ...
> :)))

Слишком толсто.

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

98. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –1 +/
Сообщение от nagualemail (ok), 29-Апр-13, 11:46 
>> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ...
>> :)))
> Слишком толсто.

Это не шутка, если не делать дефрагментацию то тормоза можно почуствовать уже через неделю :))

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

99. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  –1 +/
Сообщение от Аноним (-), 29-Апр-13, 12:42 
Мне трудно представить, что надо делать с томом, чтобы производительность деградировала так сильно и так быстро.
Ответить | Правка | Наверх | Cообщить модератору

145. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."  +/
Сообщение от Аноним (-), 30-Апр-13, 16:15 
> Мне трудно представить, что надо делать с томом, чтобы производительность деградировала
> так сильно и так быстро.

CoW?

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

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

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




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

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