| |
| |
| 3.13, BratSinot (?), 21:03, 13/12/2012 [^] [^^] [^^^] [ответить]
| –13 +/– |
> XFS рекомендуется для создания хранилища
> Btrfs для корневой ФС
Вы точно читать умеете? Хранилище, это там где положили и хранят. Корень, это там, где постоянно что-то меняется.
| | |
| |
| 4.19, Анонище (?), 21:14, 13/12/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если корень это там, где что-то постоянно меняется, то расскажи как нам милок, что есть /var?
| | |
| |
| 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)
| | |
| |
| 8.95, Аноним (-), 11:00, 14/12/2012 [^] [^^] [^^^] [ответить] | +6 +/– | А некоторые еще и через костры прыгают, в прорубь зимой ныряют, делают татуировк... текст свёрнут, показать | | |
|
| 7.139, Аноним (-), 13:42, 15/12/2012 [^] [^^] [^^^] [ответить] | +/– | http lists busybox net pipermail busybox 2010-December 074114 html http www ... большой текст свёрнут, показать | | |
|
|
| |
| |
| 7.79, Яйцассыром (?), 04:32, 14/12/2012 [^] [^^] [^^^] [ответить]
| +8 +/– |
вот нелегко нам злоумышленникам( все время палки в колеса подлые админы вставляют(
| | |
|
|
|
| 4.91, Аноним (-), 09:22, 14/12/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Прядочная женщина любит порядок: сегод7я один, завтра другой. Потаскуха - потоскует и идет спать.
| | |
|
|
| 2.12, SubGun (ok), 21:03, 13/12/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Готова к продакшену, да? Поздравлямс сусю.
Выпустят патч и ФС приблизиться к идеалу еще на шажок.
| | |
| |
| |
| |
| 5.53, iZEN (ok), 23:04, 13/12/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Только так и не видно его, продакшна этого, вот в чём соль.
Лиц пубертатного возраста к продакшену не допускают.
| | |
| |
| 6.54, AlexAT (ok), 23:07, 13/12/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >> Только так и не видно его, продакшна этого, вот в чём соль.
> Лиц пубертатного возраста к продакшену не допускают.
Видимо да, в этом и причина...
| | |
| 6.55, Аноним (-), 23:08, 13/12/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Лиц пубертатного возраста к продакшену не допускают.
По тебе заметно :)
| | |
| 6.140, Аноним (-), 23:28, 15/12/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Лиц пубертатного возраста к продакшену не допускают.
Если так, то у ZFS нет шансов в продакшене.
| | |
|
| |
| 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, почему нет?
На практике сие могут сделать только идиоты.
Еще раз перечитал пост изена выше - ни хрена это не хеш-таблица, это чексуммирование данных.
| | |
| |
| 7.115, Аноним (-), 17:52, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Потому что на практике от такой диверсии хэш-таблица изрядно тормознет Всерьез ... большой текст свёрнут, показать | | |
|
| 6.118, iZEN (ok), 18:15, 14/12/2012 [^] [^^] [^^^] [ответить] | –2 +/– | Чексуммирование 8212 частный случай применения хэширования Хэш на основе CRC... большой текст свёрнут, показать | | |
| |
| 7.131, Аноним (-), 19:34, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Только к хэш- b таблицам b все это ну вообще совсем не относится Ни флетчер, ... большой текст свёрнут, показать | | |
| |
| 8.136, iZEN (ok), 20:41, 14/12/2012 [^] [^^] [^^^] [ответить] | –2 +/– | А что, кто-то утверждал что CRC32, fletcher, SHA-256 в ZFS используется в хэш-та... большой текст свёрнут, показать | | |
| |
| 9.143, Аноним (-), 00:18, 16/12/2012 [^] [^^] [^^^] [ответить] | +/– | Ну вот и будьте Какой смысл с апломбом вспоминать sha-256 чексуммировние данных... большой текст свёрнут, показать | | |
|
|
|
|
| 5.121, iZEN (ok), 18:32, 14/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | gt оверквотинг удален Дополню справедливости ради --- Блоки пула дисковой ... большой текст свёрнут, показать | | |
|
|
|
| 2.56, Аноним (-), 23:25, 13/12/2012 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Поздравлямс сусю.
Разработчики суси уже надоели. Всё время совершают какие-то ошибки. То ли дело разработчики убунты - никогда их не совершают! Ещё ни разу не было новости о том, что разработчики ядра из Canonical объявили свою разработку готовой к использованию, а через неделю появляется новость о критичном баге в нём!
| | |
| |
| |
| 4.81, canonical (?), 07:10, 14/12/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>разработчики ядра из Canonical
>Таких не существует в природе!
http://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.
>Толсто!
а с этим согласен.
| | |
|
|
| 2.70, Кевин (?), 00:19, 14/12/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
ребят то что не готово к продакшену досить даже не пытаются...
| | |
| |
| 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а будет ниже или вообще невозможен.
| | |
| |
| 4.58, Аноним (-), 23:26, 13/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Взаимоисключающие параграфы детектед Он, конечно, кричит, но в хеш-табли... большой текст свёрнут, показать | | |
| |
| 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 предназначена для поиска и исправления ошибок в канале связи (а не для хеширования), тоже учат.
И да, деревья тоже дают. Ты мог бы уже включить моск и подумать, почему проектировщики файловых систем обычно выбирают деревья, а не хэши.
| | |
| |
| 6.144, Аноним (-), 00:30, 16/12/2012 [^] [^^] [^^^] [ответить] | +/– | Много апломба и мало по делу На втором курсе обычно учат тому что нужна какая-... большой текст свёрнут, показать | | |
| |
| 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 - тут уж не бывает без вариантов). Другой вопрос что при реализации кто-то заложился что таких колизий не много - но это уже проблемы реализации :-) Которую тут хвалили..
| | |
| |
| 5.28, Аноним (-), 21:31, 13/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Просто намеренный гасеж коллизиями вообще-то не является штатным видом эксплуата... большой текст свёрнут, показать | | |
| |
| |
| 7.119, Аноним (-), 18:24, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Внезапно, хэш-таблицы сами по себе вообще не требуют в общем случае использовани... большой текст свёрнут, показать | | |
|
|
|
| 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 выдал ошибку на шестьдесят втором файле с коллизией.
| | |
| |
| 7.61, Аноним (-), 23:46, 13/12/2012 [^] [^^] [^^^] [ответить] | +/– | Не только читал, но и в курсе как хэш таблицы делают Понимаете ли, для хэш-табл... большой текст свёрнут, показать | | |
| |
| 8.84, svn (??), 07:35, 14/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Почитай ещё раз То что ты знаешь, не значит что авторы btrfs знают По факту, в... текст свёрнут, показать | | |
| |
| 9.122, Аноним (-), 18:32, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Во первых, простите, а что есть дописать в середину файла Технически я понима... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| |
| 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, преимуществ никаких, сколько тестов уже было опубликовано, сколько раз сам ставил на корень и убеждался. В ЧЕМ, ПРИ КАКИХ УСЛОВИЯХ проявляется ее мифическая производительность???
| | |
| |
| 2.35, Аноним (-), 21:47, 13/12/2012 [^] [^^] [^^^] [ответить] | +3 +/– | Возятся с ней потому что вот в этом вы не правы Во первых, покажите хоть какую... большой текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| 7.69, Аноним (-), 00:16, 14/12/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ubuntu переводится как "я не могу настроить Debian"
Казалось бы, при чем тут вообще Лужков^W убунту. Впрочем, черный пиар - это тоже пиар.
| | |
|
|
| 5.67, Аноним (-), 00:03, 14/12/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Не, ну почему Как-то работает Вопрос только в том КАК 1 Это не в майнлайне ... большой текст свёрнут, показать | | |
| |
| 6.75, iZEN (ok), 01:03, 14/12/2012 [^] [^^] [^^^] [ответить] | –3 +/– | Зачем это им нужно Магия поддержки любых ФС в ZVOL со всеми плюшками ZFS, как ... большой текст свёрнут, показать | | |
| |
| 7.83, AlexAT (ok), 07:21, 14/12/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Зачем это им нужно?! Магия поддержки любых ФС в ZVOL со всеми
Затем. Чтобы эту "магию" попробовать, надо либо с чистого листа начинать, либо переносить готовое. Долго, нудно, опасно. С BTRFS проще - завернул имеющуюся ext4 в BTRFS, начал юзать. Что-то в производительности или чём еще не устроило - откатился к моменту завертывания.
| | |
| |
| 8.146, Аноним (-), 00:38, 16/12/2012 [^] [^^] [^^^] [ответить] | +1 +/– | У него жгучий продакшн с трехдисковым пулом выдающим 18Мб сек А у меня ноутбучн... текст свёрнут, показать | | |
| |
| 9.152, iZEN (ok), 09:42, 17/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Твой винт поддерживает хотя бы дедупликацию блоков ФС, не говоря уж о сквозной ц... текст свёрнут, показать | | |
| |
| |
| 11.155, iZEN (ok), 18:37, 17/12/2012 [^] [^^] [^^^] [ответить] | –2 +/– | А чего же тогда лезет в охотный ряд и сравнивает в принципе известные факты де... большой текст свёрнут, показать | | |
| |
| 12.156, AlexAT (ok), 19:30, 17/12/2012 [^] [^^] [^^^] [ответить] | +2 +/– | Блджад Вот сразу видно жабиста Zero knowledge of underlying operations Не у... большой текст свёрнут, показать | | |
| |
| 13.161, Аноним (-), 22:24, 20/12/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Ну что поделать Не понимают жабисты как работают компьютеры Это позволяет им к... большой текст свёрнут, показать | | |
| |
| 14.163, iZEN (ok), 20:10, 21/12/2012 [^] [^^] [^^^] [ответить] | +/– | Не поэтому scrub бессилен на FAULTED-пуле Но недавно появилась волшебная коман... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 7.123, Аноним (-), 18:39, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Просто прикольная иллюстрация гибкости в размещении метаданных Оно даже иную ФС... большой текст свёрнут, показать | | |
|
|
| |
| 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.47, Аноним (-), 22:34, 13/12/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
А дополнительно для упоротых там подарят мне 32 гб озу если я скачаю сорца zfsonlinux?
| | |
| 4.48, ананим (?), 22:37, 13/12/2012 [^] [^^] [^^^] [ответить]
| +/– |
да все твои уже итак знают.
ты лучше нормальным покажи кто поддержкой этой каки в ынтырпрайзе (аля сюзе) займётся?
компания упоротых айзенов?
| | |
| |
| 5.109, linux must _RIP_ (?), 16:39, 14/12/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
> да все твои уже итак знают.
> ты лучше нормальным покажи кто поддержкой этой каки в ынтырпрайзе (аля сюзе)
> займётся?
> компания упоротых айзенов?
LLNL.gov, Intel.com .... мало ?
| | |
| |
| 6.125, Аноним (-), 18:41, 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 тоже пока не особо производительностью радует.
так что это ещё тот пример.
> А если там база данных?
и в самый пик нагрузки именно снэпшоты и делаются?
и ещё, как дба, не стоит полагаться на снэпшоты с субд — файлы в этот момент могут быть не в консистентном состоянии и кэши в памяти могут быть не скинуты
| | |
| |
| 6.68, Аноним (-), 00:07, 14/12/2012 [^] [^^] [^^^] [ответить] | –1 +/– | Тем не менее, скорость записи на оную от самого по себе факта наличия снапшота т... большой текст свёрнут, показать | | |
| |
| 7.74, ананим (?), 01:01, 14/12/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Тем не менее, скорость записи на оную от самого по себе факта наличия снапшота там падать не обязана.
Тем не менее скорость записи на оную падает всегда и ресурсы жрутся тоже всегда, а не только в редкие моменты снэпшотов и бэкапов, которые более-менее адекватные админы делают в наименее нагруженное время.
а если учесть упомянутую тобой бд, то сожранные фс ресурсы (а именно память) гораздо эффективнее отдать под кэш этой субд, при этом скорость работы с оной увеличится опять же всегда, при чём так, что процесс создания снепшотов будет даже и не заметен.
>> и в самый пик нагрузки именно снэпшоты и делаются?
>Проблема не в пике нагрузки.
тогда не понятен плач ярославны по поводу скорости (снэпшот тормозит пока он есть, zfs тормозит всегда)
>А в том насколько после этого скорость всех операций вообще угробится.
а нафига снепшоты вообще делают?
а то как в анекдоте:
- доктор, если я вот так вот подтяжки перекручиваю, то вот тут жмёт.
- ну не перекручивайте так подтяжки.
сделал снепшот, сделал бэкап (инкрементальный), убрал снэпшот.
>Вы в вашем праве долбаться с снапшотами ext4 через LVM если оно вам зачем-то надо.
Вы тоже в праве тормозить всегда, а не только в моменты снепшотов.
| | |
| |
| 8.127, Аноним (-), 18:50, 14/12/2012 [^] [^^] [^^^] [ответить] | +/– | Простите, падает - это если на ext4 полный журнал врубить А тут аналог полного ... большой текст свёрнут, показать | | |
|
| 7.89, GentooBoy (ok), 08:53, 14/12/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Почитайте про устройство снапшотов в LVM, а потом говорите про уменьшение производительности в 2 раза.
| | |
|
|
| 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, преимуществ никаких, сколько тестов
> уже было опубликовано, сколько раз сам ставил на корень и убеждался.
> В ЧЕМ, ПРИ КАКИХ УСЛОВИЯХ проявляется ее мифическая производительность???
Помимо производительности, есть соображения удобства администрирования и количества поддерживаемых возможностей.
| | |
| |
| |
| 4.63, Аноним (-), 23:50, 13/12/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Зачем нужны возмжности, если давно уже есть LVM+ext4?
Вот вы и юзайте там снапшоты если хотите.
| | |
|
|
|
| 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. А то вдруг каким-то чудом доживешь еще? Как же тогда твой статус некрофила?
| | |
|
|
