| |
| |
| 3.13, BratSinot (?), 21:03, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –13 +/– |
> XFS рекомендуется для создания хранилища
> Btrfs для корневой ФС
Вы точно читать умеете? Хранилище, это там где положили и хранят. Корень, это там, где постоянно что-то меняется.
| | |
| |
| |
| 5.25, Аноним (-), 21:28, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –8 +/– |
> Если корень это там, где что-то постоянно меняется, то расскажи как нам
> милок, что есть /var?
Так тенденция же идет к тому, что не будет ни каких тебе /var /usr и пр., будет только /. И линуксовые же админы с пеной у рта всем доказывают что все в / - это хорошо.
| | |
| |
| 6.40, ананим (?), 22:19, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +4 +/– |
это называется — объяснение прописных истин.
корень (/) — это такое место, где хранятся файлы и каталоги, доступные по записи только привилегированным пользователям (как правило root), а также где содержаться точки монтирования других фс.
к последним относятся и tmpfs(shm/…) с точками монтирования в /run, /var/tmp, /tmp и тд
это понятно? не?
root НЕ доступен для записи кем попало (включая сабж) и не расшаривается как ресурс различными сервисами.
усвойте это.
чтобы понятнее уж совсем — рут это такой ц:\\видавс, который доступен для записи только админам.
| | |
| |
| 7.52, pavlinux (ok), 23:03, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –6 +/– |
$ testparm
[SHARA]
path = /
read only = No
force directory mode = 1777
use sendfile = Yes
write cache size = 8192
case sensitive = Yes
strict locking = Yes
# cat /etc/exports
/ master(rw) trusty(rw,no_root_squash)
| | |
|
|
|
|
|
| |
| |
| |
| 5.53, iZEN (ok), 23:04, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
 > Только так и не видно его, продакшна этого, вот в чём соль.
Лиц пубертатного возраста к продакшену не допускают.
| | |
| |
| 6.54, AlexAT (ok), 23:07, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
 >> Только так и не видно его, продакшна этого, вот в чём соль.
> Лиц пубертатного возраста к продакшену не допускают.
Видимо да, в этом и причина...
| | |
|
| |
| 6.142, Аноним (-), 00:07, 16/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
> у вас странный продакшен :-) Только не надо отмазываться рассказывая про университеты..
Не, ну что вы, как можно! Продакшн - это изен, у которого пул из 3 дисков 18Мб/сек выжимает.
| | |
|
|
|
|
| |
| 3.98, Аноним (-), 14:22, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
>> Готова к продакшену, да? Поздравлямс сусю.
> Оракл сперва поздравь.
zfs не crc32 использует. А вполне себе SHA-256, чтоб ты знал. Где-где тама коллизии, гришь?
| | |
| |
| 4.99, AlexAT (ok), 14:32, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
> zfs не crc32 использует. А вполне себе SHA-256, чтоб ты знал. Где-где
> тама коллизии, гришь?
SHA256, говоришь? Как там с загрузкой CPU при создании 100500 файлов в каталоге?
| | |
| |
| 5.113, Аноним (-), 17:43, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> SHA256, говоришь? Как там с загрузкой CPU при создании 100500 файлов в каталоге?
По-моему эти ламерюги элементарно перепутали хэши которые внутренняя функция хэш-таблицы с хэшами которые в роли чексуммы выступают. Бывает же такое ламерсто, а?! И смех и грех :). С одной стороны это не тред а просто перепись ламеров опеннета, эпически палящихся на непонимании того что есть хэш-таблица и как это работает. С другой - печально что на планете столько тупиц несущих с умным видом абсолютную чепуху.
| | |
| |
| 6.114, AlexAT (ok), 17:46, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> По-моему эти ламерюги элементарно перепутали хэши которые внутренняя функция хэш-таблицы
> с хэшами которые в роли чексуммы выступают. Бывает же такое ламерсто,
> а?! И смех и грех :). С одной стороны это не
> тред а просто перепись ламеров опеннета, эпически палящихся на непонимании того
> что есть хэш-таблица и как это работает. С другой - печально
> что на планете столько тупиц несущих с умным видом абсолютную чепуху.
Он пониже спалился, угу.
checksum=on | off | fletcher2,| fletcher4 | sha256
| | |
| |
| 7.120, iZEN (ok), 18:30, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
>> По-моему эти ламерюги элементарно перепутали хэши которые внутренняя функция хэш-таблицы
>> с хэшами которые в роли чексуммы выступают. Бывает же такое ламерсто,
>> а?! И смех и грех :). С одной стороны это не
>> тред а просто перепись ламеров опеннета, эпически палящихся на непонимании того
>> что есть хэш-таблица и как это работает. С другой - печально
>> что на планете столько тупиц несущих с умным видом абсолютную чепуху.
> Он пониже спалился, угу.
> checksum=on | off | fletcher2,| fletcher4 | sha256
Уймись уже. Контрольная сумма — частный случай хэширования.
| | |
|
|
|
| 4.100, filosofem (ok), 14:38, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +2 +/– |
 >>> Готова к продакшену, да? Поздравлямс сусю.
>> Оракл сперва поздравь.
>zfs не crc32 использует. А вполне себе SHA-256, чтоб ты знал. Где-где тама коллизии, гришь?
У тебя zfs межушного ганглия. Не офтопь, тут не про этот чудопепелац новость. Ей пользуются полтора землекопа в продакшне, да и досит она себя сама без посторонней помощи.
http://www.oracle.com/us/corporate/press/1555025
March 13, 2012
The Btrfs file system is now production-ready with this release. Standard in Oracle Linux, Btrfs supports data stores of up to 16 exabyte, is optimized for solid state disks, is easy to administer, and includes built-in data integrity.
| | |
| |
| 5.102, iZEN (ok), 15:00, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
>[оверквотинг удален]
>>zfs не crc32 использует. А вполне себе SHA-256, чтоб ты знал. Где-где тама коллизии, гришь?
> У тебя zfs межушного ганглия. Не офтопь, тут не про этот чудопепелац
> новость. Ей пользуются полтора землекопа в продакшне, да и досит она
> себя сама без посторонней помощи.
> http://www.oracle.com/us/corporate/press/1555025
> March 13, 2012
> The Btrfs file system is now production-ready with this release. Standard in
> Oracle Linux, Btrfs supports data stores of up to 16 exabyte,
> is optimized for solid state disks, is easy to administer, and
> includes built-in data integrity.
Btrfs не сертифицирована для продакшена баз данных.
http://www.spinics.net/lists/linux-btrfs/msg19006.html
| | |
| |
| 6.133, Аноним (-), 19:39, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
> Btrfs не сертифицирована для продакшена баз данных.
А где был сертифицирован ZFS в бсд? Ну или даже в лине? Ах, нигде? Ну я так и подумал.
Хотя ты конечно в твоем праве покупать у оракля соляру на их конских условиях для их БД, если тебе сертификация так свербит. Иные сертифицированные конфиги тебе имхо не понравятся, т.к. там нет ZFS но есть Linux :)
| | |
|
|
| 4.101, iZEN (ok), 14:57, 14/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –1 +/– |
>>> Готова к продакшену, да? Поздравлямс сусю.
>> Оракл сперва поздравь.
> zfs не crc32 использует. А вполне себе SHA-256, чтоб ты знал.
Только в особых случаях — http://www.freebsd.org/cgi/man.cgi?query=zfs&apropos=0&sektion=0&manpath=Free
checksum=on | off | fletcher2,| fletcher4 | sha256
Controls the checksum used to verify data integrity. The default
value is on, which automatically selects an appropriate algorithm
(currently, fletcher4, but this may change in future releases). The
value off disables integrity checking on user data. Disabling
checksums is NOT a recommended practice.
Changing this property affects only newly-written data.
| | |
| |
| 5.111, Аноним (-), 17:40, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –1 +/– | |
Вы что, настолько дятлы что не отличаете хэши используемые как внутренняя функция хэш-таблиц от хэшей использыемых для проверки чексум? Пиндец. Откуда такие ламаки берутся? Не знают чем одно от другого отличается, зато поумничать уже вылезли.
Ну-ка раскалывайтесь, бастарды, сколько из вас представляет как сделана хэш-таблица? И сколько из вас видело SHA-256 в виде функции для хэш-таблиц. Ну? :)
| | |
| |
| 6.112, AlexAT (ok), 17:41, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
> Вы что, настолько дятлы что не отличаете хэши используемые как внутренняя функция
> хэш-таблиц от хэшей использыемых для проверки чексум? Пиндец. Откуда такие ламаки
> берутся? Не знают чем одно от другого отличается, зато поумничать уже
> вылезли.
> Ну-ка раскалывайтесь, бастарды, сколько из вас представляет как сделана хэш-таблица? И
> сколько из вас видело SHA-256 в виде функции для хэш-таблиц. Ну?
> :)
В теории хэш-таблица легко может строиться и деревом на основе SHA-256, почему нет?
На практике сие могут сделать только идиоты.
Еще раз перечитал пост изена выше - ни хрена это не хеш-таблица, это чексуммирование данных.
| | |
|
|
|
|
| 2.56, Аноним (-), 23:25, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +5 +/– | |
> Поздравлямс сусю.
Разработчики суси уже надоели. Всё время совершают какие-то ошибки. То ли дело разработчики убунты - никогда их не совершают! Ещё ни разу не было новости о том, что разработчики ядра из Canonical объявили свою разработку готовой к использованию, а через неделю появляется новость о критичном баге в нём!
| | |
| |
| |
| 4.81, canonical (?), 07:10, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>разработчики ядра из Canonical
>Таких не существует в природе!
https://www.opennet.ru/opennews/art.shtml?num=35240
commit 2000afe4fb86c374650371f41eb287746790d9ff
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date: Mon Aug 27 20:56:52 2012 -0300
floppy: do put_disk on current dr if blk_init_queue fails
commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.
>Толсто!
а с этим согласен.
| | |
|
|
| |
| 3.149, Аноним (-), 01:01, 16/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> ребят то что не готово к продакшену досить даже не пытаются...
А в коментах в бложике упоминается что в OpenBSD (!!) с использованием похожей тактики успешно задосилась файловая система используемая по умолчанию. Там граждане развлекаются с попытками подгадить кэшу имен, чтоли. Ща мы узнаем много нового :)
| | |
|
|
| |
| 2.10, Аноним (-), 21:01, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +5 +/– | |
Ооо, btrfs-у выпала честь от более-менее оригинально мыслящего перца потыкать в него палочкой и обнаружить неординарные возможности.
Заметьте, все остальные просто не попали под его внимание. Это не значит что там всенепременно нет проблем. Это значит что их пока никто палочкой не тыкал.
| | |
| |
| 3.37, all_glory_to_the_hypnotoad (ok), 22:03, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
 атаки на хэши давно известны, их часто используют (вспоминаем, например, недавние атаки на питоны и некоторые веб сервера). Так что сам факт хэширования по crc32 кричит всякой школоте и просто скучающим людям - поимей меня!
> Заметьте, все остальные просто не попали под его внимание. Это не значит что там всенепременно нет проблем.
в остальных фс обычно используют менее тривиальное хэширование и деревья, саксес подобного DoSа будет ниже или вообще невозможен.
| | |
| |
| |
| 5.104, linux must _RIP_ (?), 16:24, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –1 +/– |
> Радуют меня такие индивиды - мешают в кучу все подряд. Указанное поведение
> - проблема именно хэш-таблиц. При чем тут деревья вообще? Это иные
> структуры с иными свойствами. Потенциально деревья кстати не лучше хэш-таблиц. Для
> дерева O(log(N)) а для таблиц O(1). Вот только как оказалось, можно
> спровоцировать ситуацию когда O(1) скорее станет похоже на O(N) :)
для хэш таблиц никогда не бывает O(1), именно из-за колизий. Не позорьтесь.
И вопрос был не о O(N), там явно что-то другое сыграло :-)
| | |
| |
| 6.117, Аноним (-), 17:59, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> для хэш таблиц никогда не бывает O(1), именно из-за колизий. Не позорьтесь.
Вообще-то нормальным сценарием эксплуатации хэш-таблицы является случай когда коллизий нет или мало. Поэтому при нормальном юзеже получается именно O(1), за что их и любят, собственно. Если коллизий слишком много, значит дуболом который юзал хэш-таблицу выбрал слишком которкий хэш для используемого размера таблицы. Какгбэ это в общем случае считается FAIL-ом в использовании данной технологии :)
> И вопрос был не о O(N), там явно что-то другое сыграло :-)
В конкретно этом случае возмжно алгоритм вообще локапнулся где-то. Ибо 220 минут - как-то шибко уж дофига.
| | |
|
| 5.134, nuclight (??), 19:49, 14/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –2 +/– |
 Эксперт 294 уровня как всегда газифицировал лужу, побыв для части сведений кэпом, а в остальной облажавшись. Эти вещи на втором курсе дают, есличо. И распределение (равномерность) значений хэш-функции учат смотреть, так что "похожесть на O(N)" для не забивавших не "как оказалось", а давно известное понятие. И что такое контрольные суммы, и что CRC предназначена для поиска и исправления ошибок в канале связи (а не для хеширования), тоже учат.
И да, деревья тоже дают. Ты мог бы уже включить моск и подумать, почему проектировщики файловых систем обычно выбирают деревья, а не хэши.
| | |
| |
| |
| 7.160, arisu (ok), 21:59, 20/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 > Ориентируясь на скорость в среднем, а не worst case (о чем
> обычно честно предупреждают). CRC32, очевидно, является хэш-функцией, сжимая все множество
> входных значений до 32 битов (или сколько там у кого).
ага, а костыли — это такие ноги, только альтернативные и экономичные. но марафоны на костылях почему-то не бегают.
вообще-то в *нормальном* учебном заведении когда говорят про хэш-таблицы, рассказывают и про uniform distribution, и про avalanche, и — в том числе — почему люди, использующие crc32 в качестве хэш-функции для хэш-таблиц — форменные идиоты.
> Ниоткуда не следует что ее нельзя юзать как функцию хэш-таблицы.
следует, причём напрямую: из изучения её свойств.
не надо больше про хэши в этом контексте, ок? а то позоришься не хуже изи.
| | |
|
|
|
|
|
| 2.11, SubGun (ok), 21:03, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
 Никто не говорил, что все идеально. Уверен, подобную "фишку" можно было бы со всеми существующими ФС сотворить, и не одна не была бы идеальной.
| | |
| |
| 3.15, Аноним (-), 21:06, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> со всеми существующими ФС сотворить,
Насчет всех - это смотреть надо. Зависит от юзаемых алгоритмов.
Потенциально же такая проблема с теми или иными последствиями может быть вообще везде где есть хэш-таблицы. Где-то это не проблема. А где-то может позволить кому-то что-то основателььно тормознуть.
| | |
| 3.151, Аноним (-), 18:49, 16/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> со всеми существующими ФС сотворить,
Для OpenBSD что-то похожее нашли. Там же в бложике в коментах немало интересного встречается.
| | |
|
| 2.18, Аноним (-), 21:12, 13/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> ОО.. и где местные аналитики которые кричали все хорошо?
Это вы еще просто не видели перцев с IXBT которые совершенно случайно нашли видеофайл который можно нарезать на CD, но потом тотально не получается его оттуда прочитать. Хотя носитель при этом абсолютно исправен.
Оказывается, после трансформации алгоритмами коррекции ошибок данные файла превратились в нечто, совпадающее с служебной сущностью (IIRC, синхрометкой). Ну а приводы налетев на такое западло совершенно не понимали как это читать дальше и отдавали ошибку чтения :)
| | |
| |
| 3.26, Аноним (-), 21:31, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>> ОО.. и где местные аналитики которые кричали все хорошо?
> Это вы еще просто не видели перцев с IXBT которые совершенно случайно
> нашли видеофайл который можно нарезать на CD, но потом тотально не
> получается его оттуда прочитать. Хотя носитель при этом абсолютно исправен.
> Оказывается, после трансформации алгоритмами коррекции ошибок данные файла превратились
> в нечто, совпадающее с служебной сущностью (IIRC, синхрометкой). Ну а приводы
> налетев на такое западло совершенно не понимали как это читать дальше
> и отдавали ошибку чтения :)
а ссыли нет? интересно было бы самому нарезать...
| | |
|
|
| 1.5, Аноним (-), 20:44, 13/12/2012 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +2 +/– |
местные аналитики забывают что подобная атака была и на питон и на пхп и на много еще чего находящегося в продакшене.
| | |
| 1.8, Аноним (-), 20:54, 13/12/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
Это можно сделать не только на Btrfs, в том плане что поедание ресурсов возможно не только в данной ФС и не только в ФС
| | |
| |
| 2.14, Аноним (-), 21:04, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Это можно сделать не только на Btrfs, в том плане что поедание
> ресурсов возможно не только в данной ФС и не только в ФС
Это можно сделать много где и это не самый ожидаемый вектор атаки для программистов.
В общем то это довольно фундаментальная проблема использующая слабое место хэш-таблиц: при коллизиях хэш-таблица может быть медленной. Если коллизий много - дело дрянь. Атака состоит в потугах сделать так чтобы коллизий стало много. Для криптостойких функций это невозможно, но они слишком медленны для скоростных применений (лукап в структуре ключ-значение в памяти). А вот упрощенные хэши дают достаточно маневра для попыток их проабузить. CRC32 в этом плане очень плох, т.к. алгоритмы подгона CRC32 под ответ ни для кого не секрет.
| | |
| 2.16, svn (??), 21:07, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
На качественных файловых системах, xfs(btree вместо hash), reiserfs(на этапе проектировки предусмотрена устойчивость к коллизиям) такого сделать не получится.
| | |
| |
| 3.20, Аноним (-), 21:14, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– | |
> предусмотрена устойчивость к коллизиям)
А нельзя ли пруф на то что они специально дизайнились с учетом этого фактора? А то проблема просто есть у целого класса алгоритмов - хэш функций. И задумались о аккуратном подгоне входных данных для их торможения относительно недавно. Явно позже чем указанные ФС проектировались. Что вызывает некие нехорошие подозрения на ваш счет.
| | |
| |
| 4.23, linux must _RIP_ (?), 21:23, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –1 +/– |
какая-то у вас каша в голове.. скорость вычисления хэша - вещь константная. И то что колизии бывают - нормальный разработчик как бы в курсе.. (достаточно подумать 255 байт ужимают до 32 - тут уж не бывает без вариантов). Другой вопрос что при реализации кто-то заложился что таких колизий не много - но это уже проблемы реализации :-) Которую тут хвалили..
| | |
| 4.24, svn (??), 21:25, 13/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
reiserfs использует хеш функцию r5, для которой не известен алгоритм создания коллизий.
И уж точно (даже если коллизия возникнет) это ограничится проблемой производительности, а не будет отказ в создании файла.
| | |
| |
| 5.34, Аноним (-), 21:43, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> И уж точно (даже если коллизия возникнет)
В общем то коллизии находят даже для криптостойких функций иногда, а для хэш-таблиц нет требования криптостойкости в общем случае. Хотя как оказалось, такая поблажка может икаться совершенно неожиданным образом.
> а не будет отказ в создании файла.
Так в btrfs нет отказов при создания файла. Правда есть какое-то непотребное время удаления.
| | |
| |
| 6.41, svn (??), 22:23, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– | |
>Так в btrfs нет отказов при создания файла.
По ссылке не ходил статью не читал? brtfs выдал ошибку на шестьдесят втором файле с коллизией.
| | |
|
|
|
| |
| 4.29, Аноним (-), 21:34, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– | |
> у ext4 тоже специально предусмотрена обработка колизий в dx tree..
Проблема не в том что обработки нет. А в том что если коллизий будет много, алгоритм очень существенно провалится по скорости относительно "среднего по больнице" поведения. Что позволяет вредителю воткнуть весьма конкретный лом в чей-то вентилятор если коллизии можно более-менее просто посчитать и организовать их появление в системе. А вот дальще система займется их обработкой. В хучшем случае хэш-таблица может деграднуть до чего-то типа линейного списка, со всеми вытекающмим, как то не O(1) а O(N), что уже совсем иной коленкор.
| | |
| |
| 5.107, linux must _RIP_ (?), 16:38, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
>> у ext4 тоже специально предусмотрена обработка колизий в dx tree..
> Проблема не в том что обработки нет. А в том что если
> коллизий будет много, алгоритм очень существенно провалится по скорости относительно "среднего
> по больнице" поведения.
see up. все не так просто.
| | |
| |
| 6.150, Аноним (-), 01:04, 16/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> see up. все не так просто.
Да, оказывается не все так просто. В коментах к бложику продолжается изучение где еще можно так поприкалываться. Под внимание попала дефолтная ФС OpenBSD, которую как я понял успешно заDOSили :)
| | |
|
|
|
|
|
| 1.30, Buy (ok), 21:35, 13/12/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –1 +/– |
 Не понятно чего так носятся с этой btrfs, преимуществ никаких, сколько тестов уже было опубликовано, сколько раз сам ставил на корень и убеждался. В ЧЕМ, ПРИ КАКИХ УСЛОВИЯХ проявляется ее мифическая производительность???
| | |
| |
| |
| |
| |
| |
| |
| 7.69, Аноним (-), 00:16, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Ubuntu переводится как "я не могу настроить Debian"
Казалось бы, при чем тут вообще Лужков^W убунту. Впрочем, черный пиар - это тоже пиар.
| | |
|
|
| |
| |
| 7.83, AlexAT (ok), 07:21, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– | |
> Зачем это им нужно?! Магия поддержки любых ФС в ZVOL со всеми
Затем. Чтобы эту "магию" попробовать, надо либо с чистого листа начинать, либо переносить готовое. Долго, нудно, опасно. С BTRFS проще - завернул имеющуюся ext4 в BTRFS, начал юзать. Что-то в производительности или чём еще не устроило - откатился к моменту завертывания.
| | |
|
|
| |
| 6.124, Аноним (-), 18:40, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> машинка из TOP10 (что-то в первой пятерке - секвоя) говорит что работает..
> можно посмотреть в презентациях LUG2012, LAD2012. Кому верить?
Да и пусть себе работает. А топ10 - это потому что "1 из 500" звучит гораздо менее понтово, да? :)
| | |
| |
| 7.138, linux must _RIP_ (?), 00:12, 15/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
>> машинка из TOP10 (что-то в первой пятерке - секвоя) говорит что работает..
>> можно посмотреть в презентациях LUG2012, LAD2012. Кому верить?
> Да и пусть себе работает. А топ10 - это потому что "1
> из 500" звучит гораздо менее понтово, да? :)
Вы мне покажете еще 10-15P стораджей под btrfs? а top10 намекает что размер дискового массива - там не из маленьких..
| | |
|
|
|
| 4.48, ананим (?), 22:37, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
да все твои уже итак знают.
ты лучше нормальным покажи кто поддержкой этой каки в ынтырпрайзе (аля сюзе) займётся?
компания упоротых айзенов?
| | |
| |
| 5.109, linux must _RIP_ (?), 16:39, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
> да все твои уже итак знают.
> ты лучше нормальным покажи кто поддержкой этой каки в ынтырпрайзе (аля сюзе)
> займётся?
> компания упоротых айзенов?
LLNL.gov, Intel.com .... мало ?
| | |
|
|
| 3.45, Аноним (-), 22:31, 13/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
>если нам надо вынуть диск из
> пула, фс может адресно удвинуть с именно этого диска все ценное
> в другие места. После чего его можно изъять. В менее продуманных
> топологиях это или невозможно совсем или долго и сложно.
pvmove разве не тоже самое делает?
| | |
| |
| 4.57, anonymous (??), 23:26, 13/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>если нам надо вынуть диск из
>> пула, фс может адресно удвинуть с именно этого диска все ценное
>> в другие места. После чего его можно изъять. В менее продуманных
>> топологиях это или невозможно совсем или долго и сложно.
> pvmove разве не тоже самое делает?
Создание снапшота в lvm2 просаживает производительность тома, который снапшотили, в 2(!) раза. Если на этом томе виртуальная машина с dns-сервисом - это, конечно, не проблема. А если там база данных? А в btrfs эта проблема решена.
| | |
| |
| 5.64, ананим (?), 23:58, 13/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– | |
>Создание снапшота в lvm2 просаживает производительность тома, который снапшотили, в 2(!) раза.
эта… как его… использование zfs вообще в принципе просаживает и производительность, и ресурсоёмкость. btrfs тоже пока не особо производительностью радует.
так что это ещё тот пример.
> А если там база данных?
и в самый пик нагрузки именно снэпшоты и делаются?
и ещё, как дба, не стоит полагаться на снэпшоты с субд — файлы в этот момент могут быть не в консистентном состоянии и кэши в памяти могут быть не скинуты
| | |
| |
| |
| 7.74, ананим (?), 01:01, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– | |
>Тем не менее, скорость записи на оную от самого по себе факта наличия снапшота там падать не обязана.
Тем не менее скорость записи на оную падает всегда и ресурсы жрутся тоже всегда, а не только в редкие моменты снэпшотов и бэкапов, которые более-менее адекватные админы делают в наименее нагруженное время.
а если учесть упомянутую тобой бд, то сожранные фс ресурсы (а именно память) гораздо эффективнее отдать под кэш этой субд, при этом скорость работы с оной увеличится опять же всегда, при чём так, что процесс создания снепшотов будет даже и не заметен.
>> и в самый пик нагрузки именно снэпшоты и делаются?
>Проблема не в пике нагрузки.
тогда не понятен плач ярославны по поводу скорости (снэпшот тормозит пока он есть, zfs тормозит всегда)
>А в том насколько после этого скорость всех операций вообще угробится.
а нафига снепшоты вообще делают?
а то как в анекдоте:
- доктор, если я вот так вот подтяжки перекручиваю, то вот тут жмёт.
- ну не перекручивайте так подтяжки.
сделал снепшот, сделал бэкап (инкрементальный), убрал снэпшот.
>Вы в вашем праве долбаться с снапшотами ext4 через LVM если оно вам зачем-то надо.
Вы тоже в праве тормозить всегда, а не только в моменты снепшотов.
| | |
|
|
| 5.82, Анонимный аноним (?), 07:20, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Хм, на собственном опыте при единственном снэпшоте особой просадки производительности (тем более в 2 раза) не заметил. Сильно заметно просадку после 3-4 снапшота. Тестилось достаточно дубово - копированием кучи rpm-ов, общая дельта изменений ~60% от первоначального. Ось RHEL-6. Для себя сделал вывод, использовать не более двух снапшотов с последующим архивированием и удалением.
| | |
| 5.93, Аноним (-), 10:42, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>>если нам надо вынуть диск из
>>> пула, фс может адресно удвинуть с именно этого диска все ценное
>>> в другие места. После чего его можно изъять. В менее продуманных
>>> топологиях это или невозможно совсем или долго и сложно.
>> pvmove разве не тоже самое делает?
> Создание снапшота в lvm2 просаживает производительность тома, который снапшотили, в 2(!)
> раза. Если на этом томе виртуальная машина с dns-сервисом - это,
> конечно, не проблема. А если там база данных? А в btrfs
> эта проблема решена.
pvmove это не снапшот, это вынуть диск из пула, я же специально цитировал на что отвечаю :)
| | |
|
|
|
| 2.36, anonymous (??), 21:50, 13/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> Не понятно чего так носятся с этой btrfs, преимуществ никаких, сколько тестов
> уже было опубликовано, сколько раз сам ставил на корень и убеждался.
> В ЧЕМ, ПРИ КАКИХ УСЛОВИЯХ проявляется ее мифическая производительность???
Помимо производительности, есть соображения удобства администрирования и количества поддерживаемых возможностей.
| | |
|
| 1.72, Аноним (-), 00:41, 14/12/2012 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
У бтрфс есть еще одно узкое место помимо производительности - пожирание места на диске за счет метаданных. на 10 гб данных требуется 1 гб метаданных, если правильно помню - 10% места коту под хвост в самом лучшем случае ;)
| | |
| |
| 2.73, filosofem (ok), 00:49, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> У бтрфс есть еще одно узкое место помимо производительности - пожирание места
> на диске за счет метаданных. на 10 гб данных требуется 1
> гб метаданных, если правильно помню - 10% места коту под хвост
> в самом лучшем случае ;)
Слегка ошибся. На 5ТБ данных 10ГБ метаданных. А вообще это зависит.
| | |
| 2.128, Аноним (-), 18:53, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> на диске за счет метаданных. на 10 гб данных требуется 1 гб метаданных,
Хотите прикол? Создавайте директории и в них файлы 0-го размера до упора. Однажды вы обнаружите что хотя на диске всего 0 байтов (т.к. все файлы нулевого размера), место тем не менее почему-то кончилось. Да-да, на 0 байтов полезных данных можно спровоцировать 100500Гб метаданных, сожравших вообще все место. Кстати, от типа файловой системы это вообще не зависит особо :)
| | |
| 2.141, Аноним (-), 23:30, 15/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> У бтрфс есть еще одно узкое место помимо производительности - пожирание места
> на диске за счет метаданных. на 10 гб данных требуется 1
> гб метаданных, если правильно помню - 10% места коту под хвост
> в самом лучшем случае ;)
Внезапно, эта величина сильно зависит от среднего размера файлов. Потому что информация о том, что файл есть, и как он называется - это и есть метаданные.
| | |
|
| |
| 2.129, Аноним (-), 18:55, 14/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> crc32? ну они дали(((
Для hash table это в принципе вполне себе функция. Просто оказалось что в конкретно этом случае можно хитро изогнуться. Но этот изгибон требует хакерского мышления а не програмерского. Так умеют не все.
| | |
| |
| 3.135, nuclight (??), 20:01, 14/12/2012 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –3 +/– |
>> crc32? ну они дали(((
> Для hash table это в принципе вполне себе функция. Просто оказалось что
> в конкретно этом случае можно хитро изогнуться. Но этот изгибон требует
> хакерского мышления а не програмерского. Так умеют не все.
Покажи-ка еще хотя бы парочку известных применений, где CRC32 использовался бы именно в качестве _хэша_ для таблиц. То, что формально математически его можно отнести к хэшам, не означает, что таким идиотизмом надо заниматься на практике.
| | |
| |
| 4.148, Аноним (-), 00:48, 16/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Покажи-ка еще хотя бы парочку известных применений, где CRC32 использовался бы именно
> в качестве _хэша_ для таблиц.
Насчет CRC32 - увы, я не коллекционировал специально для вас подборку всех реализаций с ранжированием по функции хеширования. Однако недавние дыры в пыхе, питоне и чем там еще - прозрачно намекают что простые и предсказуемые функции в хэш-таблицах - вполне обычное явление.
| | |
|
| 3.159, arisu (ok), 21:08, 20/12/2012 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> Для hash table это в принципе вполне себе функция.
вот такие кулхацкеры и суют её в хэши, ага. сейчас я тебе скажу два словосочетания: «avalanche test» и «uniform distribution test». да, это надо вбивать в гугель вместе с буквами «crc32».
я надеюсь, ты не пишешь ничего сложнее приветмиров. или хотя бы не показываешь публике. потому что с таким уровнем компетенции… в других областях она у тебя не лучше, инфа 146%
| | |
|
|
| |
| 2.162, Аноним (-), 01:58, 21/12/2012 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– | |
> хэш. crc32. на всякий случай отложил идею пощупать btrfs на 50 лет.
Лучше на 100. А то вдруг каким-то чудом доживешь еще? Как же тогда твой статус некрофила?
| | |
|
|
