форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

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

"Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от opennews (??) on 27-Фев-12, 16:08
Для файловой системы Btrfs были представлены (http://article.gmane.org/gmane.comp.file-systems.btrfs/15744) патчи с поддержкой алгоритма сжатия LZ4 (http://code.google.com/p/lz4/), показавшие довольно приятные  результаты. LZ4 - скоростной алгоритм сжатия, как правило обгоняющий Snappy (https://www.opennet.ru/opennews/art.shtml?num=30003) по степени сжатия и способный достигать скорости сжатия в 300Мб/сек на одном ядре процессора и скорости распаковки в 1Гб/сек, достигая на многоядерной системе потолка производительности RAM. Также отмечается (http://www.phoronix.com/scan.php?page=news_item&px=MTA2MDI) о создании отдельной экспериментальной ветки в Git-репозитрии (https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs...) Btrfs для тестирования реализации утилиты btrfsck, ориентированной на восстановление целостности повреждённой ФС (добавлена опция "--repair"). Ветка получила название "dangerdonteveruse (https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs... URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA1OTQ Новость: https://www.opennet.ru/opennews/art.shtml?num=33197
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 16:08
Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+7 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 16:12
	> Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования. Почитайте man fsck в вашей ОС, там изложены несколько иные взгляды.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	60. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 01:56
	>  А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования. Как бы тебе объяснить то? Ты будешь готов скушать далеко не любой результат работы таковой утилиты. Иногда таким утилитам "по статусу положено" принимать потенциально проблемные решения, так что вопрос о дефолтах довольно философский.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 16:10
> Также отмечается о создании отдельной экспериментальной ветки в Git-репозитрии Btrfs > ветка получила название "dangerdonteveruse" Хм. Бранч с таким названием в репе btrfs-progs лично я помню уже как минимум месяц.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–6 +/–
Сообщение от Васька. on 27-Фев-12, 16:17
Непонятно, зачем сжатие файловой системе? Хранить в два, ну почти три раза больше данных :-( данные данным рознь, не получится из этого ничего хорошего.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+9 +/–
	Сообщение от Блуд (??) on 27-Фев-12, 16:24
	Всё очень просто. Храня сжатые данные, требуется меньше времени на их считывания. А учитывая, что жёсткий диск является медленным устройством, то сжатие - большой плюс!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	11. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–6 +/–
	Сообщение от Анодуб on 27-Фев-12, 16:33
	Больше кэшей! Больших и разных.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 16:48
	При рандомном доступе к многотерабайтному массиву, для более-менее эффективной работы размер кэша должен быть сопоставим с размером массива. Во-первых, дорого, во-вторых, неустойчиво к сбоям. Порочность этого пути хорошо видна на примере ZFS, которая выдает приемлемую производительность только в "режиме стримера" (т.е. исключительно при линейном доступе).
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	41. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 19:21
	Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать, потом распаковать, потом только обратиться к нужному месту. Рандомное обращение - плохой пример.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	47. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 23:31
	Очень сильно зависит от размера секции.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	58. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от VoDA (ok) on 28-Фев-12, 01:08
	> Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать, > потом распаковать, потом только обратиться к нужному месту. Рандомное обращение - > плохой пример. Много-пользователей читает множество файлов. Или раздача web-статики. Получается стучимся в радномные файлы (часто малого размера). На этом как раз кэш в холостую работает, а сжатие данных очень полезно.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	63. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 01:59
	> Как рандомно обратиться к запакованным данным? Так же как и к остальным - никто не жмет огромные блоки. Сжатие идет небольшими кусками, чего впрочем вполне хватает для профита на рыхлых данных. Да, 7zip сожмет покруче. И даже очень. Вот только скорость... ;)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	62. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 01:58
	> Больше кэшей! Больших и разных. В данном случае выигрыш за счет того что меньше данных читать-писать, а алгоритм крайне быстр и может существенно обгонять накопитель.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	71. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 08:04
	А еще это решение является концептуальным в своем роде. Подумайте сами - с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы при этом лишь надо соблюсти соотношение скорость сжатия/распаковки со скоростью чтения/записи на носитель.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	72. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 08:23
	> с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы Ну вот zlib зачастую не поспевает за накопителем, т.к. 2-ступенчатый (LZ -> huffman). А вот эти алгоритмы - быстрые, распаковка такой штуки вообще напоминает немного продвинутый вариант memcpy. Поэтому обычно они (LZO, Snappy, LZ4) - шустрее. Накопители, btw, тоже на месте не стоят: появились ssd которым 6Гбит sata - мало, так что они в pci-e втыкаются. Стоят конечно конских денег, но ведь и скорость - под стать...
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	88. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 17:17
	А как насчет LZMA ? ИМХО, кажется он совершенно пригоден для сжатия на уровне фс (ядра-то мы давно уже сжимаем им).
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	90. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от arisu (ok) on 28-Фев-12, 17:23
	> А как насчет LZMA ? с дуба рухнул, штоле? скорость сжатия ужасающа, скорость разжатия ужасающа.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	117. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 17:36
	> А как насчет LZMA ? Хоть его и портировали на чистый си в конце концов и даже в виде годном для пихания в ядро... 1) По скорости сжатия он еще хуже zlib, потому что делался с оглядкой на максимальное сжатие. 2) При мелком размере блока разогнаться с крутым сжатием особо негде и не на чем. А жать большой блок - долго и RAM много надо... 3) По скорости распаковки он как и все LZ-based довольно ничего, но... но довольно хардкорная несимметрия скоростей сжатия и распаковки ограничивает его применение в штуках типа squashfs или сжатия ядра, где распаковка - есть, а упаковки - нет. Просто потому что упаковка может быть длительной и потребовать много ресурсов, что слегонца неприемлимо для сжатия работающего на лету. Технически кстати LZMA всего лишь развитие все тех же идей: 2-ступенчатый алгоритм, LZ-подобное сжатие которому дозволено юзать более крупный словарь чем zlib с его куцыми 32кб + марковские цепочки как вторая стадия. Жмет хорошо но медленно. Распаковывается более-менее резво (как и любой иной LZ-based). Рекордные скорости не покажет из-за двустадийности (распаковка голого LZ без второй стадии может быть крайне быстрой в силу простоты этой операции).
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	6. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от igoree on 27-Фев-12, 16:25
	библиотека мошкова кашерно разместится)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Анонут on 27-Фев-12, 16:28
	Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать как-бэ 120Мб. Реально влезало на 1-2Мб больше. При малейшем сбое на винте - данные терялись чуть менее чем все. Может сейчас оно уже не так ужасно. Прогресс всетаки.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+4 +/–
	Сообщение от inferrna on 27-Фев-12, 16:43
	Ну, во-первых, там и в 95-98 винде сжимался вроде-как весь диск и при внешнем монтировании это дело выглядело как 1 большой файл и горстка маленьких. Тут, всё-таки, сжимаются отдельные файлы. Во-вторых, по-умолчанию там "compress highly compressible files, but back off and blacklist incompressible content".
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	73. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 08:31
	> Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать > как-бэ 120Мб. Реально влезало на 1-2Мб больше. Реально - зависело от того что там хранить. Понятный пень что уже сжатые жыпеги и гифы еще раз не сожмутся. А вот рыхлые текстовики, бинарники системы и прочие doom2.wad - на раз жмутся в 2-3 раза, обеспечивая вполне себе профит. Правда там алгоритм сжатия был не чемпион по скорости и потому о выигрыше в скорости речь не шла. Но с ростом мощщи проца, появлением кучи ядер и развитием скоростных алгоритмов типа того же LZ4 - появился повод вспомнить давно забытое старое еще раз. На новом технологическом уровне. > При малейшем сбое на винте - данные терялись чуть менее чем все. Все - не терялись, но вот утилиты починки диска реагировали на такие диски довольно странно. Вообще оно было довольно криво сделано, два набора чувствительных структур (FAT и CVFAT), и журнала опять же нет, а во времена доса - еще и защиты памяти драйвера. Так что небольшой факап программы мог порушить память драйверу сжатия и устроить довольно массовый дестрой данных на томе. > Может сейчас оно уже не так ужасно. Прогресс всетаки. Ну так времена ОС без защиты памяти, фс без журналирования и что там еще - закончились.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от x0r (??) on 27-Фев-12, 16:30
	ну если не сжалось - можно и записать как есть.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	51. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 00:10
	ты видел сколько бдрипы стартрека занимают? в ноут такой диск пока не впихнёшь.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	77. "Представлены патчи для Btrfs с поддержкой алгоритма..."	–1 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 12:01
	> ты видел сколько бдрипы стартрека занимают? во времена TOS никакого «б» не было. а остальным место в помойке.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	61. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 01:57
	> Непонятно, зачем сжатие файловой системе? Скорость записи и особенно чтения с столь скоростными алгоритмами может быть _быстрее_ чем скорость чтения-записи несжатых файлов. Просто потому что читать-писать меньше и если все упиралось в накопитель, ему внезапно полегчает в пару раз -> PROFIT.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
Сообщение от x0r (??) on 27-Фев-12, 16:28
"устойчива к сбоям, тем не мнее потребность в fsck вызвана возможностью появления повреждений, вызванных внешними факторами" Типа космические архитекторы столкнулись с реальностью? Они заметили, что: 1) при их методах использования двоичных деревьев - дофига места тратится на метаинформацию. 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 16:40
	> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает... Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе такого представить.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	25. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–9 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 17:28
	>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает... > Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе > такого представить. В линюкс эта фс входит в штатное ядро? Уже можно пользоваться "из коробки" и без лишних телодвижений, как extx, jfs, xfs? Что-то в том же руководстве по генту о ней ни слова... Ой, так вы о той самой фс, у которой проблемы с лицензией под линюкс? Которая требует или патча на ядро, или использования ее в fuse? Экое счастье - оставьте его тем, кому оно надо - инвалидам на костылях. А мы btrfs прекрасно будем пользоваться ;) Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	31. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 18:29
	> Которая требует или патча на ядро, или использования ее в fuse? zfsonlinux легко и непринужденно собирается модулем. Но зачем тащить в линукс это кривое тормозилово? > Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck. Да, ZFS при сбоях данные убивает надежно и намертво. А ее разработчики zfschk не осилили, поэтому придумывают сказки, что оно не нужно.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	37. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–6 +/–
	Сообщение от iZEN (ok) on 27-Фев-12, 18:59
	> Да, ZFS при сбоях данные убивает надежно и намертво. Что вы врёте и не краснеете? При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F"  и scrub'а может быть живым, лишившись лишь части файлов - http://forum.ixbt.com/topic.cgi?id=11:43009-163#4797
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	48. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+1 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 23:36
	> При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F"  и scrub'а может быть живым, лишившись лишь части файлов Теоретики, такие теоретики...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	52. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от Клыкастый (ok) on 28-Фев-12, 00:13
	практики куда круче
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	95. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 18:33
	> Теоретики, такие теоретики... Дык, практики. Всё опробовано и выяснено на деле.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	101. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 19:09
	> Дык, практики. Всё опробовано и выяснено на деле. Если вы думаете, что fsck на ZFS не нужен, значит, вы не сталкивались на практике со сбоями в ZFS.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	109. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 21:09
	>> Дык, практики. Всё опробовано и выяснено на деле. > Если вы думаете, что fsck на ZFS не нужен, значит, вы не > сталкивались на практике со сбоями в ZFS. Я сталкивался со сбоями ZFS. После scrub'а повреждённого пула у меня был список невосстановимых файлов. Сам пул был приведён в рабочее состояние.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	78. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+2 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 12:04
	> Метаинформация многократно дублируется. а я покупал диски, чтобы данные хранить, а не «метаинформацию»…
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	91. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 18:28
	> а я покупал диски, чтобы данные хранить, а не «метаинформацию»… Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	97. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+3 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 18:37
	>> а я покупал диски, чтобы данные хранить, а не «метаинформацию»… > Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. > ;) а в zfs мало, и та через libastral добывается, места не занимает.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	100. "Представлены патчи для Btrfs с поддержкой алгоритма..."	–1 +/–
	Сообщение от Аноним (??) on 28-Фев-12, 19:08
	> Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;) А в ZFS ее столько же, плюс еще она дублируется 100500 раз (хотят толку от этого, если копии не консистентны). Так что места под данные не остается вообще =)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	108. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 19:49
	> хотят толку от этого, если копии не консистентны Откуда вы это знаете? Где проходили? В ZFS 128k-блоки (по умолчанию) данных и метаданных имеют контрольную сумму (алгоритм подсчёта контрольных сумм — свойство конкретной ФС в пуле, можно выбрать). Если, допустим, с пула читаются данные, то каждый блок подвергается проверке на предмет целостности. Если блок повреждён, то ZFS на лету пробует перечитать и восстановить его в случае с отказоустойчивым пулом, а в случае с неотказоустойчивым — рапортует об ошибке чтения файла или метаданных. При повреждении всех синхронных копий метаданных работа с пулом прекращается. scrub сканирует метаданные и данные (не весь объём ФС, а только занятый), вычисляет повреждения, восстанавливает обнаруженную неконсистентность, предоставляет полный список невосстановимых файлов с полными путями к ним.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	112. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от ананим on 01-Мрт-12, 20:31
	>Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;) # btrfs filesystem df / Data: total=310.00GB, used=227.90GB System, DUP: total=8.00MB, used=44.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=4.12GB, used=2.85GB данных 227.90GB метаданных 2.85GB ~1% Гораздо меньше zfs опять врёшь.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	113. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от iZEN (ok) on 01-Мрт-12, 21:42
	>>Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;) > # btrfs filesystem df / > Data: total=310.00GB, used=227.90GB > System, DUP: total=8.00MB, used=44.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=4.12GB, used=2.85GB > данных 227.90GB > метаданных 2.85GB > ~1% > Гораздо меньше zfs Читал: http://docs.oracle.com/cd/E19253-01/820-0836/gbchp/index.html http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuni... ? > опять врёшь. — не ко мне. Можешь посчитать тут: https://lkml.org/lkml/2010/6/3/313 Тут обсуждение: http://www.linux.org.ru/news/kernel/5041798 и тут: http://habrahabr.ru/blogs/linux/108629/
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	38. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+3 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 19:02
	+1 У меня бтр под Linux 98 ваще летает, а ZFS ацтой, постоянно глючил на дискетах 1.44".
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	40. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
	Сообщение от zhuk on 27-Фев-12, 19:18
	А чтож ты, деточка, не представился? Засцал с izen'ом в открытую поговорить?))))
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	44. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
	Сообщение от fyjybvec on 27-Фев-12, 20:39
	Вот только Б-дерево - не двоичное. Но кого это волнует?..
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	64. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+2 +/–
	Сообщение от Аноним (??) on 28-Фев-12, 02:01
	> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает... Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны...
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	92. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 18:29
	>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает... > Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны... Кактус ли это?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	102. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 19:11
	> Кактус ли это? Лично мне кажется, что склонная к неожиданным смертям файлуха без fsck - явный кактус. Поэтому на ZFS не рвусь. У вас, конечно, может быть другое мнение =)
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	110. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 21:37
	>> Кактус ли это? > Лично мне кажется, что склонная к неожиданным смертям файлуха без fsck - > явный кактус. Поэтому на ZFS не рвусь. > У вас, конечно, может быть другое мнение =) https://www.opennet.ru/openforum/vsluhforumID3/83275.html#94
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

12. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Sergey722 (ok) on 27-Фев-12, 16:36
Что-то часто про БТР в последнее время слышно...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 17:00
	Аха, к 14 февраля обещали релиз btrfs.fsck. Сегодня 27 :)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	23. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Sergey722 (ok) on 27-Фев-12, 17:20
	Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта (ну на крайняк к 9 мая).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	35. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 18:36
	> Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта > (ну на крайняк к 9 мая). Вопрос только, какого года? Явно, что не этого.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	45. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+1 +/–
	Сообщение от Serrgey722too on 27-Фев-12, 22:52
	> Вопрос только, какого года? Явно, что не этого. Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	49. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 23:38
	> Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади. Да, к 70-му юбилею. Ну в крайнем случае к 75-му.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	20. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Анодуб on 27-Фев-12, 17:04
	Это будет боевая ФС для ОБЧР!
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	22. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Sergey722 (ok) on 27-Фев-12, 17:12
	Да я в курсе. Просто её пилят чуть ли не столько же сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот я думаю, это признак того, что счастье уже близко или просто статистический выброс.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 17:24
	Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	34. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+1 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 18:35
	> Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :) Лично для меня разработка btrfs - это такой комедийный сериал, по длительности сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим", посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	66. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 02:02
	> Лично для меня разработка btrfs - это такой комедийный сериал, по длительности > сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим", > посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid. "Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..."
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	81. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–2 +/–
	Сообщение от Аноним (??) on 28-Фев-12, 14:26
	> "Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..." Это не про разработку btrfs. Про разработку btrfs будет так: "Сначала над вами смеются, потом над вами смеются, а потом над вами смеются снова..."
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	120. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 21:55
	> смеются, а потом над вами смеются снова..." Вам бы этого хотелось, да? Ну чтож, мечтайте, это не вредно :)
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	79. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+1 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 12:07
	для тебя вообще разработка — комедийный сериал, видимо. «и что вы мучаетесь, дурачки? ведь всё уже давно написано, больше ничего делать не надо!»
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	82. "Представлены патчи для Btrfs с поддержкой алгоритма..."	–1 +/–
	Сообщение от Аноним (??) on 28-Фев-12, 14:27
	> для тебя вообще разработка — комедийный сериал, видимо. Если у разработчиков руки из задницы, то да.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	115. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 16:39
	> Если у разработчиков руки из задницы, то да. Такие масштабные выводы на песке, конечно... :)
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	54. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Клыкастый (ok) on 28-Фев-12, 00:16
	> Да я в курсе. Просто её пилят чуть ли не столько же > сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот > я думаю, это признак того, что счастье уже близко или просто > статистический выброс. на самом деле это очень хорошо. пилят - это здорово.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от ArtKun on 27-Фев-12, 17:53
Хорошо, что перенесли на F18. Летом не придется переустанавливать систему, а к Новому году можно будет таки перевести на нее все диски.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 17:55
То что Btrfs скоро будет в Fedora по умолчанию, это еще не признак того что она готова к продакшену. Да и как бы там не было, хотелось бы иметь гарантию в лице fsck, в случае проблем с ФС
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от nagual (ok) on 27-Фев-12, 18:07
	> То что Btrfs скоро будет в Fedora по умолчанию, это еще не > признак того что она готова к продакшену. Да и как бы > там не было, хотелось бы иметь гарантию в лице fsck, в > случае проблем с ФС И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ...
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–3 +/–
	Сообщение от Дворник (??) on 27-Фев-12, 18:16
	Ну как бы это помягче сказать... Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так. ;)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 18:22
	Не все ноутбуки можно легко обновлять.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	55. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Клыкастый (ok) on 28-Фев-12, 00:19
	> Не все ноутбуки можно легко обновлять. это да. с другой стороны 90% купивших ноутбуки ставят их на стол "они занимают меньше места". с учётом толковой мыши и часто клавы - больше, но ведь это мелочи. И батареи садятся через год. И ремонтопригодность не ахти. И апгрейд не особо.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Анон on 27-Фев-12, 18:34
	Это если у вас файлохранилище выделенное. А если на той системе, где куча ещё всего?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	43. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от анон on 27-Фев-12, 20:19
	> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так Это не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья. Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не справляется.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	59. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+1 +/–
	Сообщение от VoDA (ok) on 28-Фев-12, 01:12
	>> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так > Это не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья. > Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не > справляется. вам не подходит - не пользуйтесь. те, кому интересен прирост производительность, CoW или другие фишки btrfs поставят требуемое количество памяти. остальным просто стоит продолжить пользоваться ext4/
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	75. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 08:35
	> btrfs с ней не справляется. А как это проверялось? Делались какие-то бенчи? Тогда методику, версию ядер и результаты - в студию. А то ископаемости с фороникса уже давно заржавели...
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	36. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+1 +/–
	Сообщение от Аноним (??) on 27-Фев-12, 18:41
	> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ... Это подразумевается by default - за плюшки cow надо платить. Не только размером кеша, необходимого для приемлемой скорости, но и размером метаданных на диске. Пока что не созданы cow fs, лишенные этих недостатков.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	46. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от anonymous (??) on 27-Фев-12, 23:21
	Не в CoW дело. Бтрфс даже сам Линус пропиарил, что то там про "пару лет потерпите с ext4 а потом будет только одно сплошное btrfs". Было это давно, как раз тогда SSD сверхмодные были и ктото запилил поддержку особенностей SSD в btrfs. Тест ессно был шоковым по скорости, народ на этой волне впал в эйфорию и вот уже четвертый год никик понять не могут в чем прокол. НЕ поймут и в следующем году, увы. Лично мне вот просто жутко понравилось сквозные контрольные суммы, и заявленая ускоренная работа при fsync. Ну нет бабла на аппаратный рейд с батарейкой и всякие ECC RAM, я обычный домашний пользователь без особых претензий. Но вот хотелось бы знать когда данные считаные с диска протухли, причем автоматом без услилий с моей стороны и бесплатно. Причем контроль на всем пути от поверхности диска до памяти. Хорошая ведь идея, журнал Ext4 тоже переделывают под это дело, но лучше бы все данные а не только журнал. А в итоге получаешь какой то прикол, та самая фича ускоренного fsync на самом деле оказалась костылем прикрученым изолентой для маскировки плохой общей организации системы, и по факту попробуй потыкай каждый день раза 3 git fetch; git rebase на дереве исходников gcc, это же песня. Не говоря об банальном yum update. Что то я снова разошелся. Ну так на самом деле обидно, разбег на рубль удар на копейку.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	50. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 27-Фев-12, 23:43
	> Лично мне вот просто жутко понравилось сквозные контрольные суммы, и заявленая ускоренная > работа при fsync. Ну нет бабла на аппаратный рейд с батарейкой > и всякие ECC RAM, я обычный домашний пользователь без особых претензий. > Но вот хотелось бы знать когда данные считаные с диска протухли, > причем автоматом без услилий с моей стороны и бесплатно. Причем контроль > на всем пути от поверхности диска до памяти. Хорошая ведь идея, > журнал Ext4 тоже переделывают под это дело, но лучше бы все > данные а не только журнал. Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом еще в 2007 году LDIF. А на диске их целостность контролирует контроллер диска. Вообще, сквозное чексуммирование по блокам (можно и с дедупликацией), при необходимости, легко и непринужденно делается средствами device-mapper, в виде обычного блочного устройства, которое выдает read error, если сумма данного блока битая. Но вот только это никому не нужно - сколько ни чексуммируй данные, все равно остается тот уровень, когда они не защищены и возможна ошибка.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	57. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от anonymous (??) on 28-Фев-12, 00:55
	Так я то же самое и говорю, хочется чтобы оно из коробки, по умолчанию, просто скачал Федору установил и все. По дефолту даже не для упрощения моей жизни (хотя это конечно тоже), а как косвенная гарантия что не я один в одной лодке и если что то пойдет не так на форумах будет шум, и более быстрое решение. Насчет чексумм не соглашусь, это еще и бесплатная дополнительная проверка дешевого домашнего железа, с этой фичей раньше прокукарекает что блок питания сыпется и так далее.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	70. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 03:27
	> косвенная гарантия что не я один в одной лодке Поверь, в этой лодке будет как минимум половина местных через энное время :). А то что не всем дано быть тестовыми пилотами - это нормально.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	87. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 17:15
	> Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом > еще в 2007 году LDIF. А на диске их целостность контролирует > контроллер диска. Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни. Увы. > Вообще, сквозное чексуммирование по блокам (можно и с дедупликацией), при необходимости, > легко и непринужденно делается средствами device-mapper, в виде обычного блочного устройства, > которое выдает read error, если сумма данного блока битая. > Но вот > только это никому не нужно - сколько ни чексуммируй данные, все > равно остается тот уровень, когда они не защищены и возможна ошибка. Недавно новость пробегала, что в Linux md-RAID всё-таки внесли исправления на предмет определения разности прочитанных блоков в конфигурации с RAID-1 и вывода сообщения об ошибке чтения с массива. Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных? Ведь в этом случае информация о верности того или иного блока должна браться с "верхнего" уровня — уровня файловой системы. Только на файловой системе ведутся подсчёты контрольных сумм для "кластеров" (в терминах Windows, совокупности секторов носителей), то есть блоков самой ФС.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	89. "Представлены патчи для Btrfs с поддержкой алгоритма..."	–1 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 17:22
	вообще-то вылазь из подвала: data integrity вполне себе контролирует сам рейд. и он способен сказать, откуда прочитали фигню, а откуда то, что записывали.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	93. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 18:30
	> вообще-то вылазь из подвала: data integrity вполне себе контролирует сам рейд. и > он способен сказать, откуда прочитали фигню, а откуда то, что записывали. Ну-ка поподробнее. Откуда куда что контролирует.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	104. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 19:17
	> Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни. > Увы. Почему вы так любите рассуждать на темы, в которых не разбираетесь? FYI: практически все современный винчестеры имеют фактическую емкость раза в полтора больше заявленной. "Избыточное" пространство используется контроллером для помехозащитного кодирования и контроля целостности данных, включая чексуммирование по блокам. > Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных? В практике администрирования такой сбой практически невозможен, т.к. контроллер винчестера проверяет целостность данных, и выдает io error, если чексумма не совпадает с контрольной. Поэтому, чтобы данные действительно различались, необходимо останавливать массив, делать dd на один диск, и снова запускать его. А это явно уже не случайный сбой.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	105. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 19:18
	> Поэтому, чтобы данные действительно различались, необходимо останавливать > массив, делать dd на один диск, и снова запускать его. Впрочем, можно и не останавливать.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	107. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 28-Фев-12, 19:37
	>> Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни. >> Увы. > Почему вы так любите рассуждать на темы, в которых не разбираетесь? > FYI: практически все современный винчестеры имеют фактическую емкость раза в полтора больше > заявленной. "Избыточное" пространство используется контроллером для помехозащитного > кодирования и контроля целостности данных, включая чексуммирование по блокам. Угу. >> Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных? > В практике администрирования такой сбой практически невозможен, т.к. контроллер винчестера > проверяет целостность данных, и выдает io error, если чексумма не совпадает > с контрольной. Поэтому, чтобы данные действительно различались, необходимо останавливать > массив, делать dd на один диск, и снова запускать его. А > это явно уже не случайный сбой. Пример с md-RAID несколькогодичной давности: http://www.linux.org.ru/news/bsd/3262617?cid=3272939 Очевидно, вы не сталкивались с рассинхронизацией программного или аппаратного RAID, раз делаете далеко идущие выводы.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	69. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 03:22
	> Не в CoW дело. Бтрфс даже сам Линус пропиарил, что то там > про "пару лет потерпите с ext4 а потом будет только одно сплошное btrfs". ИЧСХ, примерно так и будет. > вот уже четвертый год никик понять не могут в чем прокол. > НЕ поймут и в следующем году, увы. Для тупых объясняю: большие и масштабные штуки не делаются на коленке за 20 минут. И тем более потом нужна куча летных испытаний, дабы страдали тестовые образцы, а не реальные данные. > журнал Ext4 тоже переделывают под это дело, но лучше бы все > данные а не только журнал. Ext4 как бы вообще ни о том. Обычная такая классика, лысая и без нифига. Ну на стероидах, а потому быстрая. Лучшее что можно выжать из классических технологий но не более того. Сколько воздушные шарики не тюнь, даже с моторчиком, а у самолетов параметры будут лучше. Может не сразу. Но - будут. > А в итоге получаешь какой то прикол, та самая фича ускоренного fsync > на самом деле оказалась костылем прикрученым изолентой для маскировки плохой общей > организации системы, На самом деле - CoW просто иной подход к организации размещения данных. По большому счету при недеструктивной записи fsync какая-то лишняя сущность: в случае краха данные то не теряются, всегда можно просто откатиться в вид как было до краха. Однако совместимость не отменяли, вот и приходится изгаляться. То что некоторые особо вумные аппы могут делать много fsync'ов, эмулируя какое-то подобие журналирования из ФС которые не обеспечивают нормального журнала, а апликухам надо - ну так вот ЭТО и есть КОСТЫЛИ и ПОДПОРКИ древним/дебильным ФС из-за тупорылости которых на уровень приложений вываливается то что по уму должна бы делать ОС и ее ФС... > и по факту попробуй потыкай каждый день раза 3 git fetch; git > rebase на дереве исходников gcc, это же песня. Я думаю что с этим постепенно будет порядок, потому как у разработчиков пингвина - оно самое и есть. Если у Торвальдса будет гит и будет btrfs - ну ты понял, да? Этот не будет в форуме ныть, пойдет и починит одно или другое и вправит мозг кому надо :) > Не говоря об банальном yum update. А что, он умеет не тормозить хоть на какой-то ФС? Помнится редхат как только ни изгалялся чтобы эту питоновую какашку разогнать, вплоть до сгрузки из репов готовых скулайтовых баз :) (шиза косила наши ряды) > Что то я снова разошелся. Ну так на самом деле обидно, разбег > на рубль удар на копейку. Прикольно оценивать силу удара при том что он еще не состоялся.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	111. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Genix on 28-Фев-12, 23:19
	>> Не говоря об банальном yum update. > А что, он умеет не тормозить хоть на какой-то ФС? По-моему, автор жалуется на то что мир меняется быстрее его понимания, а не то что ФС тормозит при yum update =)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	67. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 02:04
	> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) Ну вообще-то ряд моментов там сделан менее дебильно и оно будет пожалуй пошустрее ZFS если гига под кеш не нашлось. Если кому интересно, у фороникса бенчей - есть. Правда баянные.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

33. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 18:35
Кстати, оно умеет L2ARC или подобие?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 19:12
Так и когда я смогу сделать compress=lz4 ??
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	68. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 02:06
	> Так и когда я смогу сделать compress=lz4 ?? Да хоть прям ща, наложив патчи, если тебе позарез охота.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

42. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 27-Фев-12, 19:29
Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФС имели бы. Блин, почему Гансу работать запретили(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	80. "Представлены патчи для Btrfs с поддержкой алгоритма..."	+1 +/–
	Сообщение от arisu (ok) on 28-Фев-12, 12:19
	вперёд — убеждай народ, собирай энтузиастов. а если убедишь какую-нибудь контору — ещё и денег дадут.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	84. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 14:33
	> Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФС А что в ней такого современного? Разве она по фичам значительно превосходит ext? Снапшоты, сквозное чексуммирование, онлайновые ресайз и дефраг, оптимизация под SSD?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

76. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от Аноним (??) on 28-Фев-12, 11:45
а нафига в cow файловой системе fsck?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	83. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 14:30
	> а нафига в cow файловой системе fsck? В cow fs fsck нужен как и в других. Просто разработчики одной известной cow fs поленились (или не осилили) написать fsck, и придумали сказку, что оно там не нужно. С тех пор и гуляет миф в народе.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	85. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от Аноним (??) on 28-Фев-12, 16:21
	Это не ответ
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	86. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 28-Фев-12, 16:29
	Это ответ.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	94. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	–1 +/–
	Сообщение от iZEN (ok) on 28-Фев-12, 18:32
	>> а нафига в cow файловой системе fsck? > В cow fs fsck нужен как и в других. Просто разработчики одной > известной cow fs поленились (или не осилили) написать fsck, и придумали > сказку, что оно там не нужно. С тех пор и гуляет > миф в народе. scrub — это и есть fsck с другим названием.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	114. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 16:34
	> scrub — это и есть fsck с другим названием. Угу. И менее дотошный/способный к починке раздестроенного тома. Иначе сообщений типа того что на лисяре просто не возникало бы как класса.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	116. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 05-Мрт-12, 17:17
	>> scrub — это и есть fsck с другим названием. > Угу. И менее дотошный/способный к починке раздестроенного тома. Ты вообще различаешь DEGRADED и FAULTED состояния системы хранения? scrub в обычном применении лечит DEGRADED. В необычном применении — после "zpool import -F faultedpoolname" scrub может лечить FAULTED-пул, импортированный "как есть", в режиме DEGRADED, если это возможно. Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни на каком RAID кроме mirror ничего тебе не пролечит, а откажется выполняться. > Иначе сообщений типа того что на лисяре просто не возникало бы как класса. В то время для импорта FAULTED пула не было опции "-F" для автоматической пробы и отмотки состояния пула от FAULTED до DEGRADED. Сейчас эта опция ЕСТЬ. ЕСТЬ! И ты заткнёшься, наконец, а?
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	118. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 17:45
	> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни > на каком RAID кроме mirror ничего тебе не пролечит, Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально напоминает файловую систему, чем и хорош. Можно данные потом достать с порушенного диска как белый человек, а не хексэдитором выколупывать...
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	119. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 05-Мрт-12, 21:48
	>> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни >> на каком RAID кроме mirror ничего тебе не пролечит, > Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально > напоминает файловую систему, чем и хорош. Можно данные потом достать с > порушенного диска как белый человек, а не хексэдитором выколупывать... Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами. scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить не удастся, а пул станет отремонтированным. Так кто там будет лазить с hex-редактором по диску, определяя, какой файл в /lost+found откуда взялся, а? :))
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	121. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от Аноним (??) on 05-Мрт-12, 22:02
	> Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами. Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни райда и что там еще... при том чем больше - тем геморройнее ;) > scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить > не удастся, а пул станет отремонтированным. Угу, на лисяре отличный пример как он станет. Конкретно эту ситуацию конечно пролечили, а что насчет остальных? Там настолько же плохо как и было или оно теперь натурально чинить хоть что-то умеет и там теперь не только маркетинговый булшит о ненужности fsck?
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	122. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
	Сообщение от iZEN (ok) on 05-Мрт-12, 22:52
	>> Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами. > Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни > райда и что там еще... при том чем больше - тем > геморройнее ;) scrub выполняет проверку только занятого пространства. fsck выполняет проверку всего пространства, выделенного под файловую систему. Сколько времени займёт работа fsck на ОТМОНТИРОВАННОМ разделе и scrub на ИМПОРТИРОВАННОМ (считается в работе) пуле (если во время работы scrub проверяет в первую очередь те файлы, которые запрашиваются в текущий момент и оперативно реконструирует повреждения)? Думаю, что времени займёт больше та задача, у которой фронт работ больше, а именно — fsck, не обращаясь к журналу, естественно. Ещё какие аргументы будут? >> scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить >> не удастся, а пул станет отремонтированным. > Угу, на лисяре отличный пример как он станет. Конкретно эту ситуацию конечно > пролечили, а что насчет остальных? Там настолько же плохо как и > было или оно теперь натурально чинить хоть что-то умеет и там > теперь не только маркетинговый булшит о ненужности fsck? Давай и насчёт остальных поговорим. Вводная статья как раз для таких как ты: http://phpsuxx.blogspot.com/2010/09/raid-z-freebsd.html Давай сам попробуй. Я уже испытал ZFS на прочность.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

123. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."	+/–
Сообщение от iZEN (ok) on 03-Авг-17, 20:08
Btrfs всё - https://www.opennet.ru/opennews/art.shtml?num=46955 ///--- В категорию устаревших (deprecated) переведена поддержка Btrfs и FedFS (Federated File System). Файловая система Btrfs ранее позиционировались в дистрибутиве RHEL 7 как экспериментальная возможность (Technology Preview), не рекомендованная к применению в промышленных решениях. Компания Red Hat приняла решение не выводить Btrfs в разряд полностью поддерживаемых в RHEL технологий и поддержка данной ФС будет прекращена в будущем значительном выпуске RHEL 8. Что касается RHEL 7.4, то в Btrfs продолжен перенос некоторых изменений из upstream. В дальнейшем, пользователи следующих выпусков ветки RHEL 7 смогут продолжить использовать Btrfs, но изменения больше переноситься не будут. ---///
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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