В рамках подготовки к выпуску ядра Linux 3.8, в файловой системе Btrfs ожидается (https://lkml.org/lkml/2012/12/17/431) ряд улучшений. Кроме всего прочего, внесен ряд патчей, нацеленных на увеличение производительности. Также отмечается, что на этой неделе будут опубликованы патчи с поддержкой RAID уровней 5 и 6.
Наиболее интересные моменты в pull-request (https://lkml.org/lkml/2012/12/17/431) от Криса Мэйсона (Chris Mason):- По числу строк кода всех остальных опережает Стефан (Stefan), добавивший возможность замены диска в процессе эксплуатации. Данный вариант заметно отличается от нормальной процедуры замены диска, используемой при администрировании btrfs, в частности работает гораздо быстрее.
- Джозеф (Josef) работал над производительностью синхронной записи. В текущий pull request не был включен патч DIO_OWN_WAITING, обсуждавшийся в списке рассылки, однако включено много других изменений, снижающие задержки и нагрузку на процессор от системных вызовов fsync и записей с флагом O_DIRECT.
- Мяо Кси (Miao Xie) внес множество исправлений и постарался разнести неупорядоченные операции по бОльшему количеству процессоров, что должно ускорить работу файловой системы в ряде случаев.
- Сам Крис внес исправления, касающиеся обработки ошибок в случае коллизий хэшей. Данные исправления также будут бэкпортированы в другие стабильные ядра и выпущены по мере завершения тестирования.
- Патч с поддержкой RAID5 и 6 перебазируется относительно нового кода замены устройств. Ожидается что он будет готов и представлен в пятницу.В дальнейшем Крис очень приветствует работу над улучшением скорости работы файловой системы, так как он видел различные тесты производительности и констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4. Кроме того, на повестке дня актуальным вопросом остается полное исправление коллизий кэшей, так как потенциально это позволяет (https://www.opennet.ru/opennews/art.shtml?num=35593) проводить атаки для вызова отказа в обслуживании.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTI1NTY
Новость: https://www.opennet.ru/opennews/art.shtml?num=35636
С переизбытком мета-данных на мелких файлах что-нибудь решили?
А что с ним надо решать? Создаете нулевые файлы и у вас на ФС кончается место хотя кроме метаданных на томе вообще ничего нет. Решайте, ага :)
> С переизбытком мета-данных на мелких файлах что-нибудь решили?А что можно "решить" против простой арифметики? Файл - это не только его содержимое, но и метаданные о нем - как минимум имя и расположение. Поэтому _любую_ ФС можно зафлудить файлами нулевого размера так, что метаданные займут все доступное место (кроме тех случаев, когда, например, иноды закончатся раньше - но бтру это не грозит).
имя в юинксах не является метаданным файла
> имя в юинксах не является метаданным файлаКто вам это сказал? Дайте ему в бубен за вранье. Метаданные на файловой системе - все что не относится к данным файла и хранится где-то сбоку. Имя, размер, даты создания/модификации/доступа, ... , атрибуты, фактическая адресация размещения, ... - все это метаданные. К данным файла не относятся но хранятся где-то сбоку по поводу существования некоего файла.
> Метаданные на файловой системе... _в_ файловой системе ...
> все что не относится к данным файла и хранится где-то сбоку
заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним. Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки на файл.
> заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные
> файла в юниксовых ФС всё, что можно прикрепить к inode и
> хранить вместе с ним. Имя таковым атрибутом не является (в отличие
> от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки
> на файл.а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?
> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?Более того, тот же posix вообще IIRC никак не регламентирует как именно ФС должна хранить сведения о файле и опсание его размещения. По поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :)
>> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?
> Более того, тот же posix вообще IIRC никак не регламентирует как именно
> ФС должна хранить сведения о файле и опсание его размещения. По
> поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :)а причем тут posix? и ответов на вопросы как не было так и нет.
> а причем тут posix?При том что апломб относительно "а вот так расово верно, а остальные - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы куда-то слинял.
> и ответов на вопросы как не было так и нет.
А это пусть гипножаб и отвечает. Никто не заставлял его умничать.
>> а причем тут posix?
> При том что апломб относительно "а вот так расово верно, а остальные
> - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный
> гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем
> кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы
> куда-то слинял.
>> и ответов на вопросы как не было так и нет.
> А это пусть гипножаб и отвечает. Никто не заставлял его умничать.а... ну да, все верно.
Внезапно да. На один inode может быть несколько жёстких ссылок.
Подробнее тут: http://ru.wikipedia.org/wiki/Inode
> ... _в_ файловой системе ...Ну это пусть граммар-наци докапываются. Вас они вообще просто обязаны расстрелять из пулемета. За пренебрежение заглавными буквами.
>> все что не относится к данным файла и хранится где-то сбоку
> заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке.
> Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним.А то что нельзя прикрепить к иноде - это тогда что? То-есть, по вашему, структуры ФС метаданными не являются? Круто, а что же это тогда по вашему? И как вы это называете? :)
> Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС).
Для тех кто тормозит, сообщаю: я имею в виду под метаданными вообще все что как-то относится к некоему файлу, его адресации и работе с ним, но не является непосредственно его данными. Т.е. по сути некий технический оверхед, возникающий из-за необходимости хранить ряд сведений, как-то адресовать доступ к этой сущности и так далее. Это вообще никак не относится к типу операционки или чему там еще. Они это могут делать слегка по разному. На мое определение что я понимаю под метаданными это не влияет.
Но если хотите, мы займемся делением на ноль. Берем расово-неверную ОС. Ну там винды, допустим. Цепляем там драйвером типа ext2fsd ext4, с инодами и все такое. А теперь расскажите: где ваш бог теперь? :)
> Имя в нашем случае это атрибут ссылки на файл.
До балды. Грубо говоря я разделяю то что есть на ФС на 2 класса сущностей: данные - это непосредственно данные файла. И метаданные - это вообще все остальное. Мне до балды как именно оно там внутрях реализовано. Я называю метаданными вообще все структуры которые будут скроены по поводу "создан файл".
> имя в юинксах не является метаданным файлаЧто, правда?
Значит, имя файла - это просто данные?
>> имя в юинксах не является метаданным файла
> Что, правда?
> Значит, имя файла - это просто данные?Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.
> Да, это так. Фактически папка - это файл со списком ссылочных структур,
> где содержится имя файла и индексный дескриптор.Фактически, никто не обязывает файловую систему хранить "папку" в именно указанном виде.
И кстати в современных ФС директории как правило проиндексированы в неких деревьях для более быстрого лукапа. Ибо просто список начинает невъ....нно тормозить когда надо работать с большим числом элементов в оном.
> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода df?
>> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.
> И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода
> df?Как посмотреть размер:
:~# ls -lhd /var
drwxr-xr-x 25 root root 4.0K Dec 26 02:43 /var
Только в данном случае речь не об этом, а о горе внутренних структур...
> Только в данном случае речь не об этом, а о горе внутренних
> структур...Об этом, об этом.
Насколько я помню, там было две проблемы:
1) служебных данных очень много в силу сложности самой структуры FS
2) кривые алгоритмы балансировки, оставляющие кучу почти пустых нод в дереве.Что фиксили, что нет - понятия не имею.
нет таких проблем.дерево портежей спокойно в 620mb вмещается. К слову, на ext4 ему раздела на 1GB сильно недостаточно!
# df -h /usr/portage
Filesystem Size Used Avail Use% Mounted on
/dev/md0p4 1.1G 622M 171M 79% /media/misc/portage# du -hs /usr/portage/
632M /usr/portage/# find /usr/portage/ -type f|wc -l -
136372 -# btrfs fi df /usr/portage
Data: total=315.69MB, used=145.57MB
System, DUP: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=341.06MB, used=237.75MB
Metadata: total=8.00MB, used=0.00как видно почти полторы сотни тысяч мелких файлов вполне отлично разместились. размер занятого места примерно равен суммарному весу файлов.
близкий результат выдавал тока reiser4 c compress=lzo1 и tail packing. p/s он всё же был экономнее и быстрее, жаль не поддержали(
сжатие на бтр-е стоит?
> сжатие на бтр-е стоит?да, zlib) и nodesize = 16k
всего влезло 830mb на раздел в 1024mb:
# df -h /usr/portage/
Filesystem Size Used Avail Use% Mounted on
/dev/md0p4 1.1G 826M 134M 87% /media/misc/portage# btrfs fi df /usr/portage
Data: total=315.69MB, used=182.07MB
System, DUP: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=341.06MB, used=321.91MB
Metadata: total=8.00MB, used=0.00попытка повторить эксперимент, поиграться с metadata_ratio успеха не принесла. опция тупо ничего не изменила.
опция --mixed mix metadata and data together даст больше объёма для данных, но ценой скорости, ощутимой на глаз.
> сжатие на бтр-е стоит?на свежую голову понял что чтото не так..
оказалось опция nodatacow отключает сжатие. и значит выше результаты без сжатия.
вот с сжатие, картинка намного приятней
mkfs.btrfs -L Portage -l 32k -n 32k /dev/md0p4
mount -o rw,noatime,nodiratime,nodatasum,noacl,space_cache,metadata_ratio=4,compress=lzo /dev/disk/by-label/Portage /usr/portage
cd /usr/ && time tar -xf /portage-latest.tar.xz
df -hm /usr/portage/
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/md0p4 1026 457 402 54% /media/misc/portagebtrfs fi df /usr/portage
Data: total=315.69MB, used=83.21MB
System, DUP: total=8.00MB, used=32.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=256.38MB, used=186.44MB
Metadata: total=8.00MB, used=0.00
К 3.9 можно будет попробовать ) Дожить бы ))
В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)
Оно либо сдохнет за ненадобностью, либо стабилизируется!Вроде скоро у Убунты десятилетие будет... :)
КЭП же! БОЛЬШИМИ БУКОВАМИ! :)
> БУКОВАМИFAIL.
> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)...при условии что ты МакЛауд и живешь вечно - замечательный вариант.
>> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)
> ...при условии что ты МакЛауд и живешь вечно - замечательный вариант.Ну а чё,
Linux ушёл в массы с версии 2.6.9, вроде 2004 год.
StarOffice/OpenOffice -> Ваще жуть, лет 20 раскручивался.
Vmware c 5-ой версии,
Apache
Netscape/Firefox
Qemu->KVM - c 2006 года.
bash со второй версии.
...
Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что копошение в начале пути всего лишь затишье перед экспоненциальным ростом.
> Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что
> копошение в начале пути всего лишь затишье перед экспоненциальным ростом.Дык, об этом и речь. Кстати, экспонента может быть и в другую сторону. (см. Openmoko)
> Linux ушёл в массы с версии 2.6.9, вроде 2004 год.Гм, даже я видел 2.4 кернелы. Хоть я и весьма поздно обратил внимание на линь.
> StarOffice/OpenOffice -> Ваще жуть, лет 20 раскручивался.
Ну это спасибо саням и ко. Оно ж проприетарью было и загнулось от натиска конкурента. Ожило лишь когда сорцы открыли и MS всех достал.
> Vmware c 5-ой версии,
ЛПП, я 3-ю версию видел в коммерческой эксплуатации. Хотя кто-то и по сей день виртуалки не признает. Ну там бсдшники всякие.
> Apache
И где он развивался 10 лет? За время его развития появился нжинкс, который его теперь и выпиливает, куда и дорога, если честно :)
> Netscape/Firefox
Опять же - проприетарью было. Околело. Реанимировалось после открытия сорса.
> Qemu->KVM - c 2006 года.
У тебя проблемы с математикой? Возьми калькулятор, 10 лет никак не получается. А я им уже всерьех пользуюсь пару лет наверное. Пашет. Никак 10 лет не выходит.
> bash со второй версии....
Не, ну если хочется послоупочить - можно до сих пор на конке ездить. Но зачем?
>> Linux ушёл в массы с версии 2.6.9, вроде 2004 год.
> Гм, даже я видел 2.4 кернелы. Хоть я и весьма поздно обратил
> внимание на линь.Я с версии 1.2, заменил полностью вянду с 2.0.33 и чё?!
Драйверов вааще не было: SVGA/ne2000/ide-generic и всё счастье!>> Vmware c 5-ой версии,
> ЛПП, я 3-ю версию видел в коммерческой эксплуатации.1.0 юзал, но страшно. :)
>> Qemu->KVM - c 2006 года.
> У тебя проблемы с математикой? Возьми калькулятор, 10 лет никак не получается.В 2006 KVM в ядро всунули, в 2.6.18 вроде, там и полетело...
...А ещё у меня где-то на диске, валяется Photoshop 3.0 for Linux и Corel Draw 3.5 for Linux :-P
---
Во, нашёл!
Photoshop 3.0 for Linux (libc5, Motif) http://pavlinux.ru/soft/lin-ps30.zip
Corel Draw 3.5 for Linux (libc5, Motif, RPM 1.0) http://pavlinux.ru/soft/corel-3.5-1.i386.rpm
К 4.0
> К 3.9 можно будет попробовать ) Дожить бы ))Что-то вы пессимист прямо. Вас там что, гопы с битами ждут, чтоли - каждый день как война? Ядра шлепают раз в 2-3 месяца и 3.9 будет менее чем через полгода.
конец света же ))
А некоторые гопы - даже с байтами.
Гоповский байт тоже состоит из восьми бит?
Это смотря сколько "а если найдут"
> А некоторые гопы - даже с байтами.Шестирукая Шива завистливо смотрит на столь удачливых гопов :)
Хм, я бы ещё как минимум версию-другую подождал. Судя по эпичности бага с коллизиями серьёзного тестирования ещё вообще не было. А киллер фич (не чтобы "удобнее", а то, без чего жить нельзя) как-то не видно, так что спешить особой необходимости нет.
> Судя по эпичности бага с коллизиями серьёзного тестирования ещё вообще не было.Такой баг практически нереально выловить при тестировании. Только аудит. Именно так его и выловили.
> А киллер фич (не чтобы "удобнее", а то, без чего жить нельзя) как-то не видно
Нужно обладать очень плохим зрением, чтобы не видеть снапшоты.
> Нужно обладать очень плохим зрением, чтобы не видеть снапшоты.И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит пониже спины от осознания что ты только что @#$нул работу за неделю - так сразу и приходит осознание зачем нужны снапшоты xD.
> И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить
> "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит
> пониже спины от осознания что ты только что @#$нул работу за
> неделю - так сразу и приходит осознание зачем нужны снапшоты xD.Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов.
Снапшоты дают возможность делать бэкапы гораздо реже.С высоты пользователя ФС, умеющей снапшоты - ежедневный бэкап выглядит ничуть не привлекательнее, чем необходимость переустанавливать ОС раз в неделю.
> привлекательнее, чем необходимость переустанавливать ОС раз в неделю.Снапшоты не заменяют бэкапы, ибо если там в середине выпадет блок - оно как костяшки домино завалится по цепочке. Но возможность отмотать ошибочную операцию в прошлом, быстро и удобно - ценное свойство.
Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно вероятностям определяются и периоды обновления.
> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
> Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем
> вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно
> вероятностям определяются и периоды обновления.Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать состояние FS - вот это да.
> Терять в худшем случае данные за месяц?Учитывая ничтожную вероятность такого исхода - не страшно.
> Увольте сразу.
Ок, вы уволены. За перерасход ресурсов.
> Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать
состояние FS - вот это да.
Очень частное и специфичное применение. Под него катят даже уродские и убогие снапшоты lvm.
>> Увольте сразу.
> Ок, вы уволены. За перерасход ресурсов.Да легко. Я из одной такой конторы ушёл сам, потому что подходы задрали. Зато потом, когда всё рухнуло, на меня вышли с "помогите/спасите". Вот только связываться с оными уже не хотелось.
Да, если строить архитектуру кривыми руками - оно непременно рухнет.
И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что новая архитектура будет не такой кривой.
> Да, если строить архитектуру кривыми руками - оно непременно рухнет.
> И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что
> новая архитектура будет не такой кривой.Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали делать бэкапы, и много чего ещё. А роль действительно положительная - той организации уже нет :)
> Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали
> делать бэкапы, и много чего ещё. А роль действительно положительная -
> той организации уже нет :)Устройся в администрацию президента - от народа потом благодарность будет
> Устройся в администрацию президента - от народа потом благодарность будетМожно еще в госдуму. Тоже неплохой вариант.
>> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
>> Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем
>> вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно
>> вероятностям определяются и периоды обновления.
> Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет
> уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать
> состояние FS - вот это да.о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ данных бекапить
> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ
> данных бекапить100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял.
>> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ
>> данных бекапить
> 100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял.ты просто не видел как бекап делается неделю. да не полный бекап, а инкрементальный. с тобой разговаривать, все равно что папуасу рассказывать про снег.
> ты просто не видел как бекап делается неделюМожно поинтересоваться - чем вы так систему добили?
>> ты просто не видел как бекап делается неделю
> Можно поинтересоваться - чем вы так систему добили?какую систему и причем тут какая-то система?
> какую систему и причем тут какая-то система?LMAO, спалился.
> ты просто не видел как бекап делается неделю.Если у вас бэкап делается неделю, у меня для вас плохие новости: you are doing it wrong!
> Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов.Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча. И осознав что все изменения про...лись. И откатить не выйдет. И undelete нету. Абыдна, да! На бтр я бы просто вернулся на свежий автоснапшот и не парился. А на ext4 - попаболь, однако.
> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча.Как правильно говорил один из моих школьных преподавателей в бородатом 95 году - торопливость нужна при ловле блох.
>> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча.
> Как правильно говорил один из моих школьных преподавателей в бородатом 95 году
> - торопливость нужна при ловле блох.Воот. И с бэкапами торопиться не следует. Это же не блохи. Хватит с них и раза в год :)
> Как правильно говорил один из моих школьных преподавателей в бородатом 95 году
> - торопливость нужна при ловле блох.Ну да, однако это не отменяет того факта что наличие нескольких разных инкарнаций ФС в разных точках времени - не самая плохая штука.
Баг с колизиями похоже так и не справили..
> Баг с колизиями похоже так и не справили..Взвис - исправили. Сам алгоритм пока не меняли, да.
констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4
трыц
> констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4Видимо Крис добрел до фороникса :)
> Видимо Крис добрел до фороникса :)Я это чудо ставил для пробы, причем сделал по умолчанию настройки как ext4 так и Btrfs. Тесты примитивнейшие - удаление сорцов ядра, копирование фильмеца и папки с доками. Везде Btrfs процентов на 10-15 проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения дня сегодняшнего :-)
Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав
> проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения
> дня сегодняшнего :-)Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное свойство которое может хотеться от ФС.
> Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав
Да в общем то по тестам форониксов вполне можно делать некие выводы. А бочку на них обычно катят те фанаты, чей фетиш проиграл в пузомерке. А само по себе бенчи как бенчи. Не хуже остальных. По крайней мере, конфига - описана, что померяно и что вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.
> Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное
> свойство которое может хотеться от ФС.Да нет, я не спорю, что у него есть масса преимуществ для серверов, но мне то они как то по барабану
> Да в общем то по тестам форониксов вполне можно делать некие выводы.
> А бочку на них обычно катят те фанаты, чей фетиш проиграл
> в пузомерке. А само по себе бенчи как бенчи. Не хуже
> остальных. По крайней мере, конфига - описана, что померяно и что
> вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.Вообще то, да
> Да нет, я не спорю, что у него есть масса преимуществ для серверов,Как бы это сказать? Я и на десктопе не против иметь возможность отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял данные. А так я смогу сгонять в прошлое и исправить свои (и не только свои) ощибки. Круто же :). Да и возможность подоткнуть при нехватке места +1 диск и ребаланс на него сделать - и на десктопе имхо вполне пригодится.
> но мне то они как то по барабану
Кому как, кому как.
> Вообще то, да
Ну по крайней мере критики обычно демонстрируют еще более убогое нечто.
> Как бы это сказать? Я и на десктопе не против иметь возможность
> отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял
> данные. А так я смогу сгонять в прошлое и исправить свои
> (и не только свои) ощибки.Ну, для этого есть бэкапы и не только на другой диск. Причем при их использовании нет потери в производительности, как в btrfs
> Ну, для этого есть бэкапы и не только на другой диск.Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну и я тоже. А btrfs так может, снапшоты вытекают из его устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 секунд.
> Причем при их использовании нет потери в производительности, как в btrfs
Потеря производительности - понятие относительное. Я в курсе кто такой CoW и как с ним мирно сосуществовать, пользуясь им на мое благо а не во вред. Я с удовольствием юзану его плюсы и не попаду под минусы. Я же не изен и нагуал все-таки, которые вообще не вдупляют как это работает.
Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию (например массированное обновление софта или что-то масштабное над БД), в случае чего откатываемся единым куском. В случае успеха снапшот удаляем.
> Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию
> (например массированное обновление софта или что-то масштабное над БД), в случае
> чего откатываемся единым куском. В случае успеха снапшот удаляем.заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)
> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)То же самое - вы не получите уже в силу завязанности процедуры на расписание бэкапа.
>> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)
> То же самое - вы не получите уже в силу завязанности процедуры
> на расписание бэкапа.выполняем критичную операцию =бэкап
> выполняем критичную операцию =бэкапА вам объяснили, как вместо этого можно использовать снапшот.
>> выполняем критичную операцию =бэкап
> А вам объяснили, как вместо этого можно использовать снапшот.C потерей производительности основных операций. "Можно грибок съем, он такой красивый ? Можно , только это бледная поганка" © :-)
>>> выполняем критичную операцию =бэкап
>> А вам объяснили, как вместо этого можно использовать снапшот.
> C потерей производительности основных операций.А бэкап, значицца на ентой производительности никак не сказывается? Ну-ну...
> Можно грибок съем, он такой красивый ?
Завязывайте с грибками, сэр. Они уже явно оказали негативное влияние на ваш мозг.
> выполняем критичную операцию =бэкапВариант, но как я уже сказал, бэкапаться раз в 30 секунд вы не будете. А вот бтрфс автоснапшоты сам лепит с такой регулярностью. Ну, как точки консистентности для отката на них при крахе. Конечно в идеале можно побухтеть про то что ощибаться не надо, но в реальном мире люди все-таки ошибаются. Иначе бы в софте не было багов :)
Резервные копии делаются по расписанию или по требованию пользователя и их создание занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, одно другому не замена.Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.
> Резервные копии делаются по расписанию или по требованию пользователя и их создание
> занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением
> потенциально опасных действий (обновление, например) и создаются моментально. Очевидно,
> одно другому не замена.
> Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок,
> в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.Не замена в том плане, что за удобство платят снижением производительности. Чудес на свете не бывает - если где то сделали гуд, то только за счет того, что в другом месте сделали каку
> Не замена в том плане, что за удобство платят снижением производительности.Вам уже заметили: бэкап тоже влияет на производительность.
> Чудес на свете не бывает - если где то сделали гуд, то
> только за счет того, что в другом месте сделали какуДа нет, "бывает". Наука называется, технологии - все дела. Надеюсь, вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?
> Да нет, "бывает". Наука называется, технологии - все дела. Надеюсь,
> вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?Пока что получается ровно напротив - удобство снапшотов приводит к снижению производительности
> удобство снапшотов приводит к снижению производительностиЧто в лоб - что по лбу. Вы вообще - читаете что вам пишут?
>> удобство снапшотов приводит к снижению производительности
> Что в лоб - что по лбу. Вы вообще - читаете
> что вам пишут?В начало треда и в саму новость. Курить до просветления ☺
> В начало треда и в саму новость.Тогда зачем вы отвечаете, если коменты не читали? :)
>> В начало треда и в саму новость.
> Тогда зачем вы отвечаете, если коменты не читали? :)Кто ж виноват, что именно вы забыли. с чего вообще начиналась полемика☺
> Да нет, "бывает". Наука называется, технологии - все дела. Надеюсь,
> вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?Для качественных усилков, как ни удивительно - лучше радиолампы. Всем транзисторы хороши... но вот каку с нелинейностью всё-таки подложили :)
> но вот каку с нелинейностью всё-таки подложили :)Подложили. Но в современных экспонатах с правильно рассчитанными режимами нелинейность столь незначительна что иные факторы ее перевесят без особых проблем. А цифровая обработка сигнала на большей части пути избавляет от накопления помех свойственных аналоговой технике к тому же. По поводу чего все это ламподр@черство - обычный фетишизм. Мало чем подкрепленный технологически. Хотя для фетищистов есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает звучание? :)
> есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по
> килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает
> звучание? :)Сигнал - улучшает, звучание - на 0, за пределами слуха.
> Сигнал - улучшает,...только цифровым технологиям это улучшение сильно пофиг.
Сигнал эзернета или попал в валидный диапазон и пакет был декодирован верно, или уж не попал и пакет забракован и перепослан. Этот факт заинкрементирует соотв. счетчик, проблема с линком будет видна. А если этот счетчик все-время ноль, на кой буй чинить то что не сломано, улучшив линию на какой-то мизер, при том что сетевки и так не жаловались ни на что? В результате получается выкинутый на ветер килобакс: передача данных вообще не изменилась, а килобакс потрачен :)> звучание - на 0, за пределами слуха.
В случае эзернета - пардон, изменений будет вообще ноль. В случае ламп - да там тоже смотреть надо. Например лампы довольно хлипкие и какая-нибудь вибрация на раз будет трясти электроды, вызывая паразитную модуляцию, например. Но ясен фиг ушибленные аудиофилы не замеряют суммарные искажения и улучшения от применения ламп. Их в индустрии просто методично доят, намного круче чем многих других :)
> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну
> и я тоже. А btrfs так может, снапшоты вытекают из его
> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30
> секунд.2 раза в сутки, и, честно говоря, мне этого вполне хватает, что не иметь постоянных лулзов с меньшей производительностью
>> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну
>> и я тоже. А btrfs так может, снапшоты вытекают из его
>> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30
>> секунд.
> 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что
> не иметь постоянных лулзов с меньшей производительностьюну ка попробуйте 50 млн инодов и 20ТБ данных два раза в сутки побекапить и хранить хотя бы 10-ок копий за разные периоды
> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
> сутки побекапить и хранить хотя бы 10-ок копий за разные периодыЭто широко рапространенная задача ? Нет, сдуру можно и кое что пониже пояса сломать, нО обязательно ли это делать ? ☺ Логика такая же
>> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
>> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды
> Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже
> пояса сломать, нО обязательно ли это делать ? ☺ Логика
> такая жекак бы вам объяснить, вот у меня очень мало серверов, где инкрементный бекап укладывается в один час, как правило бекап делается от трех часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов (до 80%) и ЦПУ на 6-ть часов в сутки, либо же их устроит падение производительности постоянное, но не большое, скажем 10%?
> как бы вам объяснить, вот у меня очень мало серверов, где инкрементный
> бекап укладывается в один час, как правило бекап делается от трех
> часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень
> сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны
> клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов
> (до 80%) и ЦПУ на 6-ть часов в сутки, либо же
> их устроит падение производительности постоянное, но не большое, скажем 10%?ionice отменили?
> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
> сутки побекапить и хранить хотя бы 10-ок копий за разные периодыИ да, гугель как то вообще обходится даже без журналирования, при этом цветет и пахнет. Инженеры в нем какие то не те, наверное ☺
> И да, гугель как то вообще обходится даже без журналирования,Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля чтобы развернуть там распределенную отказоустойчивую ФС.
>> И да, гугель как то вообще обходится даже без журналирования,
> Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля
> чтобы развернуть там распределенную отказоустойчивую ФС.да тут вопрос собственно в приоритетах, если чоловику первичны эти снапшоты через 30 сек с потерей производительности, он выберет Btrfs; если первична нормальная производительность, и он не страдает что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs
> да тут вопрос собственно в приоритетах,Да, у гугля надежность совершенно не в приоритете: благодаря устройству их распределенных систем, они выдерживают выгорание сервака синим пламенем вообще без прерывания сервиса. Но для этого очевидно должно быть довольно много серверов хранящих блоки избыточных данных, да? :)
> если чоловику первичны эти снапшоты через 30 сек с потерей производительности,
С потерей производительности - это в LVM. А в бтрфс это просто часть дизайна. То-есть, фс по сути ничего нового вообще не делает, она лишь фиксирует что теперь вон тот набор данных и метаданных считается за снапшот.
Тупить оно начнет если сделать кучу снапшотов, забыв о том что отличия между ними хранятся и жрут место, и потом долго фигарить на своей волне, нарастив огромный объем изменений относительно снапшота.
Да, старые снапшоты надо иногда подтирать, иначе вообще кончится место - чудес не бывает. А в автомобили надо иногда заливать горючее и накачивать шины. Это не баг - это просто особенность технологии.
> он выберет Btrfs; если первична нормальная производительность, и он не страдает
> что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на BtrfsБэкап 2 раза в сутки - это прекрасно, но есть некая разница между "2 раза в сутки" и "раз в 30 секунд".
Тьфу ты Ё, как по бенгазильски пишу. Читай в самой новости "уступает в производительности ext4". Почему оно уступает мне по глубокому барабану. И для меня первична производительность, а не снапшоты через 30 сек. В офисе, в котором работаю, есть плагин для сохранения в гугледоки, и мне совершенно не нужен этот снапшот через каждые 30 сек. Плюс бэкапы 2 разы в день
> в производительности ext4". Почему оно уступает мне по глубокому барабану.Запорожес с горы Арарат легко обгонит какой-нибудь Феррари. Будешь водителем запорожца? :)
> Тупить оно начнет если сделать кучу снапшотов,Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах начинает тупить? В ZFS "по барабану", сколько снапшотов.
> забыв о том что отличия
> между ними хранятся и жрут место, и потом долго фигарить на
> своей волне, нарастив огромный объем изменений относительно снапшота.И что?
> Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах
> начинает тупить? В ZFS "по барабану", сколько снапшотов.Да, там путем черной магии обманывают физику и логику, ну конечно же :). Особенно эпично подобные заявы смотрятся от эксперта по получению 6Мб/сек на шпиндель, который даже в такой позе и то не забывает верещать что дефрагер - лишний понт. Ну, знаешь, не у всех понятия о производительности дисковых ФС такие же как у тебя :)
>> своей волне, нарастив огромный объем изменений относительно снапшота.
> И что?И то - и фрагментация растет + оверхед на майнтенанс "лоскутного одеяла" выше. Чудес не бывает. И если б ты не был жабистом и понимал как работают компьютеры, ты бы понял почему лоскутное одеяло из кучи кусочков не сможет разогнаться до той же скорости что и большой непрерывный кусок, читаемый одним чихом.
> По числу строк кода всех остальных опережает Стефан (Stefan)
> Джозеф (Josef) работал над производительностью синхронной записи.Прямо клуб анонимных разработчиков
"Здравствуйте, меня зовут Джозеф, и я уже три года работаю над производительностью синхронной записи"
Это чтобы использующие это уже сейчас в "продакшн" по совету суседелов не отловили и не насовали ему за потерю данных.
А что, при более медленной синхронной записи выше вероятность их потери?
Чем больше время операции тем выше вероятность сбоя во время операции.
> Чем больше время операции тем выше вероятность сбоя во время операции.По такой логике ядерные реакторы вообще взрываться не должны :)
Очередная порция исправлений и улучшений...Видать "14 февраля" наступит таки не раньше чем через три-пять лет, даже не смотря на радужные заявления SUSE.
Этот долгострой уже давно напоминает своей эпичностью незабвенное PulseAudio.
PulseAudio был готов с 1 версии и оллично работал, в том чисте и у меня. Не его проблема что он пользовался документированными возможностями ALSA, криво реализованными. Вот ALSA и чинили эпично.
Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни мог додуматься только поцтеринг.
> Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни
> мог додуматься только поцтеринг.Ой, оказывается в софте бывают баги. Надо же, открытие века.
"добавивший возможность замены диска в процессе эксплуатации"
в btrfs небыло горячей замены диска? spare-дисков там тоже нету?
А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме как для извращений "а вот у меня рейд прямо в файловой системе"?
> А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме
> как для извращений "а вот у меня рейд прямо в файловой
> системе"?Когда конфигурация дискового пула стабильна, то, в большинстве случаев, оно без разницы - какими средствами raid организован (MD/HW/BTRFS/ZFS).
А вот если количество и объем винтов постоянно гуляет, то FS, берущая на себя управление рейдом, оказывается выгоднее - тупо гораздо меньшее количество дисковых операций при изменении конфы дискового пула.
> А вот если количество и объем винтов постоянно гуляет- самое время решить админа премии, а то и уволить, за открытую дестабилизацию системы.
Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.
> Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо
> расширение объёма - но эта операция, на чём бы RAID ни
> был собран, является операцией критичной, и требует планирования работ. Кроме того,
> правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления
> винта каждый месяц можно поставить 12 винтов сразу, и забыть на
> полгода.а что критичного в этой операции? уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп (хотсвоп) или просто доставил винты, подключил к пулу и пошел пиво пить. юзеры как работали, так и работают дальше ничего не замечая.
> а что критичного в этой операции?Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный бэкап перед операцией должен быть. Да, речь про рейды, а не про спаны.
> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп
Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот об этой критичности как раз и речь. Обязательно надо планировать возможность простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже если это кластер. Потому что выход кластера в нештатный режим - тоже проблема, и серьезная.
> подключил к пулу и пошел пиво пить
А в это время (с)... так и пивом можно подавиться в пессимистичном варианте.
>> а что критичного в этой операции?
> Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный
> бэкап перед операцией должен быть. Да, речь про рейды, а не
> про спаны.Не так пойдет - если вы с пьяного глаза, выдерните винт из соседнего сервера, а потом завалите стойку, запнувшись об свою ногу и в процессе падения умудритесь еще ухватить толстый жгут витой поры.
>> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп
> Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания
> операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот
> об этой критичности как раз и речь. Обязательно надо планировать возможность
> простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже
> если это кластер. Потому что выход кластера в нештатный режим -
> тоже проблема, и серьезная.А дальше ничего страшного, у нас же raidz2, а то и raidz3 на шибко больших массивах.
> Не так пойдет - если вы с пьяного глаза, выдерните винт изНаивняк, верящий в 100% надежность железа во время критичных операций с ним, обычно либо быстро переучивается, либо его переучивают с вазелином после первого случая.
> А дальше ничего страшного, у нас же raidz2, а то и raidz3
> на шибко больших массивах.Флаг в жо^W руки - считать на CPU RS-коды.
http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai...Если у вас "шибко большие массивы" - то откуда у вас софтовые рейды, удел нищебродов?
Ну и да - удачи вам в случае чего в forensic с разваленного RAID-Z :)
> Флаг в жо^W руки - считать на CPU RS-коды.Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно вычислить посмотрев с какой из них чексуммы сходятся.
> Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно
> вычислить посмотрев с какой из них чексуммы сходятся.Так речь про Z2/Z3 или все-таки про R5/Z?
> Так речь про Z2/Z3 или все-таки про R5/Z?Про сабжа и raid 5 :)
> Наивняк, верящий в 100% надежность железа во время критичных операций с ним,
> обычно либо быстро переучивается, либо его переучивают с вазелином после первого
> случая.Да, переучился быстро, после того, как 3варе умирая забрала с собой и данные. Теперь сильно спецефичного железа, перед троганием которого нужно долго чесать левое ухо правой пяткой, не имею.
> Флаг в жо^W руки - считать на CPU RS-коды.
> http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai...а мне не критична скорость, мне критична надежность и удобство, в том числе снапшоты, которых в ваших адаптеках сколько, напомните мне.
> Если у вас "шибко большие массивы" - то откуда у вас софтовые
> рейды, удел нищебродов?еще одна точка отказа, это видимо удел не нищебродов, с чем я вас и поздравляю.
> Ну и да - удачи вам в случае чего в forensic с
> разваленного RAID-Z :)как бы вам это донести... у меня зфс пережила то, что не пережили железные контроллеры... вижу вы уже поняли, что нельзя полагаться на железо, теперь вам пену у рта надо подтереть и подумать, если вы способны на это.
> как бы вам это донести... у меня зфс пережила то,А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.
>> как бы вам это донести... у меня зфс пережила то,
> А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и не было на тот момент штатной команды "zpool import -F".
> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
> не было на тот момент штатной команды "zpool import -F".Проблема на самом деле не в том. А в том что средств для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула как я понимаю нет и не планируется. Такой подход невыгодно отличается от традиционного в случае когда что-то пошло не так, факап получился и авария вышла за те рамки которые предусматривали проектировщики ФС в своем сферическом вакууме.
>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
>> не было на тот момент штатной команды "zpool import -F".
> Проблема на самом деле не в том. А в том что средств
> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
> как я понимаю нет и не планируется.Видишь ли, сам принцип CoW не может позволить навернуться существующим данным и новым данным записаться "не туда". Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW). Это делается чаще автоматически при восстановлении после сбоев, но иногда случаются казусы при серьёзных сбоях, когда пул потерял избыточность и получить _непротиворечивые_ метаданные неоткуда. В последнем случае требуется ручной импорт пула командой "zpool import -F" с целью проанализировать потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться достать данные, которые уцелели.
> Такой подход невыгодно отличается
> от традиционного в случае когда что-то пошло не так, факап получился
> и авария вышла за те рамки которые предусматривали проектировщики ФС в
> своем сферическом вакууме.Классический подход с fsck связан с offline-проверкой и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте сами кашу из анонимных файлов.
scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения вплоть до имён потерянных файлов с полными путями к ним.
>> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
>> как я понимаю нет и не планируется.
> Видишь ли, сам принцип CoW не может позволить навернуться существующим даннымЗато может помочь сбой в фирмвари накопителя, логики контроллера, драйверов устройств и ФС, различные глюки оборудования (RAM, CPU, каналов передачи) и даже просто элементарные внезапно вылездшие бэды.
Да, ваша долбаная ZFS рассчитана только на аварии не крупнее проектного дизайна. А если у вас факап запроектного масштаба (т.е. не тот сферический факуум который предусмотрели разработчики) - ничего не знаем, разгребайте свое радиоактивное гэ сами, а мы не при чем, это не мы тот РБМК-1000 дизайнили и поставляли, наша хата вообще с краю, ничего не знаю: мы написали AS IS и все такое - попробуйте теперь с нас слупить чего-нибудь. А как вы там эти радиоактивные ошметки соберете - всем пофиг. Пускайте дескать парней с хэксэдитором, если там что-то ценное а нужного бэкапа вдруг нет.
> и новым данным записаться "не туда".
Так может думать только наивный чукотский юножа^W^W жабист, который просто не знает как и что сделано а потому очень хило представляет себе как это работает. Однако замечу что даже элементарнейшие бэд-сектора и любые глюки железа уже не вписываются в эту сферически-вакуумную концепцию. Что в реальном мире может являть проблему.
> Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое
> время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW).Есть одно важное допущение: допускается что вся эта механика до точки отказа не пострадала и сможет корректно отработат. А какой-нибудь подлый бэд вылезший на (мета)данных записанных год назад может и не разделить оптимизм по этому поводу :). В такой ситуации попытка отмотать может делать даже хуже, потому что довольно сложная логика нарвется на редкое краевое ошибочное состояние. Из которого к тому же может не быть осмысленного (в плане продолжения корректной работы) выхода в хучшем случае. По нашему это называетсы "нащла коса на камень". Неплохо отражает смысл того что получается когда CoW пытается откатить снапшот и тут вдруг окжется что именно там половина данных/метаданных на наше несчастье дали дуба. Никакого рекавери из такого сценария CoW сам по себе не дает: это "запроектная" авария. Хотя пачка бэдов на винче - вполне себе наблюдаемое явление природы.
> потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться
> достать данные, которые уцелели.Вот, до тебя начинает доходить почему fsck не настолько уж и маразм.
>> и авария вышла за те рамки которые предусматривали проектировщики ФС в
>> своем сферическом вакууме.
> Классический подход с fsck связан с offline-проверкойЧто является весьма умным вариантом - при эксклюзивном доступе к диску утиль может делать ряд допушений которые иначе делать не вышло бы. Это ж не для красоты придумали. А из соображения минимизации сложности, улучшения надежности и предсказуемости таковых операций. Например агрессивные попытки починить смонтированный диск к которому ведется активный доступ могут не вести к хорошим результатам. Просто потому что при этом надо разруливать одновременный доступ + деликатные операции + данные ФС потенциально разрушены. Поэтому онлайн обычно если и делают починку то в довольно лайтовой версии.
> и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте
> сами кашу из анонимных файлов.А это только когда удалось понять что вон то возможно было неким файлом/дирой, но совершенно не удалось понять к чему оно относилось. Это конечно не идеальный способ починки, но единственной альтернативой в таком случае является разве что просто совсем очистить спорную территорию.
> scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения
> вплоть до имён потерянных файлов с полными путями к ним.Как ты понимаешь, имена хранятся в метаданных. Чтобы их оттуда вынуть - эти метаданные должны для начала быть. А вот этого никто не обещал, между прочим. Частично такое лечится райд-уровнями и прочая - вероятность ситуации снижается. Зато если уж завалится, +10 к геморности разруливания вручную каждый лишний уровень абстракции даст. Дата рекавери лабы в курсе и за любой вид рэйда сразу накидывают изрядно бабла к стоимости процедуры.
Плюсую. Всегда приятно видеть человека, разбирающегося в работе системы глубоко.
>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
>> не было на тот момент штатной команды "zpool import -F".
> Проблема на самом деле не в том. А в том что средств
> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
> как я понимаю нет и не планируется.zdb — штатная утилита отладки ZFS.
> Такой подход невыгодно отличается
> от традиционного в случае когда что-то пошло не так, факап получился
> и авария вышла за те рамки которые предусматривали проектировщики ФС в
> своем сферическом вакууме.Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.
> Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего
> не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.Проще задать вопрос: а собственно, где ныне Sun со своими мега-разработками :)
>Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.Я уважаю ваше мнение и оно вполне справедливо для идеального случая. К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых полках или свободных винтов, которые можно запихнуть туда "про запас" на пол-года вперед. И проблема не в админе, а в финансировании (начальство на спичках экономит). Или, что тоже часто бывает, всплывает задача, которую надо решить "здесь и сейчас" без оглядки на планы КПСС для третьей пятилетки.
Так что лишняя гибкость в конфигурации дискового пула никому не помешает.
Если оно _вам_ не нужно, то это еще не значит, что оно _никому_ не нужно ⓒ
> Я уважаю ваше мнение и оно вполне справедливо для идеального случая.Оно справедливо для случая, когда и админ, и руководство - вменяемы. В России это встречается не часто, угу.
> К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых
> полках или свободных винтов, которые можно запихнуть туда "про запас" на
> пол-года вперед.Это проблема планирования нагрузки, и решается она административно.
> И проблема не в админе, а в финансировании (начальство на спичках экономит).
Ну Россия, да, угу...
> Если оно _вам_ не нужно, то это еще не значит, что оно
> _никому_ не нужно ⓒОно не не нужно, оно неправильно и рискованно.
> А оно, простите, нужно? При наличии md / HW RAID?Да. Так как классические решения не обеспечивают сквозную целостность данных и другие полезные фишки на уровне свойств отдельных файловых систем. Кроме того, хардварный RAID стоит денег не только за саму железку, но и за гарантийные обязательства по её сопровождению и замене в случае отказа. Грубо говоря: всегда нужно где-то рядом иметь резервный контроллер на случай внезапного отказа рабочего. Софтверные решения здесь явно в плюсе, так как не требуют уникального оборудования минимум в двух экземплярах. Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
> Да. Так как классические решения не обеспечивают сквозную целостность данныхТвоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.
> полезные фишки на уровне свойств отдельных файловых систем
Какие именно?
> Кроме того, хардварный RAID стоит денег не только за саму железку, но и за
> гарантийные обязательства по её сопровождению и замене в случае отказаИменно! В этом и плюс железки по сравнению с unsupported решением.
> всегда нужно где-то рядом иметь резервный контроллер на случай внезапного
> отказа рабочегоВ случае отказа софтового непонятного решения ака "RAID в FS" не поможет уже ничего. md в этом плане куда лучше - он достаточно стандартен, и не использует туевой хучи метаданных для поддержания собственной функциональности.
> Твоя СЦД - это миф.Она не моя, а ваша — сквозная целостность в Btrfs, за которую я не поручусь. А вот ZFS уже спасла от разрушения многие терабайты данных.
> Правда, не понимая принципов работы железа, этого не понять.
Железо без софта мёртво. Не понимая работы софта, а так же какой драйвер кем пишется и в каких условиях, трудно прогнозировать надёжность такой системы хранения.
> А вот ZFS уже спасла от разрушения многие терабайты данных.Например здесь?
https://groups.google.com/forum/?fromgroups=#!topic/comp.uni... - как раз следствие повреждения данных в памятиИли здесь?
http://blog.lastinfirstout.net/2010/04/oraclesun-zfs-data-lo...Или...
http://mail.opensolaris.org/pipermail/zfs-discuss/2012-Janua...
http://christopher-technicalmusings.blogspot.ru/2011/02/zfs-... / http://christopher-technicalmusings.blogspot.ru/2011/05/foll...Ну и google по ZFS data loss.
>> Правда, не понимая принципов работы железа, этого не понять.
> Железо без софта мёртво. Не понимая работы софта, а так же какойНе понимая работы железа, работу софта понять получится только поверхностно. Ибо даже если софт "гарантирует" - еще не факт, что CPU, например, не ошибется с расчётом CRC. Или что до расчёта CRC не будут повреждены данные в памяти. 100% уверенность в "сквозной целостности" может быть только у людей, ни разу с эксплуатацией реальных систем не сталкивавшихся. Причем в практике каждая "9" в 99.999... целостности требует в 10 раз бОльших вложений средств. А вы пытаетесь заменить это нищебродским решением, в надежде, что "усё будет"
> Например здесь?
> https://groups.google.com/forum/?fromgroups=#!topic/comp.uni... - как раз следствие повреждения данных в памятиТам массив просто не импортируется. Что делал до этого — х.з., может он по одному диски из него вынимал, проверяя стабильность, или контроллер навернулся... По остальному — нытьё о том, что "у меня вот тут пул накрылся, не поможете?"...
Ты, это, со своей попаболью с soft-raid лучше обратись в соотвествующую ветку форума: http://forum.ixbt.com/topic.cgi?id=11:44629
Там тебе объяснят что к чему, а чего не бывает.Разумнее сначала прочитать о принципах работы и восстановлении после сбоев soft-RAID, поскольку эти же принципы лежат в основе "интегрированных" (с менеджером томов) файловых систем Btrfs и ZFS.
> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я думаю что знаю ответ. И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? Если уж бряцать громкими терминами охота.
> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?Обеспечит одно — прекращение работы с пулом.
> Обеспечит одно — прекращение работы с пулом.А как ты узнаешь когда тебе уже прекращать работать с пулом?
>> Обеспечит одно — прекращение работы с пулом.
> А как ты узнаешь когда тебе уже прекращать работать с пулом?Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут доступны.
> Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут
> доступны.Пул о повреждении памяти узнает очень и очень поздно.
> Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут доступны.Пардон, пул в это состояние перейдет когда там получится настолько крутая вермишель что ее парсинг будет вызывать проблемы. При этом уже поздно пить боржоми.
>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
> Обеспечит одно — прекращение работы с пулом.А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска.
>>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
>> Обеспечит одно — прекращение работы с пулом.
> А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска.Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками во время записи данных, и они не могут определить просираемость данных на этом этапе? Ошибаешься — это не "классика" на md.
> Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками
> во время записи данных, и они не могут определить просираемость данных
> на этом этапе? Ошибаешься — это не "классика" на md.Бугага. 100% незнание предмета детектед. Запись-то корректно пройдёт. Вот только данные будут "не те".
>> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.
> Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я
> думаю что знаю ответ. И да, если изен такой умный -
> пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
> Если уж бряцать громкими терминами охота.я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?
> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?Мы можете :) предположить что если уж понтоваться надежностью - то наверное на надежном железе. Где хотя-бы оперативка с ECC, etc. А не как изен - "без порток, но в шляпе".
>> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?
> Мы можете :) предположить что если уж понтоваться надежностью - то наверное
> на надежном железе. Где хотя-бы оперативка с ECC, etc. А не
> как изен - "без порток, но в шляпе".а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...
> а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...На 100% во всех случаяю - нельзя, но как минимум если проблема, особенно на уровне железа а не частиц из космоса есть - шансы узнать о ней значительно повышаются. Процессор сложнее - стопроцентная проверка достоверности работы CPU штука сложная и дорогая. Тем не менее, соломку в виде ECC у кэшей там вполне себе подстеливают.
> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...А вы вообще Linux в глаза видели?
>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
> А вы вообще Linux в глаза видели?Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не русифицирован. Но в интернет вылез спокойно.
>>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
>> А вы вообще Linux в глаза видели?
> Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не
> русифицирован. Но в интернет вылез спокойно.Ну да, я к тому - что в ваших комментариях только и читается "обои не понравились". Боюсь, более содержательных знаний о Linux, в частности по работе md - вы не имеете...
>>>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
>>> А вы вообще Linux в глаза видели?
>> Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не
>> русифицирован. Но в интернет вылез спокойно.
> Ну да, я к тому - что в ваших комментариях только и
> читается "обои не понравились". Боюсь, более содержательных знаний о Linux,
> в частности по работе md - вы не имеете...Я слежу за новостями.
Вот тройка ссылок про md:
http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...
http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...
http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...Но сравнительно недавно новость была на opennet.ru, что md научили делать синхронное сравнение блоков в зеркале при обычном чтении.
> Я слежу за новостями.То, что вы процитировали - не "новости", а срач на лоре.
> Вот тройка ссылок про md:
Вы еще "Московский Комсомолец" ссылки забыли, да. Собственно, "тесты" показаны в расчете на школоту, которая доверчиво смотрит в рот "тестеру". ЛОР есть ЛОР.
> Но сравнительно недавно новость была на opennet.ru, что md научили делать синхронное
> сравнение блоков в зеркале при обычном чтении.Скорее всего, вы просто не поняли все слова. Я постараюсь вам помочь, если вы вспомните новость.
PS: Уж никак чтение не может быть "обычное" - описываемая вами фича (о которой я сходу не вспомню и по логам тоже не вижу) носит явно опциональный характер. Ввиду ограниченной сферы применения и сопутствующей деградации производительности.
Менять можно было, но неудобно и долго. Кажется, выглядело оно примерно так:1. Даем команду на извлечение диска
2. Идет полный ребаланс FS (это очень долго)
3. Вытаскиваем диск, вставляем новый
4. По идее, надо делать ребаланс еще раз.Впрочем, могу и ошибаться в последовательности действий - у меня btrfs в качестве эксперимента только на одном винте жила.
>Кроме того, на повестке дня актуальным вопросом остается полное исправление коллизий
>хэшей, так как потенциально это позволяет проводить атаки для вызова отказа в обслуживании.Что они там курят/колят в вену? =)
Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть: https://ru.wikipedia.org/wiki/%D0%A5%D0%...P.S. Все меньше желания пробовать эту кривую поделку после вот таких вот новостей.
То что вы процитировали это какие-то эротические фантазии аффтара новости.
В pull-request'e нет ничего похожего на эту фразу.
> Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество
> в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть:Речь про защиту от управляемого создание коллизий, как правило проблема решается добавлеием пары случайных байт к данным, полученным от пользователя.
> Любая хэш функция по определению имеет коллизииИмелась в виду замена алгоритма CRC32 на иной, более устойчивый к целенаправленной массовой генерации коллизий со стороны вредителя. Пока починили только баг с обработкой очень массовой коллизии. Но сильное проседание скорости при таких махинациях никуда не делось.