Для файловой системы Btrfs были представлены (http://article.gmane.org/gmane.comp.file-systems.btrfs/15744) патчи с поддержкой алгоритма сжатия LZ4 (http://code.google.com/p/lz4/), показавшие довольно приятные результаты. LZ4 - скоростной алгоритм сжатия, как правило обгоняющий Snappy (http://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
Новость: http://www.opennet.ru/opennews/art.shtml?num=33197
Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.
> Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.Почитайте man fsck в вашей ОС, там изложены несколько иные взгляды.
> А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.Как бы тебе объяснить то? Ты будешь готов скушать далеко не любой результат работы таковой утилиты. Иногда таким утилитам "по статусу положено" принимать потенциально проблемные решения, так что вопрос о дефолтах довольно философский.
> Также отмечается о создании отдельной экспериментальной ветки в Git-репозитрии Btrfs
> ветка получила название "dangerdonteveruse"Хм. Бранч с таким названием в репе btrfs-progs лично я помню уже как минимум месяц.
Непонятно, зачем сжатие файловой системе? Хранить в два, ну почти три раза больше данных :-( данные данным рознь, не получится из этого ничего хорошего.
Всё очень просто. Храня сжатые данные, требуется меньше времени на их считывания. А учитывая, что жёсткий диск является медленным устройством, то сжатие - большой плюс!
Больше кэшей! Больших и разных.
При рандомном доступе к многотерабайтному массиву, для более-менее эффективной работы размер кэша должен быть сопоставим с размером массива. Во-первых, дорого, во-вторых, неустойчиво к сбоям. Порочность этого пути хорошо видна на примере ZFS, которая выдает приемлемую производительность только в "режиме стримера" (т.е. исключительно при линейном доступе).
Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать, потом распаковать, потом только обратиться к нужному месту. Рандомное обращение - плохой пример.
Очень сильно зависит от размера секции.
> Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать,
> потом распаковать, потом только обратиться к нужному месту. Рандомное обращение -
> плохой пример.Много-пользователей читает множество файлов. Или раздача web-статики. Получается стучимся в радномные файлы (часто малого размера). На этом как раз кэш в холостую работает, а сжатие данных очень полезно.
> Как рандомно обратиться к запакованным данным?Так же как и к остальным - никто не жмет огромные блоки. Сжатие идет небольшими кусками, чего впрочем вполне хватает для профита на рыхлых данных. Да, 7zip сожмет покруче. И даже очень. Вот только скорость... ;)
> Больше кэшей! Больших и разных.В данном случае выигрыш за счет того что меньше данных читать-писать, а алгоритм крайне быстр и может существенно обгонять накопитель.
А еще это решение является концептуальным в своем роде. Подумайте сами - с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы при этом лишь надо соблюсти соотношение скорость сжатия/распаковки со скоростью чтения/записи на носитель.
> с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмыНу вот zlib зачастую не поспевает за накопителем, т.к. 2-ступенчатый (LZ -> huffman). А вот эти алгоритмы - быстрые, распаковка такой штуки вообще напоминает немного продвинутый вариант memcpy. Поэтому обычно они (LZO, Snappy, LZ4) - шустрее. Накопители, btw, тоже на месте не стоят: появились ssd которым 6Гбит sata - мало, так что они в pci-e втыкаются. Стоят конечно конских денег, но ведь и скорость - под стать...
А как насчет LZMA ? ИМХО, кажется он совершенно пригоден для сжатия на уровне фс (ядра-то мы давно уже сжимаем им).
> А как насчет LZMA ?с дуба рухнул, штоле? скорость сжатия ужасающа, скорость разжатия ужасающа.
> А как насчет LZMA ?Хоть его и портировали на чистый си в конце концов и даже в виде годном для пихания в ядро...
1) По скорости сжатия он еще хуже zlib, потому что делался с оглядкой на максимальное сжатие.
2) При мелком размере блока разогнаться с крутым сжатием особо негде и не на чем. А жать большой блок - долго и RAM много надо...
3) По скорости распаковки он как и все LZ-based довольно ничего, но... но довольно хардкорная несимметрия скоростей сжатия и распаковки ограничивает его применение в штуках типа squashfs или сжатия ядра, где распаковка - есть, а упаковки - нет. Просто потому что упаковка может быть длительной и потребовать много ресурсов, что слегонца неприемлимо для сжатия работающего на лету.Технически кстати LZMA всего лишь развитие все тех же идей: 2-ступенчатый алгоритм, LZ-подобное сжатие которому дозволено юзать более крупный словарь чем zlib с его куцыми 32кб + марковские цепочки как вторая стадия. Жмет хорошо но медленно. Распаковывается более-менее резво (как и любой иной LZ-based). Рекордные скорости не покажет из-за двустадийности (распаковка голого LZ без второй стадии может быть крайне быстрой в силу простоты этой операции).
библиотека мошкова кашерно разместится)
Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать как-бэ 120Мб. Реально влезало на 1-2Мб больше. При малейшем сбое на винте - данные терялись чуть менее чем все.Может сейчас оно уже не так ужасно. Прогресс всетаки.
Ну, во-первых, там и в 95-98 винде сжимался вроде-как весь диск и при внешнем монтировании это дело выглядело как 1 большой файл и горстка маленьких. Тут, всё-таки, сжимаются отдельные файлы. Во-вторых, по-умолчанию там "compress highly compressible files, but back off and blacklist incompressible content".
> Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать
> как-бэ 120Мб. Реально влезало на 1-2Мб больше.Реально - зависело от того что там хранить. Понятный пень что уже сжатые жыпеги и гифы еще раз не сожмутся. А вот рыхлые текстовики, бинарники системы и прочие doom2.wad - на раз жмутся в 2-3 раза, обеспечивая вполне себе профит. Правда там алгоритм сжатия был не чемпион по скорости и потому о выигрыше в скорости речь не шла. Но с ростом мощщи проца, появлением кучи ядер и развитием скоростных алгоритмов типа того же LZ4 - появился повод вспомнить давно забытое старое еще раз. На новом технологическом уровне.
> При малейшем сбое на винте - данные терялись чуть менее чем все.
Все - не терялись, но вот утилиты починки диска реагировали на такие диски довольно странно. Вообще оно было довольно криво сделано, два набора чувствительных структур (FAT и CVFAT), и журнала опять же нет, а во времена доса - еще и защиты памяти драйвера. Так что небольшой факап программы мог порушить память драйверу сжатия и устроить довольно массовый дестрой данных на томе.
> Может сейчас оно уже не так ужасно. Прогресс всетаки.
Ну так времена ОС без защиты памяти, фс без журналирования и что там еще - закончились.
ну если не сжалось - можно и записать как есть.
ты видел сколько бдрипы стартрека занимают? в ноут такой диск пока не впихнёшь.
> ты видел сколько бдрипы стартрека занимают?во времена TOS никакого «б» не было. а остальным место в помойке.
> Непонятно, зачем сжатие файловой системе?Скорость записи и особенно чтения с столь скоростными алгоритмами может быть _быстрее_ чем скорость чтения-записи несжатых файлов. Просто потому что читать-писать меньше и если все упиралось в накопитель, ему внезапно полегчает в пару раз -> PROFIT.
"устойчива к сбоям, тем не мнее потребность в fsck вызвана возможностью появления повреждений, вызванных внешними факторами"
Типа космические архитекторы столкнулись с реальностью? Они заметили, что:
1) при их методах использования двоичных деревьев - дофига места тратится на метаинформацию.
2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе такого представить.
>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
> Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе
> такого представить.В линюкс эта фс входит в штатное ядро? Уже можно пользоваться "из коробки" и без лишних телодвижений, как extx, jfs, xfs? Что-то в том же руководстве по генту о ней ни слова...
Ой, так вы о той самой фс, у которой проблемы с лицензией под линюкс? Которая требует или патча на ядро, или использования ее в fuse? Экое счастье - оставьте его тем, кому оно надо - инвалидам на костылях. А мы btrfs прекрасно будем пользоваться ;) Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck.
> Которая требует или патча на ядро, или использования ее в fuse?zfsonlinux легко и непринужденно собирается модулем. Но зачем тащить в линукс это кривое тормозилово?
> Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck.
Да, ZFS при сбоях данные убивает надежно и намертво.
А ее разработчики zfschk не осилили, поэтому придумывают сказки, что оно не нужно.
> Да, ZFS при сбоях данные убивает надежно и намертво.Что вы врёте и не краснеете?
При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F" и scrub'а может быть живым, лишившись лишь части файлов - http://forum.ixbt.com/topic.cgi?id=11:43009-163#4797
> При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F" и scrub'а может быть живым, лишившись лишь части файловТеоретики, такие теоретики...
практики куда круче
> Теоретики, такие теоретики...Дык, практики. Всё опробовано и выяснено на деле.
> Дык, практики. Всё опробовано и выяснено на деле.Если вы думаете, что fsck на ZFS не нужен, значит, вы не сталкивались на практике со сбоями в ZFS.
>> Дык, практики. Всё опробовано и выяснено на деле.
> Если вы думаете, что fsck на ZFS не нужен, значит, вы не
> сталкивались на практике со сбоями в ZFS.Я сталкивался со сбоями ZFS. После scrub'а повреждённого пула у меня был список невосстановимых файлов. Сам пул был приведён в рабочее состояние.
> Метаинформация многократно дублируется.а я покупал диски, чтобы данные хранить, а не «метаинформацию»…
> а я покупал диски, чтобы данные хранить, а не «метаинформацию»…Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;)
>> а я покупал диски, чтобы данные хранить, а не «метаинформацию»…
> Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много.
> ;)а в zfs мало, и та через libastral добывается, места не занимает.
> Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;)А в ZFS ее столько же, плюс еще она дублируется 100500 раз (хотят толку от этого, если копии не консистентны). Так что места под данные не остается вообще =)
> хотят толку от этого, если копии не консистентныОткуда вы это знаете? Где проходили? В ZFS 128k-блоки (по умолчанию) данных и метаданных имеют контрольную сумму (алгоритм подсчёта контрольных сумм — свойство конкретной ФС в пуле, можно выбрать). Если, допустим, с пула читаются данные, то каждый блок подвергается проверке на предмет целостности. Если блок повреждён, то ZFS на лету пробует перечитать и восстановить его в случае с отказоустойчивым пулом, а в случае с неотказоустойчивым — рапортует об ошибке чтения файла или метаданных. При повреждении всех синхронных копий метаданных работа с пулом прекращается.
scrub сканирует метаданные и данные (не весь объём ФС, а только занятый), вычисляет повреждения, восстанавливает обнаруженную неконсистентность, предоставляет полный список невосстановимых файлов с полными путями к ним.
>Этот перл адресуйте разработчикам 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опять врёшь.
>>Этот перл адресуйте разработчикам 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/
+1У меня бтр под Linux 98 ваще летает, а ZFS ацтой, постоянно глючил на дискетах 1.44".
А чтож ты, деточка, не представился? Засцал с izen'ом в открытую поговорить?))))
Вот только Б-дерево - не двоичное. Но кого это волнует?..
> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны...
>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
> Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны...Кактус ли это?
> Кактус ли это?Лично мне кажется, что склонная к неожиданным смертям файлуха без fsck - явный кактус. Поэтому на ZFS не рвусь.
У вас, конечно, может быть другое мнение =)
>> Кактус ли это?
> Лично мне кажется, что склонная к неожиданным смертям файлуха без fsck -
> явный кактус. Поэтому на ZFS не рвусь.
> У вас, конечно, может быть другое мнение =)http://www.opennet.ru/openforum/vsluhforumID3/83275.html#94
Что-то часто про БТР в последнее время слышно...
Аха, к 14 февраля обещали релиз btrfs.fsck. Сегодня 27 :)
Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта (ну на крайняк к 9 мая).
> Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта
> (ну на крайняк к 9 мая).Вопрос только, какого года? Явно, что не этого.
> Вопрос только, какого года? Явно, что не этого.Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади.
> Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади.Да, к 70-му юбилею. Ну в крайнем случае к 75-му.
Это будет боевая ФС для ОБЧР!
Да я в курсе. Просто её пилят чуть ли не столько же сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот я думаю, это признак того, что счастье уже близко или просто статистический выброс.
Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :)
> Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :)Лично для меня разработка btrfs - это такой комедийный сериал, по длительности сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим", посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid.
> Лично для меня разработка btrfs - это такой комедийный сериал, по длительности
> сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим",
> посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid."Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..."
> "Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..."Это не про разработку btrfs.
Про разработку btrfs будет так: "Сначала над вами смеются, потом над вами смеются, а потом над вами смеются снова..."
> смеются, а потом над вами смеются снова..."Вам бы этого хотелось, да? Ну чтож, мечтайте, это не вредно :)
для тебя вообще разработка — комедийный сериал, видимо. «и что вы мучаетесь, дурачки? ведь всё уже давно написано, больше ничего делать не надо!»
> для тебя вообще разработка — комедийный сериал, видимо.Если у разработчиков руки из задницы, то да.
> Если у разработчиков руки из задницы, то да.Такие масштабные выводы на песке, конечно... :)
> Да я в курсе. Просто её пилят чуть ли не столько же
> сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот
> я думаю, это признак того, что счастье уже близко или просто
> статистический выброс.на самом деле это очень хорошо. пилят - это здорово.
Хорошо, что перенесли на F18. Летом не придется переустанавливать систему, а к Новому году можно будет таки перевести на нее все диски.
То что Btrfs скоро будет в Fedora по умолчанию, это еще не признак того что она готова к продакшену. Да и как бы там не было, хотелось бы иметь гарантию в лице fsck, в случае проблем с ФС
> То что Btrfs скоро будет в Fedora по умолчанию, это еще не
> признак того что она готова к продакшену. Да и как бы
> там не было, хотелось бы иметь гарантию в лице fsck, в
> случае проблем с ФСИ почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ...
Ну как бы это помягче сказать... Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так. ;)
Не все ноутбуки можно легко обновлять.
> Не все ноутбуки можно легко обновлять.это да. с другой стороны 90% купивших ноутбуки ставят их на стол "они занимают меньше места". с учётом толковой мыши и часто клавы - больше, но ведь это мелочи. И батареи садятся через год. И ремонтопригодность не ахти. И апгрейд не особо.
Это если у вас файлохранилище выделенное. А если на той системе, где куча ещё всего?
> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не такЭто не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья.
Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не справляется.
>> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так
> Это не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья.
> Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не
> справляется.вам не подходит - не пользуйтесь.
те, кому интересен прирост производительность, CoW или другие фишки btrfs поставят требуемое количество памяти. остальным просто стоит продолжить пользоваться ext4/
> btrfs с ней не справляется.А как это проверялось? Делались какие-то бенчи? Тогда методику, версию ядер и результаты - в студию. А то ископаемости с фороникса уже давно заржавели...
> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ...Это подразумевается by default - за плюшки cow надо платить. Не только размером кеша, необходимого для приемлемой скорости, но и размером метаданных на диске.
Пока что не созданы cow fs, лишенные этих недостатков.
Не в CoW дело. Бтрфс даже сам Линус пропиарил, что то там про "пару лет потерпите с ext4 а потом будет только одно сплошное btrfs". Было это давно, как раз тогда SSD сверхмодные были и ктото запилил поддержку особенностей SSD в btrfs. Тест ессно был шоковым по скорости, народ на этой волне впал в эйфорию и вот уже четвертый год никик понять не могут в чем прокол. НЕ поймут и в следующем году, увы.Лично мне вот просто жутко понравилось сквозные контрольные суммы, и заявленая ускоренная работа при fsync. Ну нет бабла на аппаратный рейд с батарейкой и всякие ECC RAM, я обычный домашний пользователь без особых претензий. Но вот хотелось бы знать когда данные считаные с диска протухли, причем автоматом без услилий с моей стороны и бесплатно. Причем контроль на всем пути от поверхности диска до памяти. Хорошая ведь идея, журнал Ext4 тоже переделывают под это дело, но лучше бы все данные а не только журнал.
А в итоге получаешь какой то прикол, та самая фича ускоренного fsync на самом деле оказалась костылем прикрученым изолентой для маскировки плохой общей организации системы, и по факту попробуй потыкай каждый день раза 3 git fetch; git rebase на дереве исходников gcc, это же песня. Не говоря об банальном yum update.
Что то я снова разошелся. Ну так на самом деле обидно, разбег на рубль удар на копейку.
> Лично мне вот просто жутко понравилось сквозные контрольные суммы, и заявленая ускоренная
> работа при fsync. Ну нет бабла на аппаратный рейд с батарейкой
> и всякие ECC RAM, я обычный домашний пользователь без особых претензий.
> Но вот хотелось бы знать когда данные считаные с диска протухли,
> причем автоматом без услилий с моей стороны и бесплатно. Причем контроль
> на всем пути от поверхности диска до памяти. Хорошая ведь идея,
> журнал Ext4 тоже переделывают под это дело, но лучше бы все
> данные а не только журнал.Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом еще в 2007 году LDIF. А на диске их целостность контролирует контроллер диска.
Вообще, сквозное чексуммирование по блокам (можно и с дедупликацией), при необходимости, легко и непринужденно делается средствами device-mapper, в виде обычного блочного устройства, которое выдает read error, если сумма данного блока битая. Но вот только это никому не нужно - сколько ни чексуммируй данные, все равно остается тот уровень, когда они не защищены и возможна ошибка.
Так я то же самое и говорю, хочется чтобы оно из коробки, по умолчанию, просто скачал Федору установил и все. По дефолту даже не для упрощения моей жизни (хотя это конечно тоже), а как косвенная гарантия что не я один в одной лодке и если что то пойдет не так на форумах будет шум, и более быстрое решение.Насчет чексумм не соглашусь, это еще и бесплатная дополнительная проверка дешевого домашнего железа, с этой фичей раньше прокукарекает что блок питания сыпется и так далее.
> косвенная гарантия что не я один в одной лодкеПоверь, в этой лодке будет как минимум половина местных через энное время :). А то что не всем дано быть тестовыми пилотами - это нормально.
> Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом
> еще в 2007 году LDIF. А на диске их целостность контролирует
> контроллер диска.Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни. Увы.
> Вообще, сквозное чексуммирование по блокам (можно и с дедупликацией), при необходимости,
> легко и непринужденно делается средствами device-mapper, в виде обычного блочного устройства,
> которое выдает read error, если сумма данного блока битая.
> Но вот
> только это никому не нужно - сколько ни чексуммируй данные, все
> равно остается тот уровень, когда они не защищены и возможна ошибка.Недавно новость пробегала, что в Linux md-RAID всё-таки внесли исправления на предмет определения разности прочитанных блоков в конфигурации с RAID-1 и вывода сообщения об ошибке чтения с массива. Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных? Ведь в этом случае информация о верности того или иного блока должна браться с "верхнего" уровня — уровня файловой системы. Только на файловой системе ведутся подсчёты контрольных сумм для "кластеров" (в терминах Windows, совокупности секторов носителей), то есть блоков самой ФС.
вообще-то вылазь из подвала: data integrity вполне себе контролирует сам рейд. и он способен сказать, откуда прочитали фигню, а откуда то, что записывали.
> вообще-то вылазь из подвала: data integrity вполне себе контролирует сам рейд. и
> он способен сказать, откуда прочитали фигню, а откуда то, что записывали.Ну-ка поподробнее. Откуда куда что контролирует.
> Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни.
> Увы.Почему вы так любите рассуждать на темы, в которых не разбираетесь?
FYI: практически все современный винчестеры имеют фактическую емкость раза в полтора больше заявленной. "Избыточное" пространство используется контроллером для помехозащитного кодирования и контроля целостности данных, включая чексуммирование по блокам.> Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных?
В практике администрирования такой сбой практически невозможен, т.к. контроллер винчестера проверяет целостность данных, и выдает io error, если чексумма не совпадает с контрольной. Поэтому, чтобы данные действительно различались, необходимо останавливать массив, делать dd на один диск, и снова запускать его. А это явно уже не случайный сбой.
> Поэтому, чтобы данные действительно различались, необходимо останавливать
> массив, делать dd на один диск, и снова запускать его.Впрочем, можно и не останавливать.
>> Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни.
>> Увы.
> Почему вы так любите рассуждать на темы, в которых не разбираетесь?
> FYI: практически все современный винчестеры имеют фактическую емкость раза в полтора больше
> заявленной. "Избыточное" пространство используется контроллером для помехозащитного
> кодирования и контроля целостности данных, включая чексуммирование по блокам.Угу.
>> Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных?
> В практике администрирования такой сбой практически невозможен, т.к. контроллер винчестера
> проверяет целостность данных, и выдает io error, если чексумма не совпадает
> с контрольной. Поэтому, чтобы данные действительно различались, необходимо останавливать
> массив, делать dd на один диск, и снова запускать его. А
> это явно уже не случайный сбой.Пример с md-RAID несколькогодичной давности:
http://www.linux.org.ru/news/bsd/3262617?cid=3272939Очевидно, вы не сталкивались с рассинхронизацией программного или аппаратного RAID, раз делаете далеко идущие выводы.
> Не в CoW дело. Бтрфс даже сам Линус пропиарил, что то там
> про "пару лет потерпите с ext4 а потом будет только одно сплошное btrfs".ИЧСХ, примерно так и будет.
> вот уже четвертый год никик понять не могут в чем прокол.
> НЕ поймут и в следующем году, увы.Для тупых объясняю: большие и масштабные штуки не делаются на коленке за 20 минут. И тем более потом нужна куча летных испытаний, дабы страдали тестовые образцы, а не реальные данные.
> журнал Ext4 тоже переделывают под это дело, но лучше бы все
> данные а не только журнал.Ext4 как бы вообще ни о том. Обычная такая классика, лысая и без нифига. Ну на стероидах, а потому быстрая. Лучшее что можно выжать из классических технологий но не более того. Сколько воздушные шарики не тюнь, даже с моторчиком, а у самолетов параметры будут лучше. Может не сразу. Но - будут.
> А в итоге получаешь какой то прикол, та самая фича ускоренного fsync
> на самом деле оказалась костылем прикрученым изолентой для маскировки плохой общей
> организации системы,На самом деле - CoW просто иной подход к организации размещения данных. По большому счету при недеструктивной записи fsync какая-то лишняя сущность: в случае краха данные то не теряются, всегда можно просто откатиться в вид как было до краха. Однако совместимость не отменяли, вот и приходится изгаляться. То что некоторые особо вумные аппы могут делать много fsync'ов, эмулируя какое-то подобие журналирования из ФС которые не обеспечивают нормального журнала, а апликухам надо - ну так вот ЭТО и есть КОСТЫЛИ и ПОДПОРКИ древним/дебильным ФС из-за тупорылости которых на уровень приложений вываливается то что по уму должна бы делать ОС и ее ФС...
> и по факту попробуй потыкай каждый день раза 3 git fetch; git
> rebase на дереве исходников gcc, это же песня.Я думаю что с этим постепенно будет порядок, потому как у разработчиков пингвина - оно самое и есть. Если у Торвальдса будет гит и будет btrfs - ну ты понял, да? Этот не будет в форуме ныть, пойдет и починит одно или другое и вправит мозг кому надо :)
> Не говоря об банальном yum update.
А что, он умеет не тормозить хоть на какой-то ФС? Помнится редхат как только ни изгалялся чтобы эту питоновую какашку разогнать, вплоть до сгрузки из репов готовых скулайтовых баз :) (шиза косила наши ряды)
> Что то я снова разошелся. Ну так на самом деле обидно, разбег
> на рубль удар на копейку.Прикольно оценивать силу удара при том что он еще не состоялся.
>> Не говоря об банальном yum update.
> А что, он умеет не тормозить хоть на какой-то ФС?По-моему, автор жалуется на то что мир меняется быстрее его понимания, а не то что ФС тормозит при yum update =)
> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-))Ну вообще-то ряд моментов там сделан менее дебильно и оно будет пожалуй пошустрее ZFS если гига под кеш не нашлось. Если кому интересно, у фороникса бенчей - есть. Правда баянные.
Кстати, оно умеет L2ARC или подобие?
Так и когда я смогу сделать compress=lz4 ??
> Так и когда я смогу сделать compress=lz4 ??Да хоть прям ща, наложив патчи, если тебе позарез охота.
Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФС имели бы. Блин, почему Гансу работать запретили(
вперёд — убеждай народ, собирай энтузиастов. а если убедишь какую-нибудь контору — ещё и денег дадут.
> Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФСА что в ней такого современного? Разве она по фичам значительно превосходит ext? Снапшоты, сквозное чексуммирование, онлайновые ресайз и дефраг, оптимизация под SSD?
а нафига в cow файловой системе fsck?
> а нафига в cow файловой системе fsck?В cow fs fsck нужен как и в других. Просто разработчики одной известной cow fs поленились (или не осилили) написать fsck, и придумали сказку, что оно там не нужно. С тех пор и гуляет миф в народе.
Это не ответ
Это ответ.
>> а нафига в cow файловой системе fsck?
> В cow fs fsck нужен как и в других. Просто разработчики одной
> известной cow fs поленились (или не осилили) написать fsck, и придумали
> сказку, что оно там не нужно. С тех пор и гуляет
> миф в народе.scrub — это и есть fsck с другим названием.
> scrub — это и есть fsck с другим названием.Угу. И менее дотошный/способный к починке раздестроенного тома. Иначе сообщений типа того что на лисяре просто не возникало бы как класса.
>> scrub — это и есть fsck с другим названием.
> Угу. И менее дотошный/способный к починке раздестроенного тома.Ты вообще различаешь DEGRADED и FAULTED состояния системы хранения?
scrub в обычном применении лечит DEGRADED.
В необычном применении — после "zpool import -F faultedpoolname" scrub может лечить FAULTED-пул, импортированный "как есть", в режиме DEGRADED, если это возможно.
Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни на каком RAID кроме mirror ничего тебе не пролечит, а откажется выполняться.> Иначе сообщений типа того что на лисяре просто не возникало бы как класса.
В то время для импорта FAULTED пула не было опции "-F" для автоматической пробы и отмотки состояния пула от FAULTED до DEGRADED. Сейчас эта опция ЕСТЬ. ЕСТЬ! И ты заткнёшься, наконец, а?
> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни
> на каком RAID кроме mirror ничего тебе не пролечит,Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально напоминает файловую систему, чем и хорош. Можно данные потом достать с порушенного диска как белый человек, а не хексэдитором выколупывать...
>> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни
>> на каком RAID кроме mirror ничего тебе не пролечит,
> Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально
> напоминает файловую систему, чем и хорош. Можно данные потом достать с
> порушенного диска как белый человек, а не хексэдитором выколупывать...Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.
scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить не удастся, а пул станет отремонтированным. Так кто там будет лазить с hex-редактором по диску, определяя, какой файл в /lost+found откуда взялся, а? :))
> Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни райда и что там еще... при том чем больше - тем геморройнее ;)
> scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить
> не удастся, а пул станет отремонтированным.Угу, на лисяре отличный пример как он станет. Конкретно эту ситуацию конечно пролечили, а что насчет остальных? Там настолько же плохо как и было или оно теперь натурально чинить хоть что-то умеет и там теперь не только маркетинговый булшит о ненужности fsck?
>> Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.
> Лучше так чем хексэдитором, самолично разгребая еще и фрагментацию, декомпрессию, уровни
> райда и что там еще... при том чем больше - тем
> геморройнее ;)scrub выполняет проверку только занятого пространства. fsck выполняет проверку всего пространства, выделенного под файловую систему. Сколько времени займёт работа fsck на ОТМОНТИРОВАННОМ разделе и scrub на ИМПОРТИРОВАННОМ (считается в работе) пуле (если во время работы scrub проверяет в первую очередь те файлы, которые запрашиваются в текущий момент и оперативно реконструирует повреждения)? Думаю, что времени займёт больше та задача, у которой фронт работ больше, а именно — fsck, не обращаясь к журналу, естественно.
Ещё какие аргументы будут?
>> scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить
>> не удастся, а пул станет отремонтированным.
> Угу, на лисяре отличный пример как он станет. Конкретно эту ситуацию конечно
> пролечили, а что насчет остальных? Там настолько же плохо как и
> было или оно теперь натурально чинить хоть что-то умеет и там
> теперь не только маркетинговый булшит о ненужности fsck?Давай и насчёт остальных поговорим. Вводная статья как раз для таких как ты: http://phpsuxx.blogspot.com/2010/09/raid-z-freebsd.html
Давай сам попробуй. Я уже испытал ZFS на прочность.
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, но изменения больше переноситься не будут.
---///