URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 87814
[ Назад ]

Исходное сообщение
"Очередная порция улучшений в Btrfs"

Отправлено opennews , 18-Дек-12 20:34 
В рамках подготовки к выпуску ядра 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. Кроме того, на повестке дня актуальным вопросом остается полное исправление коллизий кэшей, так как потенциально это позволяет (http://www.opennet.me/opennews/art.shtml?num=35593) проводить атаки для вызова отказа в обслуживании.

URL: http://www.phoronix.com/scan.php?page=news_item&px=MTI1NTY
Новость: http://www.opennet.me/opennews/art.shtml?num=35636


Содержание

Сообщения в этом обсуждении
"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 20:34 
С переизбытком мета-данных на мелких файлах что-нибудь решили?

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:02 
А что с ним надо решать? Создаете нулевые файлы и у вас на ФС кончается место хотя кроме метаданных на томе вообще ничего нет. Решайте, ага :)

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:50 
> С переизбытком мета-данных на мелких файлах что-нибудь решили?

А что можно "решить" против простой арифметики? Файл - это не только его содержимое, но и метаданные о нем - как минимум имя и расположение. Поэтому _любую_ ФС можно зафлудить файлами нулевого размера так, что метаданные займут все доступное место (кроме тех случаев, когда, например, иноды закончатся раньше - но бтру это не грозит).


"Очередная порция улучшений в Btrfs"
Отправлено all_glory_to_the_hypnotoad , 18-Дек-12 22:23 
имя в юинксах не является метаданным файла

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 23:05 
> имя в юинксах не является метаданным файла

Кто вам это сказал? Дайте ему в бубен за вранье. Метаданные на файловой системе - все что не относится к данным файла и хранится где-то сбоку. Имя, размер, даты создания/модификации/доступа, ... , атрибуты, фактическая адресация размещения, ... - все это метаданные. К данным файла не относятся но хранятся где-то сбоку по поводу существования некоего файла.


"Очередная порция улучшений в Btrfs"
Отправлено all_glory_to_the_hypnotoad , 18-Дек-12 23:34 
> Метаданные на файловой системе

... _в_ файловой системе ...

> все что не относится к данным файла и хранится где-то сбоку

заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним. Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки на файл.  


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 06:33 
> заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные
> файла в юниксовых ФС всё, что можно прикрепить к inode и
> хранить вместе с ним. Имя таковым атрибутом не является (в отличие
> от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки
> на файл.

а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:33 
> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?

Более того, тот же posix вообще IIRC никак не регламентирует как именно ФС должна хранить сведения о файле и опсание его размещения. По поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 05:32 
>> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?
> Более того, тот же posix вообще IIRC никак не регламентирует как именно
> ФС должна хранить сведения о файле и опсание его размещения. По
> поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :)

а причем тут posix? и ответов на вопросы как не было так и нет.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:02 
> а причем тут posix?

При том что апломб относительно "а вот так расово верно, а остальные - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы куда-то слинял.

> и ответов на вопросы как не было так и нет.

А это пусть гипножаб и отвечает. Никто не заставлял его умничать.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 21-Дек-12 19:49 
>> а причем тут posix?
> При том что апломб относительно "а вот так расово верно, а остальные
> - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный
> гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем
> кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы
> куда-то слинял.
>> и ответов на вопросы как не было так и нет.
> А это пусть гипножаб и отвечает. Никто не заставлял его умничать.

а... ну да, все верно.


"Очередная порция улучшений в Btrfs"
Отправлено Гентушник , 20-Дек-12 13:02 
Внезапно да. На один inode может быть несколько жёстких ссылок.
Подробнее тут: http://ru.wikipedia.org/wiki/Inode

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 16:41 
>  ... _в_ файловой системе ...

Ну это пусть граммар-наци докапываются. Вас они вообще просто обязаны расстрелять из пулемета. За пренебрежение заглавными буквами.

>> все что не относится к данным файла и хранится где-то сбоку
> заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке.
> Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним.

А то что нельзя прикрепить к иноде - это тогда что? То-есть, по вашему, структуры ФС метаданными не являются? Круто, а что же это тогда по вашему? И как вы это называете? :)

> Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС).

Для тех кто тормозит, сообщаю: я имею в виду под метаданными вообще все что как-то относится к некоему файлу, его адресации и работе с ним, но не является непосредственно его данными. Т.е. по сути некий технический оверхед, возникающий из-за необходимости хранить ряд сведений, как-то адресовать доступ к этой сущности и так далее. Это вообще никак не относится к типу операционки или чему там еще. Они это могут делать слегка по разному. На мое определение что я понимаю под метаданными это не влияет.

Но если хотите, мы займемся делением на ноль. Берем расово-неверную ОС. Ну там винды, допустим. Цепляем там драйвером типа ext2fsd ext4, с инодами и все такое. А теперь расскажите: где ваш бог теперь? :)

> Имя в нашем случае это атрибут ссылки на файл.

До балды. Грубо говоря я разделяю то что есть на ФС на 2 класса сущностей: данные - это непосредственно данные файла. И метаданные - это вообще все остальное. Мне до балды как именно оно там внутрях реализовано. Я называю метаданными вообще все структуры которые будут скроены по поводу "создан файл".


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 01:34 
> имя в юинксах не является метаданным файла

Что, правда?
Значит, имя файла - это просто данные?


"Очередная порция улучшений в Btrfs"
Отправлено Valentine , 19-Дек-12 10:30 
>> имя в юинксах не является метаданным файла
> Что, правда?
> Значит, имя файла - это просто данные?

Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 16:46 
> Да, это так. Фактически папка - это файл со списком ссылочных структур,
> где содержится имя файла и индексный дескриптор.

Фактически, никто не обязывает файловую систему хранить "папку" в именно указанном виде.

И кстати в современных ФС директории как правило проиндексированы в неких деревьях для более быстрого лукапа. Ибо просто список начинает невъ....нно тормозить когда надо работать с большим числом элементов в оном.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:10 
> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.

И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода df?


"Очередная порция улучшений в Btrfs"
Отправлено Valentine , 28-Дек-12 10:37 
>> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.
> И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода
> df?

Как посмотреть размер:

:~# ls -lhd /var
drwxr-xr-x 25 root root 4.0K Dec 26 02:43 /var


"Очередная порция улучшений в Btrfs"
Отправлено Crazy Alex , 18-Дек-12 22:35 
Только в данном случае речь не об этом, а о горе внутренних структур...

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 22:54 
> Только в данном случае речь не об этом, а о горе внутренних
> структур...

Об этом, об этом.


"Очередная порция улучшений в Btrfs"
Отправлено Crazy Alex , 19-Дек-12 01:06 
Насколько я помню, там было две проблемы:
1) служебных данных очень много в силу сложности самой структуры FS
2) кривые алгоритмы балансировки, оставляющие кучу почти пустых нод в дереве.

Что фиксили, что нет - понятия не имею.


"Очередная порция улучшений в Btrfs"
Отправлено runoverheads , 19-Дек-12 06:11 
нет таких проблем.

дерево портежей спокойно в 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 он всё же был экономнее и быстрее, жаль не поддержали(


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 06:37 
сжатие на бтр-е стоит?

"Очередная порция улучшений в Btrfs"
Отправлено runoverheads , 19-Дек-12 06:45 
> сжатие на бтр-е стоит?

да, 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 даст больше объёма для данных, но ценой скорости, ощутимой на глаз.


"Очередная порция улучшений в Btrfs"
Отправлено runoverheads , 19-Дек-12 13:38 
> сжатие на бтр-е стоит?

на свежую голову понял что чтото не так..

оказалось опция 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/portage

btrfs 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


"Очередная порция улучшений в Btrfs"
Отправлено Аноним2 , 18-Дек-12 21:07 
К 3.9 можно будет попробовать ) Дожить бы ))

"Очередная порция улучшений в Btrfs"
Отправлено pavlinux , 18-Дек-12 21:21 
В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)
Оно либо сдохнет за ненадобностью, либо стабилизируется!

Вроде скоро у Убунты десятилетие будет... :)


"Очередная порция улучшений в Btrfs"
Отправлено closet_source , 18-Дек-12 21:38 
КЭП же! БОЛЬШИМИ БУКОВАМИ! :)

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 22:16 
> БУКОВАМИ

FAIL.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:44 
> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)

...при условии что ты МакЛауд и живешь вечно - замечательный вариант.


"Очередная порция улучшений в Btrfs"
Отправлено pavlinux , 19-Дек-12 01:35 
>> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :)
> ...при условии что ты МакЛауд и живешь вечно - замечательный вариант.

Ну а чё,
Linux ушёл в массы с версии 2.6.9, вроде 2004 год.
StarOffice/OpenOffice ->  Ваще жуть, лет 20 раскручивался.
Vmware c 5-ой версии,
Apache
Netscape/Firefox
Qemu->KVM - c 2006 года.  
bash со второй версии.
...



"Очередная порция улучшений в Btrfs"
Отправлено rshadow , 19-Дек-12 03:04 
Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что копошение в начале пути всего лишь затишье перед экспоненциальным ростом.

"Очередная порция улучшений в Btrfs"
Отправлено pavlinux , 19-Дек-12 03:51 
> Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что
> копошение в начале пути всего лишь затишье перед экспоненциальным ростом.

Дык, об этом и речь. Кстати, экспонента может быть и в другую сторону. (см. Openmoko)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:39 
> 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 со второй версии....

Не, ну если хочется послоупочить - можно до сих пор на конке ездить. Но зачем?


"Очередная порция улучшений в Btrfs"
Отправлено pavlinux , 19-Дек-12 19:03 
>> 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


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:35 
К 4.0

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:36 
> К 3.9 можно будет попробовать ) Дожить бы ))

Что-то вы пессимист прямо. Вас там что, гопы с битами ждут, чтоли - каждый день как война? Ядра шлепают раз в 2-3 месяца и 3.9 будет менее чем через полгода.


"Очередная порция улучшений в Btrfs"
Отправлено Mike Lee , 19-Дек-12 11:10 
конец света же ))

"Очередная порция улучшений в Btrfs"
Отправлено sdfsfsf , 19-Дек-12 16:53 
А некоторые гопы - даже с байтами.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 20:12 
Гоповский байт тоже состоит из восьми бит?

"Очередная порция улучшений в Btrfs"
Отправлено kurokaze , 21-Дек-12 00:59 
Это смотря сколько "а если найдут"

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:09 
> А некоторые гопы - даже с байтами.

Шестирукая Шива завистливо смотрит на столь удачливых гопов :)


"Очередная порция улучшений в Btrfs"
Отправлено Crazy Alex , 18-Дек-12 22:37 
Хм, я бы ещё как минимум версию-другую подождал. Судя по эпичности бага с коллизиями серьёзного тестирования ещё вообще не было. А киллер фич (не чтобы "удобнее", а то, без чего жить нельзя) как-то не видно, так что спешить особой необходимости нет.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 01:37 
> Судя по эпичности бага с коллизиями серьёзного тестирования ещё вообще не было.

Такой баг практически нереально выловить при тестировании. Только аудит. Именно так его и выловили.

> А киллер фич (не чтобы "удобнее", а то, без чего жить нельзя) как-то не видно

Нужно обладать очень плохим зрением, чтобы не видеть снапшоты.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:09 
> Нужно обладать очень плохим зрением, чтобы не видеть снапшоты.

И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит пониже спины от осознания что ты только что @#$нул работу за неделю - так сразу и приходит осознание зачем нужны снапшоты xD.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 18:11 
> И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить
> "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит
> пониже спины от осознания что ты только что @#$нул работу за
> неделю - так сразу и приходит осознание зачем нужны снапшоты xD.

Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:15 
Снапшоты дают возможность делать бэкапы гораздо реже.

С высоты пользователя ФС, умеющей снапшоты - ежедневный бэкап выглядит ничуть не привлекательнее, чем необходимость переустанавливать ОС раз в неделю.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:47 
> привлекательнее, чем необходимость переустанавливать ОС раз в неделю.

Снапшоты не заменяют бэкапы, ибо если там в середине выпадет блок - оно как костяшки домино завалится по цепочке. Но возможность отмотать ошибочную операцию в прошлом, быстро и удобно - ценное свойство.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 19:20 
Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно вероятностям определяются и периоды обновления.

"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 19:25 
> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
> Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем
> вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно
> вероятностям определяются и периоды обновления.

Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать состояние FS - вот это да.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 20:14 
> Терять в худшем случае данные за месяц?

Учитывая ничтожную вероятность такого исхода - не страшно.

> Увольте сразу.

Ок, вы уволены. За перерасход ресурсов.

> Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать

состояние FS - вот это да.

Очень частное и специфичное применение. Под него катят даже уродские и убогие снапшоты lvm.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 20:38 
>> Увольте сразу.
> Ок, вы уволены. За перерасход ресурсов.

Да легко. Я из одной такой конторы ушёл сам, потому что подходы задрали. Зато потом, когда всё рухнуло, на меня вышли с "помогите/спасите". Вот только связываться с оными уже не хотелось.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 20:53 
Да, если строить архитектуру кривыми руками - оно непременно рухнет.
И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что новая архитектура будет не такой кривой.

"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 20:54 
> Да, если строить архитектуру кривыми руками - оно непременно рухнет.
> И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что
> новая архитектура будет не такой кривой.

Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали делать бэкапы, и много чего ещё. А роль действительно положительная - той организации уже нет :)


"Очередная порция улучшений в Btrfs"
Отправлено kurokaze , 21-Дек-12 01:02 
> Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали
> делать бэкапы, и много чего ещё. А роль действительно положительная -
> той организации уже нет :)

Устройся в администрацию президента - от народа потом благодарность будет


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 27-Дек-12 22:29 
> Устройся в администрацию президента - от народа потом благодарность будет

Можно еще в госдуму. Тоже неплохой вариант.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 06:50 
>> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного.
>> Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем
>> вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно
>> вероятностям определяются и периоды обновления.
> Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет
> уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать
> состояние FS - вот это да.

о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ данных бекапить


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 20-Дек-12 07:14 
> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ
> данных бекапить

100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 21-Дек-12 18:56 
>> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ
>> данных бекапить
> 100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял.

ты просто не видел как бекап делается неделю. да не полный бекап, а инкрементальный. с тобой разговаривать, все равно что папуасу рассказывать про снег.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 21-Дек-12 20:53 
> ты просто не видел как бекап делается неделю

Можно поинтересоваться - чем вы так систему добили?



"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 23-Дек-12 05:43 
>> ты просто не видел как бекап делается неделю
> Можно поинтересоваться - чем вы так систему добили?

какую систему и причем тут какая-то система?


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 23-Дек-12 09:41 
> какую систему и причем тут какая-то система?

LMAO, спалился.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 27-Дек-12 22:30 
> ты просто не видел как бекап делается неделю.

Если у вас бэкап делается неделю, у меня для вас плохие новости: you are doing it wrong!


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:46 
> Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов.

Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча. И осознав что все изменения про...лись. И откатить не выйдет. И undelete нету. Абыдна, да! На бтр я бы просто вернулся на свежий автоснапшот и не парился. А на ext4 - попаболь, однако.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 19:26 
> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча.

Как правильно говорил один из моих школьных преподавателей в бородатом 95 году - торопливость нужна при ловле блох.



"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 20:54 
>> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча.
> Как правильно говорил один из моих школьных преподавателей в бородатом 95 году
> - торопливость нужна при ловле блох.

Воот. И с бэкапами торопиться не следует. Это же не блохи. Хватит с них и раза в год :)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:11 
> Как правильно говорил один из моих школьных преподавателей в бородатом 95 году
> - торопливость нужна при ловле блох.

Ну да, однако это не отменяет того факта что наличие нескольких разных инкарнаций ФС в разных точках времени - не самая плохая штука.


"Очередная порция улучшений в Btrfs"
Отправлено linux must _RIP_ , 18-Дек-12 21:31 
Баг с колизиями похоже так и не справили..

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 21:37 
> Баг с колизиями похоже так и не справили..

Взвис - исправили. Сам алгоритм пока не меняли, да.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 18-Дек-12 22:40 
констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4
трыц

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 23:10 
> констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4

Видимо Крис добрел до фороникса :)



"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 15:00 
> Видимо Крис добрел до фороникса :)

Я это чудо ставил для пробы, причем сделал по умолчанию настройки как ext4 так и  Btrfs. Тесты примитивнейшие - удаление сорцов ядра, копирование фильмеца и папки с доками. Везде Btrfs процентов на 10-15 проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения дня сегодняшнего :-)
Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:16 
> проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения
> дня сегодняшнего :-)

Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное свойство которое может хотеться от ФС.

> Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав

Да в общем то по тестам форониксов вполне можно делать некие выводы. А бочку на них обычно катят те фанаты, чей фетиш проиграл в пузомерке. А само по себе бенчи как бенчи. Не хуже остальных. По крайней мере, конфига - описана, что померяно и что вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 17:19 
> Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное
> свойство которое может хотеться от ФС.

Да нет, я не спорю, что у него есть масса преимуществ для серверов, но мне то они как то по барабану

> Да в общем то по тестам форониксов вполне можно делать некие выводы.
> А бочку на них обычно катят те фанаты, чей фетиш проиграл
> в пузомерке. А само по себе бенчи как бенчи. Не хуже
> остальных. По крайней мере, конфига - описана, что померяно и что
> вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.

Вообще  то, да



"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:44 
> Да нет, я не спорю, что у него есть масса преимуществ для серверов,

Как бы это сказать? Я и на десктопе не против иметь возможность отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял данные. А так я смогу сгонять в прошлое и исправить свои (и не только свои) ощибки. Круто же :). Да и возможность подоткнуть при нехватке места +1 диск и ребаланс на него сделать - и на десктопе имхо вполне пригодится.

> но мне то они как то по барабану

Кому как, кому как.

> Вообще  то, да

Ну по крайней мере критики обычно демонстрируют еще более убогое нечто.



"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 17:49 
> Как бы это сказать? Я и на десктопе не против иметь возможность
> отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял
> данные. А так я смогу сгонять в прошлое и исправить свои
> (и не только свои) ощибки.

Ну, для этого есть бэкапы и не только на другой диск. Причем при их использовании нет потери в производительности, как в btrfs


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:56 
> Ну, для этого есть бэкапы и не только на другой диск.

Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну и я тоже. А btrfs так может, снапшоты вытекают из его устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 секунд.

> Причем при их использовании нет потери в производительности, как в btrfs

Потеря производительности - понятие относительное. Я в курсе кто такой CoW и как с ним мирно сосуществовать, пользуясь им на мое благо а не во вред. Я с удовольствием юзану его плюсы и не попаду под минусы. Я же не изен и нагуал все-таки, которые вообще не вдупляют как это работает.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 19:29 
Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию (например массированное обновление софта или что-то масштабное над БД), в случае чего откатываемся единым куском. В случае успеха снапшот удаляем.

"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 20:18 
> Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию
> (например массированное обновление софта или что-то масштабное над БД), в случае
> чего откатываемся единым куском. В случае успеха снапшот удаляем.

заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)



"Очередная порция улучшений в Btrfs"
Отправлено myhand , 19-Дек-12 21:41 
> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)

То же самое - вы не получите уже в силу завязанности процедуры на расписание бэкапа.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 21:44 
>> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)
> То же самое - вы не получите уже в силу завязанности процедуры
> на расписание бэкапа.

выполняем критичную операцию =бэкап


"Очередная порция улучшений в Btrfs"
Отправлено myhand , 19-Дек-12 21:58 
> выполняем критичную операцию =бэкап

А вам объяснили, как вместо этого можно использовать снапшот.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 00:59 
>> выполняем критичную операцию =бэкап
> А вам объяснили, как вместо этого можно использовать снапшот.

C потерей производительности основных операций. "Можно грибок съем, он такой красивый ? Можно , только это бледная поганка" © :-)



"Очередная порция улучшений в Btrfs"
Отправлено myhand , 20-Дек-12 01:13 
>>> выполняем критичную операцию =бэкап
>> А вам объяснили, как вместо этого можно использовать снапшот.
> C потерей производительности основных операций.

А бэкап, значицца на ентой производительности никак не сказывается?  Ну-ну...

> Можно грибок съем, он такой красивый ?

Завязывайте с грибками, сэр.  Они уже явно оказали негативное влияние на ваш мозг.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 18:11 
> выполняем критичную операцию =бэкап

Вариант, но как я уже сказал, бэкапаться раз в 30 секунд вы не будете. А вот бтрфс автоснапшоты сам лепит с такой регулярностью. Ну, как точки консистентности для отката на них при крахе. Конечно в идеале можно побухтеть про то что ощибаться не надо, но в реальном мире люди все-таки ошибаются. Иначе бы в софте не было багов :)


"Очередная порция улучшений в Btrfs"
Отправлено Tav , 20-Дек-12 03:43 
Резервные копии делаются по расписанию или по требованию пользователя и их создание занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, одно другому не замена.

Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 08:06 
> Резервные копии делаются по расписанию или по требованию пользователя и их создание
> занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением
> потенциально опасных действий (обновление, например) и создаются моментально. Очевидно,
> одно другому не замена.
> Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок,
> в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.

Не замена в том плане, что за удобство платят снижением производительности. Чудес на свете не бывает - если где то сделали гуд, то только за счет того, что в другом месте сделали каку



"Очередная порция улучшений в Btrfs"
Отправлено myhand , 20-Дек-12 12:51 
> Не замена в том плане, что за удобство платят снижением производительности.

Вам уже заметили: бэкап тоже влияет на производительность.

> Чудес на свете не бывает - если где то сделали гуд, то
> только за счет того, что в другом месте сделали каку

Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 12:54 
> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь,
> вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?

Пока что получается ровно напротив - удобство снапшотов приводит к снижению производительности



"Очередная порция улучшений в Btrfs"
Отправлено myhand , 20-Дек-12 16:43 
> удобство снапшотов приводит к снижению производительности

Что в лоб - что по лбу.  Вы вообще - читаете что вам пишут?


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 16:45 
>> удобство снапшотов приводит к снижению производительности
> Что в лоб - что по лбу.  Вы вообще - читаете
> что вам пишут?

В начало треда и в саму новость. Курить до просветления ☺


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:13 
> В начало треда и в саму новость.

Тогда зачем вы отвечаете, если коменты не читали? :)



"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 17:17 
>> В начало треда и в саму новость.
> Тогда зачем вы отвечаете, если коменты не читали? :)

Кто ж виноват, что именно вы забыли. с чего вообще начиналась полемика☺


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 20-Дек-12 16:47 
> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь,
> вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?

Для качественных усилков, как ни удивительно - лучше радиолампы. Всем транзисторы хороши... но вот каку с нелинейностью всё-таки подложили :)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:20 
> но вот каку с нелинейностью всё-таки подложили :)

Подложили. Но в современных экспонатах с правильно рассчитанными режимами нелинейность столь незначительна что иные факторы ее перевесят без особых проблем. А цифровая обработка сигнала на большей части пути избавляет от накопления помех свойственных аналоговой технике к тому же. По поводу чего все это ламподр@черство - обычный фетишизм. Мало чем подкрепленный технологически. Хотя для фетищистов есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает звучание? :)


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 20-Дек-12 17:22 
> есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по
> килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает
> звучание? :)

Сигнал - улучшает, звучание - на 0, за пределами слуха.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 18:18 
> Сигнал - улучшает,

...только цифровым технологиям это улучшение сильно пофиг.
Сигнал эзернета или попал в валидный диапазон и пакет был декодирован верно, или уж не попал и пакет забракован и перепослан. Этот факт заинкрементирует соотв. счетчик, проблема с линком будет видна. А если этот счетчик все-время ноль, на кой буй чинить то что не сломано, улучшив линию на какой-то мизер, при том что сетевки и так не жаловались ни на что? В результате получается выкинутый на ветер килобакс: передача данных вообще не изменилась, а килобакс потрачен :)

> звучание - на 0, за пределами слуха.

В случае эзернета - пардон, изменений будет вообще ноль. В случае ламп - да там тоже смотреть надо. Например лампы довольно хлипкие и какая-нибудь вибрация на раз будет трясти электроды, вызывая паразитную модуляцию, например. Но ясен фиг ушибленные аудиофилы не замеряют суммарные искажения и улучшения от применения ламп. Их в индустрии просто методично доят, намного круче чем многих других :)


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 19-Дек-12 20:17 
> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну
> и я тоже. А btrfs так может, снапшоты вытекают из его
> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30
> секунд.

2 раза в сутки, и, честно говоря, мне этого вполне хватает, что не иметь постоянных лулзов с меньшей производительностью



"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 06:26 
>> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну
>> и я тоже. А btrfs так может, снапшоты вытекают из его
>> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30
>> секунд.
> 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что
> не иметь постоянных лулзов с меньшей производительностью

ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в сутки побекапить и хранить хотя бы 10-ок копий за разные периоды


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 08:05 
> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды

Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже пояса сломать, нО обязательно ли это  делать ? ☺ Логика такая же


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 21-Дек-12 19:25 
>> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
>> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды
> Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже
> пояса сломать, нО обязательно ли это  делать ? ☺ Логика
> такая же

как бы вам объяснить, вот у меня очень мало серверов, где инкрементный бекап укладывается в один час, как правило бекап делается от трех часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов (до 80%) и ЦПУ на 6-ть часов в сутки, либо же их устроит падение производительности постоянное, но не большое, скажем 10%?


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 21-Дек-12 20:53 
> как бы вам объяснить, вот у меня очень мало серверов, где инкрементный
> бекап укладывается в один час, как правило бекап делается от трех
> часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень
> сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны
> клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов
> (до 80%) и ЦПУ на 6-ть часов в сутки, либо же
> их устроит падение производительности постоянное, но не большое, скажем 10%?

ionice отменили?


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 13:02 
> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в
> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды

И да, гугель как то вообще обходится даже без журналирования, при этом цветет и пахнет. Инженеры в нем какие то не те, наверное  ☺



"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:22 
> И да, гугель как то вообще обходится даже без журналирования,

Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля чтобы развернуть там распределенную отказоустойчивую ФС.


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 17:28 
>> И да, гугель как то вообще обходится даже без журналирования,
> Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля
> чтобы развернуть там распределенную отказоустойчивую ФС.

да тут вопрос собственно в приоритетах, если чоловику первичны эти снапшоты через 30 сек с потерей производительности, он выберет Btrfs; если первична нормальная производительность, и он не страдает что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 18:24 
> да тут вопрос собственно в приоритетах,

Да, у гугля надежность совершенно не в приоритете: благодаря устройству их распределенных систем, они выдерживают выгорание сервака синим пламенем вообще без прерывания сервиса. Но для этого очевидно должно быть довольно много серверов хранящих блоки избыточных данных, да? :)

> если чоловику первичны эти снапшоты через 30 сек с потерей производительности,

С потерей производительности - это в LVM. А в бтрфс это просто часть дизайна. То-есть, фс по сути ничего нового вообще не делает, она лишь фиксирует что теперь вон тот набор данных и метаданных считается за снапшот.

Тупить оно начнет если сделать кучу снапшотов, забыв о том что отличия между ними хранятся и жрут место, и потом долго фигарить на своей волне, нарастив огромный объем изменений относительно снапшота.

Да, старые снапшоты надо иногда подтирать, иначе вообще кончится место - чудес не бывает. А в автомобили надо иногда заливать горючее и накачивать шины. Это не баг - это просто особенность технологии.

> он выберет Btrfs; если первична нормальная производительность, и он не страдает
> что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs

Бэкап 2 раза в сутки - это прекрасно, но есть некая разница между "2 раза в сутки" и "раз в 30 секунд".


"Очередная порция улучшений в Btrfs"
Отправлено SergMarkov , 20-Дек-12 18:35 
Тьфу ты Ё, как по бенгазильски пишу. Читай в самой новости "уступает в производительности ext4". Почему оно уступает мне по глубокому барабану. И для меня первична производительность, а не снапшоты через 30 сек. В офисе, в котором работаю, есть плагин для сохранения в гугледоки, и мне совершенно не нужен этот снапшот через каждые 30 сек. Плюс бэкапы 2 разы в день

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 22:35 
> в производительности ext4". Почему оно уступает мне по глубокому барабану.

Запорожес с горы Арарат легко обгонит какой-нибудь Феррари. Будешь водителем запорожца? :)


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 21-Дек-12 20:26 
> Тупить оно начнет если сделать кучу снапшотов,

Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах начинает тупить? В ZFS "по барабану", сколько снапшотов.

> забыв о том что отличия
> между ними хранятся и жрут место, и потом долго фигарить на
> своей волне, нарастив огромный объем изменений относительно снапшота.

И что?


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 27-Дек-12 22:39 
> Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах
> начинает тупить? В ZFS "по барабану", сколько снапшотов.

Да, там путем черной магии обманывают физику и логику, ну конечно же :). Особенно эпично подобные заявы смотрятся от эксперта по получению 6Мб/сек на шпиндель, который даже в такой позе и то не забывает верещать что дефрагер - лишний понт. Ну, знаешь, не у всех понятия о производительности дисковых ФС такие же как у тебя :)

>> своей волне, нарастив огромный объем изменений относительно снапшота.
> И что?

И то - и фрагментация растет + оверхед на майнтенанс "лоскутного одеяла" выше. Чудес не бывает. И если б ты не был жабистом и понимал как работают компьютеры, ты бы понял почему лоскутное одеяло из кучи кусочков не сможет разогнаться до той же скорости что и большой непрерывный кусок, читаемый одним чихом.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 18-Дек-12 23:41 
> По числу строк кода всех остальных опережает Стефан (Stefan)
> Джозеф (Josef) работал над производительностью синхронной записи.

Прямо клуб анонимных разработчиков
"Здравствуйте, меня зовут Джозеф, и я уже три года работаю над производительностью синхронной записи"


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 01:39 
Это чтобы использующие это уже сейчас в "продакшн" по совету суседелов не отловили и не насовали ему за потерю данных.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 10:35 
А что, при более медленной синхронной записи выше вероятность их потери?

"Очередная порция улучшений в Btrfs"
Отправлено К.О. , 19-Дек-12 16:04 
Чем больше время операции тем выше вероятность сбоя во время операции.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:17 
> Чем больше время операции тем выше вероятность сбоя во время операции.

По такой логике ядерные реакторы вообще взрываться не должны :)


"Очередная порция улучшений в Btrfs"
Отправлено Anonus , 19-Дек-12 02:51 
Очередная порция исправлений и улучшений...

Видать "14 февраля" наступит таки не раньше чем через три-пять лет, даже не смотря на радужные заявления SUSE.

Этот долгострой уже давно напоминает своей эпичностью незабвенное PulseAudio.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 03:29 
PulseAudio был готов с 1 версии и оллично работал, в том чисте и у меня. Не его проблема что он пользовался документированными возможностями ALSA, криво реализованными. Вот ALSA и чинили эпично.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 14:55 
Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни мог додуматься только поцтеринг.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:17 
> Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни
> мог додуматься только поцтеринг.

Ой, оказывается в софте бывают баги. Надо же, открытие века.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 06:44 
"добавивший возможность замены диска в процессе эксплуатации"
в btrfs небыло горячей замены диска? spare-дисков там тоже нету?

"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 07:22 
А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме как для извращений "а вот у меня рейд прямо в файловой системе"?

"Очередная порция улучшений в Btrfs"
Отправлено dalco , 19-Дек-12 07:52 
> А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме
> как для извращений "а вот у меня рейд прямо в файловой
> системе"?

Когда конфигурация дискового пула стабильна, то, в большинстве случаев, оно без разницы - какими средствами raid организован (MD/HW/BTRFS/ZFS).

А вот если количество и объем винтов постоянно гуляет, то FS, берущая на себя управление рейдом, оказывается выгоднее - тупо гораздо меньшее количество дисковых операций при изменении конфы дискового пула.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 09:33 
> А вот если количество и объем винтов постоянно гуляет

- самое время решить админа премии, а то и уволить, за открытую дестабилизацию системы.

Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 10:00 
> Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо
> расширение объёма - но эта операция, на чём бы RAID ни
> был собран, является операцией критичной, и требует планирования работ. Кроме того,
> правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления
> винта каждый месяц можно поставить 12 винтов сразу, и забыть на
> полгода.

а что критичного в этой операции? уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп (хотсвоп) или просто доставил винты, подключил к пулу и пошел пиво пить. юзеры как работали, так и работают дальше ничего не замечая.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 10:05 
> а что критичного в этой операции?

Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный бэкап перед операцией должен быть. Да, речь про рейды, а не про спаны.

> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп

Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот об этой критичности как раз и речь. Обязательно надо планировать возможность простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже если это кластер. Потому что выход кластера в нештатный режим - тоже проблема, и серьезная.

> подключил к пулу и пошел пиво пить

А в это время (с)... так и пивом можно подавиться в пессимистичном варианте.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 10:49 
>> а что критичного в этой операции?
> Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный
> бэкап перед операцией должен быть. Да, речь про рейды, а не
> про спаны.

Не так пойдет - если вы с пьяного глаза, выдерните винт из соседнего сервера, а потом завалите стойку, запнувшись об свою ногу и в процессе падения умудритесь еще ухватить толстый жгут витой поры.

>> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп
> Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания
> операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот
> об этой критичности как раз и речь. Обязательно надо планировать возможность
> простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже
> если это кластер. Потому что выход кластера в нештатный режим -
> тоже проблема, и серьезная.

А дальше ничего страшного, у нас же raidz2, а то и raidz3 на шибко больших массивах.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 14:04 
> Не так пойдет - если вы с пьяного глаза, выдерните винт из

Наивняк, верящий в 100% надежность железа во время критичных операций с ним, обычно либо быстро переучивается, либо его переучивают с вазелином после первого случая.

> А дальше ничего страшного, у нас же raidz2, а то и raidz3
> на шибко больших массивах.

Флаг в жо^W руки - считать на CPU RS-коды.
http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai...

Если у вас "шибко большие массивы" - то откуда у вас софтовые рейды, удел нищебродов?

Ну и да - удачи вам в случае чего в forensic с разваленного RAID-Z :)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:20 
> Флаг в жо^W руки - считать на CPU RS-коды.

Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно вычислить посмотрев с какой из них чексуммы сходятся.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 18:12 
> Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно
> вычислить посмотрев с какой из них чексуммы сходятся.

Так речь про Z2/Z3 или все-таки про R5/Z?


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 18:57 
> Так речь про Z2/Z3 или все-таки про R5/Z?

Про сабжа и raid 5 :)


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 06:03 
> Наивняк, верящий в 100% надежность железа во время критичных операций с ним,
> обычно либо быстро переучивается, либо его переучивают с вазелином после первого
> случая.

Да, переучился быстро, после того, как 3варе умирая забрала с собой и данные. Теперь сильно спецефичного железа, перед троганием которого нужно долго чесать левое ухо правой пяткой, не имею.

> Флаг в жо^W руки - считать на CPU RS-коды.
> http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai...

а мне не критична скорость, мне критична надежность и удобство, в том числе снапшоты, которых в ваших адаптеках сколько, напомните мне.

> Если у вас "шибко большие массивы" - то откуда у вас софтовые
> рейды, удел нищебродов?

еще одна точка отказа, это видимо удел не нищебродов, с чем я вас и поздравляю.

> Ну и да - удачи вам в случае чего в forensic с
> разваленного RAID-Z :)

как бы вам это донести... у меня зфс пережила то, что не пережили железные контроллеры... вижу вы уже поняли, что нельзя полагаться на железо, теперь вам пену у рта надо подтереть и подумать, если вы способны на это.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:56 
> как бы вам это донести... у меня зфс пережила то,

А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 20-Дек-12 18:11 
>> как бы вам это донести... у меня зфс пережила то,
> А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.

Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и не было на тот момент штатной команды "zpool import -F".


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 22:39 
> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
> не было на тот момент штатной команды "zpool import -F".

Проблема на самом деле не в том. А в том что средств для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула как я понимаю нет и не планируется. Такой подход невыгодно отличается от традиционного в случае когда что-то пошло не так, факап получился и авария вышла за те рамки которые предусматривали проектировщики ФС в своем сферическом вакууме.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 21-Дек-12 20:19 
>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
>> не было на тот момент штатной команды "zpool import -F".
> Проблема на самом деле не в том. А в том что средств
> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
> как я понимаю нет и не планируется.

Видишь ли, сам принцип CoW не может позволить навернуться существующим данным и новым данным записаться "не туда". Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW). Это делается чаще автоматически при восстановлении после сбоев, но иногда случаются казусы при серьёзных сбоях, когда пул потерял избыточность и получить _непротиворечивые_ метаданные неоткуда. В последнем случае требуется ручной импорт пула командой "zpool import -F" с целью проанализировать потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться достать данные, которые уцелели.

> Такой подход невыгодно отличается
> от традиционного в случае когда что-то пошло не так, факап получился
> и авария вышла за те рамки которые предусматривали проектировщики ФС в
> своем сферическом вакууме.

Классический подход с fsck связан с offline-проверкой и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте сами кашу из анонимных файлов.

scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения вплоть до имён потерянных файлов с полными путями к ним.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 27-Дек-12 23:09 
>> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
>> как я понимаю нет и не планируется.
> Видишь ли, сам принцип CoW не может позволить навернуться существующим данным

Зато может помочь сбой в фирмвари накопителя, логики контроллера, драйверов устройств и ФС, различные глюки оборудования (RAM, CPU, каналов передачи) и даже просто элементарные внезапно вылездшие бэды.

Да, ваша долбаная ZFS рассчитана только на аварии не крупнее проектного дизайна. А если у вас факап запроектного масштаба (т.е. не тот сферический факуум который предусмотрели разработчики) - ничего не знаем, разгребайте свое радиоактивное гэ сами, а мы не при чем, это не мы тот РБМК-1000 дизайнили и поставляли, наша хата вообще с краю, ничего не знаю: мы написали AS IS и все такое - попробуйте теперь с нас слупить чего-нибудь. А как вы там эти радиоактивные ошметки соберете - всем пофиг. Пускайте дескать парней с хэксэдитором, если там что-то ценное а нужного бэкапа вдруг нет.

> и новым данным записаться "не туда".

Так может думать только наивный чукотский юножа^W^W жабист, который просто не знает как и что сделано а потому очень хило представляет себе как это работает. Однако замечу что даже элементарнейшие бэд-сектора и любые глюки железа уже не вписываются в эту сферически-вакуумную концепцию. Что в реальном мире может являть проблему.

> Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое
> время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW).

Есть одно важное допущение: допускается что вся эта механика до точки отказа не пострадала и сможет корректно отработат. А какой-нибудь подлый бэд вылезший на (мета)данных записанных год назад может и не разделить оптимизм по этому поводу :). В такой ситуации попытка отмотать может делать даже хуже, потому что довольно сложная логика нарвется на редкое краевое ошибочное состояние. Из которого к тому же может не быть осмысленного (в плане продолжения корректной работы) выхода в хучшем случае. По нашему это называетсы "нащла коса на камень". Неплохо отражает смысл того что получается когда CoW пытается откатить снапшот и тут вдруг окжется что именно там половина данных/метаданных на наше несчастье дали дуба. Никакого рекавери из такого сценария CoW сам по себе не дает: это "запроектная" авария. Хотя пачка бэдов на винче - вполне себе наблюдаемое явление природы.

> потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться
> достать данные, которые уцелели.

Вот, до тебя начинает доходить почему fsck не настолько уж и маразм.

>> и авария вышла за те рамки которые предусматривали проектировщики ФС в
>> своем сферическом вакууме.
> Классический подход с fsck связан с offline-проверкой

Что является весьма умным вариантом - при эксклюзивном доступе к диску утиль может делать ряд допушений которые иначе делать не вышло бы. Это ж не для красоты придумали. А из соображения минимизации сложности, улучшения надежности и предсказуемости таковых операций. Например агрессивные попытки починить смонтированный диск к которому ведется активный доступ могут не вести к хорошим результатам. Просто потому что при этом надо разруливать одновременный доступ + деликатные операции + данные ФС потенциально разрушены. Поэтому онлайн обычно если и делают починку то в довольно лайтовой версии.

> и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте
> сами кашу из анонимных файлов.

А это только когда удалось понять что вон то возможно было неким файлом/дирой, но совершенно не удалось понять к чему оно относилось. Это конечно не идеальный способ починки, но единственной альтернативой в таком случае является разве что просто совсем очистить спорную территорию.

> scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения
> вплоть до имён потерянных файлов с полными путями к ним.

Как ты понимаешь, имена хранятся в метаданных. Чтобы их оттуда вынуть - эти метаданные должны для начала быть. А вот этого никто не обещал, между прочим. Частично такое лечится райд-уровнями и прочая - вероятность ситуации снижается. Зато если уж завалится, +10 к геморности разруливания вручную каждый лишний уровень абстракции даст. Дата рекавери лабы в курсе и за любой вид рэйда сразу накидывают изрядно бабла к стоимости процедуры.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 28-Дек-12 09:37 
Плюсую. Всегда приятно видеть человека, разбирающегося в работе системы глубоко.

"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 29-Дек-12 17:07 
>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и
>> не было на тот момент штатной команды "zpool import -F".
> Проблема на самом деле не в том. А в том что средств
> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула
> как я понимаю нет и не планируется.

zdb — штатная утилита отладки ZFS.

> Такой подход невыгодно отличается
> от традиционного в случае когда что-то пошло не так, факап получился
> и авария вышла за те рамки которые предусматривали проектировщики ФС в
> своем сферическом вакууме.

Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 29-Дек-12 22:13 
> Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего
> не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.

Проще задать вопрос: а собственно, где ныне Sun со своими мега-разработками :)


"Очередная порция улучшений в Btrfs"
Отправлено dalco , 19-Дек-12 10:09 
>Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.

Я уважаю ваше мнение и оно вполне справедливо для идеального случая. К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых полках или свободных винтов, которые можно запихнуть туда "про запас" на пол-года вперед. И проблема не в админе, а в финансировании (начальство на спичках экономит). Или, что тоже часто бывает, всплывает задача, которую надо решить "здесь и сейчас" без оглядки на планы КПСС для третьей пятилетки.

Так что лишняя гибкость в конфигурации дискового пула никому не помешает.

Если оно _вам_ не нужно, то это еще не значит, что оно _никому_ не нужно ⓒ


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 10:15 
> Я уважаю ваше мнение и оно вполне справедливо для идеального случая.

Оно справедливо для случая, когда и админ, и руководство - вменяемы. В России это встречается не часто, угу.

> К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых
> полках или свободных винтов, которые можно запихнуть туда "про запас" на
> пол-года вперед.

Это проблема планирования нагрузки, и решается она административно.

> И проблема не в админе, а в финансировании (начальство на спичках экономит).

Ну Россия, да, угу...

> Если оно _вам_ не нужно, то это еще не значит, что оно
> _никому_ не нужно ⓒ

Оно не не нужно, оно неправильно и рискованно.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 19-Дек-12 08:27 
> А оно, простите, нужно? При наличии md / HW RAID?

Да. Так как классические решения не обеспечивают сквозную целостность данных и другие полезные фишки на уровне свойств отдельных файловых систем. Кроме того, хардварный RAID стоит денег не только за саму железку, но и за гарантийные обязательства по её сопровождению и замене в случае отказа. Грубо говоря: всегда нужно где-то рядом иметь резервный контроллер на случай внезапного отказа рабочего. Софтверные решения здесь явно в плюсе, так как не требуют уникального оборудования минимум в двух экземплярах. Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 09:32 
> Да. Так как классические решения не обеспечивают сквозную целостность данных

Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.

> полезные фишки на уровне свойств отдельных файловых систем

Какие именно?

> Кроме того, хардварный RAID стоит денег не только за саму железку, но и за
> гарантийные обязательства по её сопровождению и замене в случае отказа

Именно! В этом и плюс железки по сравнению с unsupported решением.

> всегда нужно где-то рядом иметь резервный контроллер на случай внезапного
> отказа рабочего

В случае отказа софтового непонятного решения ака "RAID в FS" не поможет уже ничего. md в этом плане куда лучше - он достаточно стандартен, и не использует туевой хучи метаданных для поддержания собственной функциональности.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 19-Дек-12 13:55 
> Твоя СЦД - это миф.

Она не моя, а ваша — сквозная целостность в Btrfs, за которую я не поручусь. А вот ZFS уже спасла от разрушения многие терабайты данных.

> Правда, не понимая принципов работы железа, этого не понять.

Железо без софта мёртво. Не понимая работы софта, а так же какой драйвер кем пишется и в каких условиях, трудно прогнозировать надёжность такой системы хранения.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 14:17 
> А вот 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 раз бОльших вложений средств. А вы пытаетесь заменить это нищебродским решением, в надежде, что "усё будет"


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 19-Дек-12 16:14 
> Например здесь?
> https://groups.google.com/forum/?fromgroups=#!topic/comp.uni... - как раз следствие повреждения данных в памяти

Там массив просто не импортируется. Что делал до этого — х.з., может он по одному диски из него вынимал, проверяя стабильность, или контроллер навернулся... По остальному — нытьё о том, что "у меня вот тут пул накрылся, не поможете?"...

Ты, это, со своей попаболью с soft-raid лучше обратись в соотвествующую ветку форума: http://forum.ixbt.com/topic.cgi?id=11:44629
Там тебе объяснят что к чему, а чего не бывает.

Разумнее сначала прочитать о принципах работы и восстановлении после сбоев soft-RAID, поскольку эти же принципы лежат в основе "интегрированных" (с менеджером томов) файловых систем Btrfs и ZFS.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:21 
> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.

Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я думаю что знаю ответ. И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? Если уж бряцать громкими терминами охота.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 19-Дек-12 18:25 
> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?

Обеспечит одно — прекращение работы с пулом.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 19:02 
> Обеспечит одно — прекращение работы с пулом.

А как ты узнаешь когда тебе уже прекращать работать с пулом?


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 20-Дек-12 07:33 
>> Обеспечит одно — прекращение работы с пулом.
> А как ты узнаешь когда тебе уже прекращать работать с пулом?

Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут доступны.



"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 20-Дек-12 08:05 
> Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут
> доступны.

Пул о повреждении памяти узнает очень и очень поздно.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:25 
> Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут доступны.

Пардон, пул в это состояние перейдет когда там получится настолько крутая вермишель что ее парсинг будет вызывать проблемы. При этом уже поздно пить боржоми.


"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 19-Дек-12 19:25 
>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
> Обеспечит одно — прекращение работы с пулом.

А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска.


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 20-Дек-12 07:36 
>>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
>> Обеспечит одно — прекращение работы с пулом.
> А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска.

Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками во время записи данных, и они не могут определить просираемость данных на этом этапе? Ошибаешься — это не "классика" на md.



"Очередная порция улучшений в Btrfs"
Отправлено AlexAT , 20-Дек-12 08:06 
> Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками
> во время записи данных, и они не могут определить просираемость данных
> на этом этапе? Ошибаешься — это не "классика" на md.

Бугага. 100% незнание предмета детектед. Запись-то корректно пройдёт. Вот только данные будут "не те".


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 06:19 
>> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять.
> Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я
> думаю что знаю ответ. И да, если изен такой умный -
> пусть скажет, что обеспечит целостность данных при сбое оперативки или проца?
> Если уж бряцать громкими терминами охота.

я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 20-Дек-12 17:27 
> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?

Мы можете :) предположить что если уж понтоваться надежностью - то наверное на надежном железе. Где хотя-бы оперативка с ECC, etc. А не как изен - "без порток, но в шляпе".


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 21-Дек-12 18:59 
>> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?
> Мы можете :) предположить что если уж понтоваться надежностью - то наверное
> на надежном железе. Где хотя-бы оперативка с ECC, etc. А не
> как изен - "без порток, но в шляпе".

а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 27-Дек-12 23:39 
> а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...

На 100% во всех случаяю - нельзя, но как минимум если проблема, особенно на уровне железа а не частиц из космоса есть - шансы узнать о ней значительно повышаются. Процессор сложнее - стопроцентная проверка достоверности работы CPU штука сложная и дорогая. Тем не менее, соломку в виде ECC у кэшей там вполне себе подстеливают.


"Очередная порция улучшений в Btrfs"
Отправлено myhand , 19-Дек-12 20:24 
> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...

А вы вообще Linux в глаза видели?


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 20-Дек-12 07:40 
>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
> А вы вообще Linux в глаза видели?

Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не русифицирован. Но в интернет вылез спокойно.


"Очередная порция улучшений в Btrfs"
Отправлено myhand , 20-Дек-12 12:46 
>>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
>> А вы вообще Linux в глаза видели?
> Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не
> русифицирован. Но в интернет вылез спокойно.

Ну да, я к тому - что в ваших комментариях только и читается "обои не понравились".  Боюсь, более содержательных знаний о Linux, в частности по работе md - вы не имеете...


"Очередная порция улучшений в Btrfs"
Отправлено iZEN , 20-Дек-12 12:57 
>>>> Но 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 научили делать синхронное сравнение блоков в зеркале при обычном чтении.


"Очередная порция улучшений в Btrfs"
Отправлено myhand , 20-Дек-12 16:40 
> Я слежу за новостями.

То, что вы процитировали - не "новости", а срач на лоре.

> Вот тройка ссылок про md:

Вы еще "Московский Комсомолец" ссылки забыли, да.  Собственно, "тесты" показаны в расчете на школоту, которая доверчиво смотрит в рот "тестеру".  ЛОР есть ЛОР.

> Но сравнительно недавно новость была на opennet.ru, что md научили делать синхронное
> сравнение блоков в зеркале при обычном чтении.

Скорее всего, вы просто не поняли все слова.  Я постараюсь вам помочь, если вы вспомните новость.

PS: Уж никак чтение не может быть "обычное" - описываемая вами фича (о которой я сходу не вспомню и по логам тоже не вижу) носит явно опциональный характер.  Ввиду ограниченной сферы применения и сопутствующей деградации производительности.


"Очередная порция улучшений в Btrfs"
Отправлено dalco , 19-Дек-12 07:42 
Менять можно было, но неудобно и долго. Кажется, выглядело оно примерно так:

1. Даем команду на извлечение диска
2. Идет полный ребаланс FS (это очень долго)
3. Вытаскиваем диск, вставляем новый
4. По идее, надо делать ребаланс еще раз.

Впрочем, могу и ошибаться в последовательности действий - у меня btrfs  в качестве эксперимента только на одном винте жила.


"Очередная порция улучшений в Btrfs"
Отправлено CssfPZS , 19-Дек-12 15:23 
>Кроме того, на повестке дня актуальным вопросом остается полное исправление коллизий
>хэшей, так как потенциально это позволяет проводить атаки для вызова отказа в обслуживании.

Что они там курят/колят в вену? =)
Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть: https://ru.wikipedia.org/wiki/%D0%A5%D0%...

P.S. Все меньше желания пробовать эту кривую поделку после вот таких вот новостей.


"Очередная порция улучшений в Btrfs"
Отправлено абыр , 19-Дек-12 16:24 
То что вы процитировали это какие-то эротические фантазии аффтара новости.
В pull-request'e нет ничего похожего на эту фразу.

"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:17 

> Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество
> в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть:

Речь про защиту от управляемого создание коллизий, как правило проблема решается добавлеием пары случайных байт к данным, полученным от пользователя.


"Очередная порция улучшений в Btrfs"
Отправлено Аноним , 19-Дек-12 17:24 
> Любая хэш функция по определению имеет коллизии

Имелась в виду замена алгоритма CRC32 на иной, более устойчивый к целенаправленной массовой генерации коллизий со стороны вредителя. Пока починили только баг с обработкой очень массовой коллизии. Но сильное проседание скорости при таких махинациях никуда не делось.