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

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

"Очередная порция улучшений в Btrfs"	+/–
Сообщение от opennews (??) on 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
Ответить | Правка | Cообщить модератору

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

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

1. "Очередная порция улучшений в Btrfs"	+/–
Сообщение от Аноним (??) on 18-Дек-12, 20:34
С переизбытком мета-данных на мелких файлах что-нибудь решили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Очередная порция улучшений в Btrfs"	+4 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:02
	А что с ним надо решать? Создаете нулевые файлы и у вас на ФС кончается место хотя кроме метаданных на томе вообще ничего нет. Решайте, ага :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	11. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:50
	> С переизбытком мета-данных на мелких файлах что-нибудь решили? А что можно "решить" против простой арифметики? Файл - это не только его содержимое, но и метаданные о нем - как минимум имя и расположение. Поэтому _любую_ ФС можно зафлудить файлами нулевого размера так, что метаданные займут все доступное место (кроме тех случаев, когда, например, иноды закончатся раньше - но бтру это не грозит).
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 18-Дек-12, 22:23
	имя в юинксах не является метаданным файла
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	26. "Очередная порция улучшений в Btrfs"	+4 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 23:05
	> имя в юинксах не является метаданным файла Кто вам это сказал? Дайте ему в бубен за вранье. Метаданные на файловой системе - все что не относится к данным файла и хранится где-то сбоку. Имя, размер, даты создания/модификации/доступа, ... , атрибуты, фактическая адресация размещения, ... - все это метаданные. К данным файла не относятся но хранятся где-то сбоку по поводу существования некоего файла.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	30. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 18-Дек-12, 23:34
	> Метаданные на файловой системе ... _в_ файловой системе ... > все что не относится к данным файла и хранится где-то сбоку заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним. Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки на файл.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	44. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 06:33
	> заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. Метаданные > файла в юниксовых ФС всё, что можно прикрепить к inode и > хранить вместе с ним. Имя таковым атрибутом не является (в отличие > от альтернативных убогих ОС). Имя в нашем случае это атрибут ссылки > на файл. а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	84. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:33
	> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах? Более того, тот же posix вообще IIRC никак не регламентирует как именно ФС должна хранить сведения о файле и опсание его размещения. По поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	119. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 05:32
	>> а чем ссылка от инода отличается? ссылка и инод хранятся где-то в разных местах? > Более того, тот же posix вообще IIRC никак не регламентирует как именно > ФС должна хранить сведения о файле и опсание его размещения. По > поводу чего такой апломб насчет одной конкретной реализации весьма улыбает :) а причем тут posix? и ответов на вопросы как не было так и нет.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	142. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:02
	> а причем тут posix? При том что апломб относительно "а вот так расово верно, а остальные - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы куда-то слинял. > и ответов на вопросы как не было так и нет. А это пусть гипножаб и отвечает. Никто не заставлял его умничать.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	167. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 21-Дек-12, 19:49
	>> а причем тут posix? > При том что апломб относительно "а вот так расово верно, а остальные > - пи...сы" должен быть чем-то подкреплен. Желательно более убедительным чем личный > гонор субъекта постящего коменты. Гипножаб привел какие-то громкие тезисы которые ничем > кроме его гонора не обоснованы, погнул пальцы. А получив резонные предъявы > куда-то слинял. >> и ответов на вопросы как не было так и нет. > А это пусть гипножаб и отвечает. Никто не заставлял его умничать. а... ну да, все верно.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	137. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Гентушник (ok) on 20-Дек-12, 13:02
	Внезапно да. На один inode может быть несколько жёстких ссылок. Подробнее тут: http://ru.wikipedia.org/wiki/Inode
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	72. "Очередная порция улучшений в Btrfs"	+5 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 16:41
	>  ... _в_ файловой системе ... Ну это пусть граммар-наци докапываются. Вас они вообще просто обязаны расстрелять из пулемета. За пренебрежение заглавными буквами. >> все что не относится к данным файла и хранится где-то сбоку > заканчивай давай со совоим обывательским учением о файлах на обезьяньем языке. > Метаданные файла в юниксовых ФС всё, что можно прикрепить к inode и хранить вместе с ним. А то что нельзя прикрепить к иноде - это тогда что? То-есть, по вашему, структуры ФС метаданными не являются? Круто, а что же это тогда по вашему? И как вы это называете? :) > Имя таковым атрибутом не является (в отличие от альтернативных убогих ОС). Для тех кто тормозит, сообщаю: я имею в виду под метаданными вообще все что как-то относится к некоему файлу, его адресации и работе с ним, но не является непосредственно его данными. Т.е. по сути некий технический оверхед, возникающий из-за необходимости хранить ряд сведений, как-то адресовать доступ к этой сущности и так далее. Это вообще никак не относится к типу операционки или чему там еще. Они это могут делать слегка по разному. На мое определение что я понимаю под метаданными это не влияет. Но если хотите, мы займемся делением на ноль. Берем расово-неверную ОС. Ну там винды, допустим. Цепляем там драйвером типа ext2fsd ext4, с инодами и все такое. А теперь расскажите: где ваш бог теперь? :) > Имя в нашем случае это атрибут ссылки на файл. До балды. Грубо говоря я разделяю то что есть на ФС на 2 класса сущностей: данные - это непосредственно данные файла. И метаданные - это вообще все остальное. Мне до балды как именно оно там внутрях реализовано. Я называю метаданными вообще все структуры которые будут скроены по поводу "создан файл".
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	35. "Очередная порция улучшений в Btrfs"	+3 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 01:34
	> имя в юинксах не является метаданным файла Что, правда? Значит, имя файла - это просто данные?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	58. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от Valentine (??) on 19-Дек-12, 10:30
	>> имя в юинксах не является метаданным файла > Что, правда? > Значит, имя файла - это просто данные? Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	73. "Очередная порция улучшений в Btrfs"	+3 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 16:46
	> Да, это так. Фактически папка - это файл со списком ссылочных структур, > где содержится имя файла и индексный дескриптор. Фактически, никто не обязывает файловую систему хранить "папку" в именно указанном виде. И кстати в современных ФС директории как правило проиндексированы в неких деревьях для более быстрого лукапа. Ибо просто список начинает невъ....нно тормозить когда надо работать с большим числом элементов в оном.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	88. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 18:10
	> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор. И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода df?
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	180. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Valentine (??) on 28-Дек-12, 10:37
	>> Да, это так. Фактически папка - это файл со списком ссылочных структур, где содержится имя файла и индексный дескриптор. > И сразу закономерный вопрос: размер такого файла учитывается в столбце "used" вывода > df? Как посмотреть размер: :~# ls -lhd /var drwxr-xr-x 25 root root 4.0K Dec 26 02:43 /var
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	20. "Очередная порция улучшений в Btrfs"	–4 +/–
	Сообщение от Crazy Alex (ok) on 18-Дек-12, 22:35
	Только в данном случае речь не об этом, а о горе внутренних структур...
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	25. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 18-Дек-12, 22:54
	> Только в данном случае речь не об этом, а о горе внутренних > структур... Об этом, об этом.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	34. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от Crazy Alex (ok) on 19-Дек-12, 01:06
	Насколько я помню, там было две проблемы: 1) служебных данных очень много в силу сложности самой структуры FS 2) кривые алгоритмы балансировки, оставляющие кучу почти пустых нод в дереве. Что фиксили, что нет - понятия не имею.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	43. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от runoverheads (ok) on 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 он всё же был экономнее и быстрее, жаль не поддержали(
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	45. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 06:37
	сжатие на бтр-е стоит?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	47. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от runoverheads (ok) on 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 даст больше объёма для данных, но ценой скорости, ощутимой на глаз.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	62. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от runoverheads (ok) on 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
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

3. "Очередная порция улучшений в Btrfs"	–1 +/–
Сообщение от Аноним2 on 18-Дек-12, 21:07
К 3.9 можно будет попробовать ) Дожить бы ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от pavlinux (ok) on 18-Дек-12, 21:21
	В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :) Оно либо сдохнет за ненадобностью, либо стабилизируется! Вроде скоро у Убунты десятилетие будет... :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	9. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от closet_source (ok) on 18-Дек-12, 21:38
	КЭП же! БОЛЬШИМИ БУКОВАМИ! :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 18-Дек-12, 22:16
	> БУКОВАМИ FAIL.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	10. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:44
	> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :) ...при условии что ты МакЛауд и живешь вечно - замечательный вариант.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	36. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от pavlinux (ok) on 19-Дек-12, 01:35
	>> В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать :) > ...при условии что ты МакЛауд и живешь вечно - замечательный вариант. Ну а чё, Linux ушёл в массы с версии 2.6.9, вроде 2004 год. StarOffice/OpenOffice ->  Ваще жуть, лет 20 раскручивался. Vmware c 5-ой версии, Apache Netscape/Firefox Qemu->KVM - c 2006 года.   bash со второй версии. ...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	40. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от rshadow (ok) on 19-Дек-12, 03:04
	Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что копошение в начале пути всего лишь затишье перед экспоненциальным ростом.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	42. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от pavlinux (ok) on 19-Дек-12, 03:51
	> Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что > копошение в начале пути всего лишь затишье перед экспоненциальным ростом. Дык, об этом и речь. Кстати, экспонента может быть и в другую сторону. (см. Openmoko)
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	85. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 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 со второй версии.... Не, ну если хочется послоупочить - можно до сих пор на конке ездить. Но зачем?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	98. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от pavlinux (ok) on 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
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	6. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:35
	К 4.0
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:36
	> К 3.9 можно будет попробовать ) Дожить бы )) Что-то вы пессимист прямо. Вас там что, гопы с битами ждут, чтоли - каждый день как война? Ядра шлепают раз в 2-3 месяца и 3.9 будет менее чем через полгода.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	61. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Mike Lee on 19-Дек-12, 11:10
	конец света же ))
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	74. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от sdfsfsf on 19-Дек-12, 16:53
	А некоторые гопы - даже с байтами.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	104. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 20:12
	Гоповский байт тоже состоит из восьми бит?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	162. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от kurokaze (ok) on 21-Дек-12, 00:59
	Это смотря сколько "а если найдут"
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	143. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:09
	> А некоторые гопы - даже с байтами. Шестирукая Шива завистливо смотрит на столь удачливых гопов :)
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	21. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от Crazy Alex (ok) on 18-Дек-12, 22:37
	Хм, я бы ещё как минимум версию-другую подождал. Судя по эпичности бага с коллизиями серьёзного тестирования ещё вообще не было. А киллер фич (не чтобы "удобнее", а то, без чего жить нельзя) как-то не видно, так что спешить особой необходимости нет.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

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

	75. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:09
	> Нужно обладать очень плохим зрением, чтобы не видеть снапшоты. И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит пониже спины от осознания что ты только что @#$нул работу за неделю - так сразу и приходит осознание зачем нужны снапшоты xD.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	89. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 18:11
	> И вообще недеструктивную запись. Хотя от этого очень помогает пару раз пришибить > "не ту" диру. Сразу наступает понимание зачем снапшоты нужны. Как засвеобит > пониже спины от осознания что ты только что @#$нул работу за > неделю - так сразу и приходит осознание зачем нужны снапшоты xD. Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

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

	94. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 18:47
	> привлекательнее, чем необходимость переустанавливать ОС раз в неделю. Снапшоты не заменяют бэкапы, ибо если там в середине выпадет блок - оно как костяшки домино завалится по цепочке. Но возможность отмотать ошибочную операцию в прошлом, быстро и удобно - ценное свойство.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

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

	100. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 19:25
	> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного. > Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем > вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно > вероятностям определяются и периоды обновления. Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать состояние FS - вот это да.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	105. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 20:14
	> Терять в худшем случае данные за месяц? Учитывая ничтожную вероятность такого исхода - не страшно. > Увольте сразу. Ок, вы уволены. За перерасход ресурсов. > Нет уж, нет уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать состояние FS - вот это да. Очень частное и специфичное применение. Под него катят даже уродские и убогие снапшоты lvm.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	109. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 20:38
	>> Увольте сразу. > Ок, вы уволены. За перерасход ресурсов. Да легко. Я из одной такой конторы ушёл сам, потому что подходы задрали. Зато потом, когда всё рухнуло, на меня вышли с "помогите/спасите". Вот только связываться с оными уже не хотелось.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	110. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 20:53
	Да, если строить архитектуру кривыми руками - оно непременно рухнет. И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что новая архитектура будет не такой кривой.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	112. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 20:54
	> Да, если строить архитектуру кривыми руками - оно непременно рухнет. > И отсутствие бэкапов тут даже играет положительную роль - есть надежда, что > новая архитектура будет не такой кривой. Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали делать бэкапы, и много чего ещё. А роль действительно положительная - той организации уже нет :)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	163. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от kurokaze (ok) on 21-Дек-12, 01:02
	> Оно рухнуло потому, что подход сменился на "минимум затрат". Соответственно, перестали > делать бэкапы, и много чего ещё. А роль действительно положительная - > той организации уже нет :) Устройся в администрацию президента - от народа потом благодарность будет
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	174. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 27-Дек-12, 22:29
	> Устройся в администрацию президента - от народа потом благодарность будет Можно еще в госдуму. Тоже неплохой вариант.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	123. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 06:50
	>> Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного. >> Потому что вероятность удалить что-то своими кривыми руками на порядок выше, чем >> вероятность сбоя на винтах, особенно если они в избыточном рейде. Соответственно >> вероятностям определяются и периоды обновления. > Терять в худшем случае данные за месяц? Увольте сразу. Нет уж, нет > уж. Снапшот удобен как вспомогательная сущность к бэкапу - чтобы зафиксировать > состояние FS - вот это да. о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ данных бекапить
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	124. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 20-Дек-12, 07:14
	> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ > данных бекапить 100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	164. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 21-Дек-12, 18:56
	>> о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ >> данных бекапить > 100Тб? А что как мало-то? Инкрементальных бэкапов никто какбэ не отменял. ты просто не видел как бекап делается неделю. да не полный бекап, а инкрементальный. с тобой разговаривать, все равно что папуасу рассказывать про снег.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	170. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 21-Дек-12, 20:53
	> ты просто не видел как бекап делается неделю Можно поинтересоваться - чем вы так систему добили?
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	172. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 23-Дек-12, 05:43
	>> ты просто не видел как бекап делается неделю > Можно поинтересоваться - чем вы так систему добили? какую систему и причем тут какая-то система?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	173. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 23-Дек-12, 09:41
	> какую систему и причем тут какая-то система? LMAO, спалился.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	175. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 27-Дек-12, 22:30
	> ты просто не видел как бекап делается неделю. Если у вас бэкап делается неделю, у меня для вас плохие новости: you are doing it wrong!
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	93. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 18:46
	> Вот. Еще один, не делающий ежедневных (инкрементальных) бэкапов. Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча. И осознав что все изменения про...лись. И откатить не выйдет. И undelete нету. Абыдна, да! На бтр я бы просто вернулся на свежий автоснапшот и не парился. А на ext4 - попаболь, однако.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	102. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 19:26
	> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча. Как правильно говорил один из моих школьных преподавателей в бородатом 95 году - торопливость нужна при ловле блох.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	111. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 20:54
	>> Кхм, вообще-то я разок про...л данные как раз раскатав старый бэкап сгоряча. > Как правильно говорил один из моих школьных преподавателей в бородатом 95 году > - торопливость нужна при ловле блох. Воот. И с бэкапами торопиться не следует. Это же не блохи. Хватит с них и раза в год :)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	144. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:11
	> Как правильно говорил один из моих школьных преподавателей в бородатом 95 году > - торопливость нужна при ловле блох. Ну да, однако это не отменяет того факта что наличие нескольких разных инкарнаций ФС в разных точках времени - не самая плохая штука.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

5. "Очередная порция улучшений в Btrfs"	–2 +/–
Сообщение от linux must _RIP_ on 18-Дек-12, 21:31
Баг с колизиями похоже так и не справили..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 18-Дек-12, 21:37
	> Баг с колизиями похоже так и не справили.. Взвис - исправили. Сам алгоритм пока не меняли, да.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

22. "Очередная порция улучшений в Btrfs"	–1 +/–
Сообщение от SergMarkov (ok) on 18-Дек-12, 22:40
констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4 трыц
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 18-Дек-12, 23:10
	> констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4 Видимо Крис добрел до фороникса :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	67. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 15:00
	> Видимо Крис добрел до фороникса :) Я это чудо ставил для пробы, причем сделал по умолчанию настройки как ext4 так и  Btrfs. Тесты примитивнейшие - удаление сорцов ядра, копирование фильмеца и папки с доками. Везде Btrfs процентов на 10-15 проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения дня сегодняшнего :-) Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	76. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:16
	> проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения > дня сегодняшнего :-) Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное свойство которое может хотеться от ФС. > Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав Да в общем то по тестам форониксов вполне можно делать некие выводы. А бочку на них обычно катят те фанаты, чей фетиш проиграл в пузомерке. А само по себе бенчи как бенчи. Не хуже остальных. По крайней мере, конфига - описана, что померяно и что вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	80. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 17:19
	> Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное > свойство которое может хотеться от ФС. Да нет, я не спорю, что у него есть масса преимуществ для серверов, но мне то они как то по барабану > Да в общем то по тестам форониксов вполне можно делать некие выводы. > А бочку на них обычно катят те фанаты, чей фетиш проиграл > в пузомерке. А само по себе бенчи как бенчи. Не хуже > остальных. По крайней мере, конфига - описана, что померяно и что > вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно. Вообще  то, да
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	86. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:44
	> Да нет, я не спорю, что у него есть масса преимуществ для серверов, Как бы это сказать? Я и на десктопе не против иметь возможность отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял данные. А так я смогу сгонять в прошлое и исправить свои (и не только свои) ощибки. Круто же :). Да и возможность подоткнуть при нехватке места +1 диск и ребаланс на него сделать - и на десктопе имхо вполне пригодится. > но мне то они как то по барабану Кому как, кому как. > Вообще  то, да Ну по крайней мере критики обычно демонстрируют еще более убогое нечто.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	87. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 17:49
	> Как бы это сказать? Я и на десктопе не против иметь возможность > отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял > данные. А так я смогу сгонять в прошлое и исправить свои > (и не только свои) ощибки. Ну, для этого есть бэкапы и не только на другой диск. Причем при их использовании нет потери в производительности, как в btrfs
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	95. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 18:56
	> Ну, для этого есть бэкапы и не только на другой диск. Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну и я тоже. А btrfs так может, снапшоты вытекают из его устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 секунд. > Причем при их использовании нет потери в производительности, как в btrfs Потеря производительности - понятие относительное. Я в курсе кто такой CoW и как с ним мирно сосуществовать, пользуясь им на мое благо а не во вред. Я с удовольствием юзану его плюсы и не попаду под минусы. Я же не изен и нагуал все-таки, которые вообще не вдупляют как это работает.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	103. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 19:29
	Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию (например массированное обновление софта или что-то масштабное над БД), в случае чего откатываемся единым куском. В случае успеха снапшот удаляем.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	107. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 20:18
	> Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию > (например массированное обновление софта или что-то масштабное над БД), в случае > чего откатываемся единым куском. В случае успеха снапшот удаляем. заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	113. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok) on 19-Дек-12, 21:41
	> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-) То же самое - вы не получите уже в силу завязанности процедуры на расписание бэкапа.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	114. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 21:44
	>> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-) > То же самое - вы не получите уже в силу завязанности процедуры > на расписание бэкапа. выполняем критичную операцию =бэкап
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	115. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok) on 19-Дек-12, 21:58
	> выполняем критичную операцию =бэкап А вам объяснили, как вместо этого можно использовать снапшот.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	116. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 00:59
	>> выполняем критичную операцию =бэкап > А вам объяснили, как вместо этого можно использовать снапшот. C потерей производительности основных операций. "Можно грибок съем, он такой красивый ? Можно , только это бледная поганка" © :-)
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	117. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от myhand (ok) on 20-Дек-12, 01:13
	>>> выполняем критичную операцию =бэкап >> А вам объяснили, как вместо этого можно использовать снапшот. > C потерей производительности основных операций. А бэкап, значицца на ентой производительности никак не сказывается?  Ну-ну... > Можно грибок съем, он такой красивый ? Завязывайте с грибками, сэр.  Они уже явно оказали негативное влияние на ваш мозг.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	155. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 18:11
	> выполняем критичную операцию =бэкап Вариант, но как я уже сказал, бэкапаться раз в 30 секунд вы не будете. А вот бтрфс автоснапшоты сам лепит с такой регулярностью. Ну, как точки консистентности для отката на них при крахе. Конечно в идеале можно побухтеть про то что ощибаться не надо, но в реальном мире люди все-таки ошибаются. Иначе бы в софте не было багов :)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	118. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Tav (ok) on 20-Дек-12, 03:43
	Резервные копии делаются по расписанию или по требованию пользователя и их создание занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, одно другому не замена. Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	131. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 08:06
	> Резервные копии делаются по расписанию или по требованию пользователя и их создание > занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением > потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, > одно другому не замена. > Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, > в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления. Не замена в том плане, что за удобство платят снижением производительности. Чудес на свете не бывает - если где то сделали гуд, то только за счет того, что в другом месте сделали каку
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	133. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok) on 20-Дек-12, 12:51
	> Не замена в том плане, что за удобство платят снижением производительности. Вам уже заметили: бэкап тоже влияет на производительность. > Чудес на свете не бывает - если где то сделали гуд, то > только за счет того, что в другом месте сделали каку Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	134. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 12:54
	> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, > вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами? Пока что получается ровно напротив - удобство снапшотов приводит к снижению производительности
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	139. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от myhand (ok) on 20-Дек-12, 16:43
	> удобство снапшотов приводит к снижению производительности Что в лоб - что по лбу.  Вы вообще - читаете что вам пишут?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	140. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 16:45
	>> удобство снапшотов приводит к снижению производительности > Что в лоб - что по лбу.  Вы вообще - читаете > что вам пишут? В начало треда и в саму новость. Курить до просветления ☺
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	145. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:13
	> В начало треда и в саму новость. Тогда зачем вы отвечаете, если коменты не читали? :)
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	146. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 17:17
	>> В начало треда и в саму новость. > Тогда зачем вы отвечаете, если коменты не читали? :) Кто ж виноват, что именно вы забыли. с чего вообще начиналась полемика☺
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	141. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 20-Дек-12, 16:47
	> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, > вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами? Для качественных усилков, как ни удивительно - лучше радиолампы. Всем транзисторы хороши... но вот каку с нелинейностью всё-таки подложили :)
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	147. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:20
	> но вот каку с нелинейностью всё-таки подложили :) Подложили. Но в современных экспонатах с правильно рассчитанными режимами нелинейность столь незначительна что иные факторы ее перевесят без особых проблем. А цифровая обработка сигнала на большей части пути избавляет от накопления помех свойственных аналоговой технике к тому же. По поводу чего все это ламподр@черство - обычный фетишизм. Мало чем подкрепленный технологически. Хотя для фетищистов есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает звучание? :)
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	148. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 20-Дек-12, 17:22
	> есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по > килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает > звучание? :) Сигнал - улучшает, звучание - на 0, за пределами слуха.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	157. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 18:18
	> Сигнал - улучшает, ...только цифровым технологиям это улучшение сильно пофиг. Сигнал эзернета или попал в валидный диапазон и пакет был декодирован верно, или уж не попал и пакет забракован и перепослан. Этот факт заинкрементирует соотв. счетчик, проблема с линком будет видна. А если этот счетчик все-время ноль, на кой буй чинить то что не сломано, улучшив линию на какой-то мизер, при том что сетевки и так не жаловались ни на что? В результате получается выкинутый на ветер килобакс: передача данных вообще не изменилась, а килобакс потрачен :) > звучание - на 0, за пределами слуха. В случае эзернета - пардон, изменений будет вообще ноль. В случае ламп - да там тоже смотреть надо. Например лампы довольно хлипкие и какая-нибудь вибрация на раз будет трясти электроды, вызывая паразитную модуляцию, например. Но ясен фиг ушибленные аудиофилы не замеряют суммарные искажения и улучшения от применения ламп. Их в индустрии просто методично доят, намного круче чем многих других :)
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	106. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 19-Дек-12, 20:17
	> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну > и я тоже. А btrfs так может, снапшоты вытекают из его > устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 > секунд. 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что не иметь постоянных лулзов с меньшей производительностью
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	122. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 06:26
	>> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну >> и я тоже. А btrfs так может, снапшоты вытекают из его >> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 >> секунд. > 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что > не иметь постоянных лулзов с меньшей производительностью ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в сутки побекапить и хранить хотя бы 10-ок копий за разные периоды
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	128. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 08:05
	> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в > сутки побекапить и хранить хотя бы 10-ок копий за разные периоды Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже пояса сломать, нО обязательно ли это  делать ? ☺ Логика такая же
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	166. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-12, 19:25
	>> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в >> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды > Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже > пояса сломать, нО обязательно ли это  делать ? ☺ Логика > такая же как бы вам объяснить, вот у меня очень мало серверов, где инкрементный бекап укладывается в один час, как правило бекап делается от трех часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов (до 80%) и ЦПУ на 6-ть часов в сутки, либо же их устроит падение производительности постоянное, но не большое, скажем 10%?
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	171. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 21-Дек-12, 20:53
	> как бы вам объяснить, вот у меня очень мало серверов, где инкрементный > бекап укладывается в один час, как правило бекап делается от трех > часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень > сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны > клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов > (до 80%) и ЦПУ на 6-ть часов в сутки, либо же > их устроит падение производительности постоянное, но не большое, скажем 10%? ionice отменили?
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	136. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 13:02
	> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в > сутки побекапить и хранить хотя бы 10-ок копий за разные периоды И да, гугель как то вообще обходится даже без журналирования, при этом цветет и пахнет. Инженеры в нем какие то не те, наверное  ☺
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

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

	152. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 17:28
	>> И да, гугель как то вообще обходится даже без журналирования, > Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля > чтобы развернуть там распределенную отказоустойчивую ФС. да тут вопрос собственно в приоритетах, если чоловику первичны эти снапшоты через 30 сек с потерей производительности, он выберет Btrfs; если первична нормальная производительность, и он не страдает что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	158. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 18:24
	> да тут вопрос собственно в приоритетах, Да, у гугля надежность совершенно не в приоритете: благодаря устройству их распределенных систем, они выдерживают выгорание сервака синим пламенем вообще без прерывания сервиса. Но для этого очевидно должно быть довольно много серверов хранящих блоки избыточных данных, да? :) > если чоловику первичны эти снапшоты через 30 сек с потерей производительности, С потерей производительности - это в LVM. А в бтрфс это просто часть дизайна. То-есть, фс по сути ничего нового вообще не делает, она лишь фиксирует что теперь вон тот набор данных и метаданных считается за снапшот. Тупить оно начнет если сделать кучу снапшотов, забыв о том что отличия между ними хранятся и жрут место, и потом долго фигарить на своей волне, нарастив огромный объем изменений относительно снапшота. Да, старые снапшоты надо иногда подтирать, иначе вообще кончится место - чудес не бывает. А в автомобили надо иногда заливать горючее и накачивать шины. Это не баг - это просто особенность технологии. > он выберет Btrfs; если первична нормальная производительность, и он не страдает > что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs Бэкап 2 раза в сутки - это прекрасно, но есть некая разница между "2 раза в сутки" и "раз в 30 секунд".
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	159. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok) on 20-Дек-12, 18:35
	Тьфу ты Ё, как по бенгазильски пишу. Читай в самой новости "уступает в производительности ext4". Почему оно уступает мне по глубокому барабану. И для меня первична производительность, а не снапшоты через 30 сек. В офисе, в котором работаю, есть плагин для сохранения в гугледоки, и мне совершенно не нужен этот снапшот через каждые 30 сек. Плюс бэкапы 2 разы в день
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	160. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 22:35
	> в производительности ext4". Почему оно уступает мне по глубокому барабану. Запорожес с горы Арарат легко обгонит какой-нибудь Феррари. Будешь водителем запорожца? :)
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	169. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 21-Дек-12, 20:26
	> Тупить оно начнет если сделать кучу снапшотов, Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах начинает тупить? В ZFS "по барабану", сколько снапшотов. > забыв о том что отличия > между ними хранятся и жрут место, и потом долго фигарить на > своей волне, нарастив огромный объем изменений относительно снапшота. И что?
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	176. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 27-Дек-12, 22:39
	> Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах > начинает тупить? В ZFS "по барабану", сколько снапшотов. Да, там путем черной магии обманывают физику и логику, ну конечно же :). Особенно эпично подобные заявы смотрятся от эксперта по получению 6Мб/сек на шпиндель, который даже в такой позе и то не забывает верещать что дефрагер - лишний понт. Ну, знаешь, не у всех понятия о производительности дисковых ФС такие же как у тебя :) >> своей волне, нарастив огромный объем изменений относительно снапшота. > И что? И то - и фрагментация растет + оверхед на майнтенанс "лоскутного одеяла" выше. Чудес не бывает. И если б ты не был жабистом и понимал как работают компьютеры, ты бы понял почему лоскутное одеяло из кучи кусочков не сможет разогнаться до той же скорости что и большой непрерывный кусок, читаемый одним чихом.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

31. "Очередная порция улучшений в Btrfs"	+1 +/–
Сообщение от Аноним (??) on 18-Дек-12, 23:41
> По числу строк кода всех остальных опережает Стефан (Stefan) > Джозеф (Josef) работал над производительностью синхронной записи. Прямо клуб анонимных разработчиков "Здравствуйте, меня зовут Джозеф, и я уже три года работаю над производительностью синхронной записи"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 01:39
	Это чтобы использующие это уже сейчас в "продакшн" по совету суседелов не отловили и не насовали ему за потерю данных.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	59. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 10:35
	А что, при более медленной синхронной записи выше вероятность их потери?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	69. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от К.О. on 19-Дек-12, 16:04
	Чем больше время операции тем выше вероятность сбоя во время операции.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

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

39. "Очередная порция улучшений в Btrfs"	–3 +/–
Сообщение от Anonus on 19-Дек-12, 02:51
Очередная порция исправлений и улучшений... Видать "14 февраля" наступит таки не раньше чем через три-пять лет, даже не смотря на радужные заявления SUSE. Этот долгострой уже давно напоминает своей эпичностью незабвенное PulseAudio.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "Очередная порция улучшений в Btrfs"	+3 +/–
	Сообщение от Аноним (??) on 19-Дек-12, 03:29
	PulseAudio был готов с 1 версии и оллично работал, в том чисте и у меня. Не его проблема что он пользовался документированными возможностями ALSA, криво реализованными. Вот ALSA и чинили эпично.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	66. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 14:55
	Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни мог додуматься только поцтеринг.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	79. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:17
	> Пользоваться функциями ALSA, в которой баг на баге? Да, до такой херни > мог додуматься только поцтеринг. Ой, оказывается в софте бывают баги. Надо же, открытие века.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

46. "Очередная порция улучшений в Btrfs"	–1 +/–
Сообщение от Аноним (??) on 19-Дек-12, 06:44
"добавивший возможность замены диска в процессе эксплуатации" в btrfs небыло горячей замены диска? spare-дисков там тоже нету?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	48. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 07:22
	А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме как для извращений "а вот у меня рейд прямо в файловой системе"?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от dalco (ok) on 19-Дек-12, 07:52
	> А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме > как для извращений "а вот у меня рейд прямо в файловой > системе"? Когда конфигурация дискового пула стабильна, то, в большинстве случаев, оно без разницы - какими средствами raid организован (MD/HW/BTRFS/ZFS). А вот если количество и объем винтов постоянно гуляет, то FS, берущая на себя управление рейдом, оказывается выгоднее - тупо гораздо меньшее количество дисковых операций при изменении конфы дискового пула.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	53. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 09:33
	> А вот если количество и объем винтов постоянно гуляет - самое время решить админа премии, а то и уволить, за открытую дестабилизацию системы. Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	54. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 10:00
	> Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо > расширение объёма - но эта операция, на чём бы RAID ни > был собран, является операцией критичной, и требует планирования работ. Кроме того, > правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления > винта каждый месяц можно поставить 12 винтов сразу, и забыть на > полгода. а что критичного в этой операции? уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп (хотсвоп) или просто доставил винты, подключил к пулу и пошел пиво пить. юзеры как работали, так и работают дальше ничего не замечая.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	55. "Очередная порция улучшений в Btrfs"	+4 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 10:05
	> а что критичного в этой операции? Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный бэкап перед операцией должен быть. Да, речь про рейды, а не про спаны. > уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот об этой критичности как раз и речь. Обязательно надо планировать возможность простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже если это кластер. Потому что выход кластера в нештатный режим - тоже проблема, и серьезная. > подключил к пулу и пошел пиво пить А в это время (с)... так и пивом можно подавиться в пессимистичном варианте.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	60. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 10:49
	>> а что критичного в этой операции? > Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный > бэкап перед операцией должен быть. Да, речь про рейды, а не > про спаны. Не так пойдет - если вы с пьяного глаза, выдерните винт из соседнего сервера, а потом завалите стойку, запнувшись об свою ногу и в процессе падения умудритесь еще ухватить толстый жгут витой поры. >> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп > Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания > операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот > об этой критичности как раз и речь. Обязательно надо планировать возможность > простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже > если это кластер. Потому что выход кластера в нештатный режим - > тоже проблема, и серьезная. А дальше ничего страшного, у нас же raidz2, а то и raidz3 на шибко больших массивах.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	64. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 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 :)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	81. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:20
	> Флаг в жо^W руки - считать на CPU RS-коды. Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно вычислить посмотрев с какой из них чексуммы сходятся.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	90. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 18:12
	> Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно > вычислить посмотрев с какой из них чексуммы сходятся. Так речь про Z2/Z3 или все-таки про R5/Z?
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	96. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 18:57
	> Так речь про Z2/Z3 или все-таки про R5/Z? Про сабжа и raid 5 :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	120. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 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 :) как бы вам это донести... у меня зфс пережила то, что не пережили железные контроллеры... вижу вы уже поняли, что нельзя полагаться на железо, теперь вам пену у рта надо подтереть и подумать, если вы способны на это.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	154. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:56
	> как бы вам это донести... у меня зфс пережила то, А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	156. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 20-Дек-12, 18:11
	>> как бы вам это донести... у меня зфс пережила то, > А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector. Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и не было на тот момент штатной команды "zpool import -F".
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	161. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 20-Дек-12, 22:39
	> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и > не было на тот момент штатной команды "zpool import -F". Проблема на самом деле не в том. А в том что средств для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула как я понимаю нет и не планируется. Такой подход невыгодно отличается от традиционного в случае когда что-то пошло не так, факап получился и авария вышла за те рамки которые предусматривали проектировщики ФС в своем сферическом вакууме.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	168. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 21-Дек-12, 20:19
	>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и >> не было на тот момент штатной команды "zpool import -F". > Проблема на самом деле не в том. А в том что средств > для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула > как я понимаю нет и не планируется. Видишь ли, сам принцип CoW не может позволить навернуться существующим данным и новым данным записаться "не туда". Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW). Это делается чаще автоматически при восстановлении после сбоев, но иногда случаются казусы при серьёзных сбоях, когда пул потерял избыточность и получить _непротиворечивые_ метаданные неоткуда. В последнем случае требуется ручной импорт пула командой "zpool import -F" с целью проанализировать потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться достать данные, которые уцелели. > Такой подход невыгодно отличается > от традиционного в случае когда что-то пошло не так, факап получился > и авария вышла за те рамки которые предусматривали проектировщики ФС в > своем сферическом вакууме. Классический подход с fsck связан с offline-проверкой и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте сами кашу из анонимных файлов. scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения вплоть до имён потерянных файлов с полными путями к ним.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	177. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 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 к геморности разруливания вручную каждый лишний уровень абстракции даст. Дата рекавери лабы в курсе и за любой вид рэйда сразу накидывают изрядно бабла к стоимости процедуры.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	179. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 28-Дек-12, 09:37
	Плюсую. Всегда приятно видеть человека, разбирающегося в работе системы глубоко.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	181. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от iZEN (ok) on 29-Дек-12, 17:07
	>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и >> не было на тот момент штатной команды "zpool import -F". > Проблема на самом деле не в том. А в том что средств > для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула > как я понимаю нет и не планируется. zdb — штатная утилита отладки ZFS. > Такой подход невыгодно отличается > от традиционного в случае когда что-то пошло не так, факап получился > и авария вышла за те рамки которые предусматривали проектировщики ФС в > своем сферическом вакууме. Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	182. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 29-Дек-12, 22:13
	> Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего > не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck. Проще задать вопрос: а собственно, где ныне Sun со своими мега-разработками :)
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	56. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от dalco (ok) on 19-Дек-12, 10:09
	>Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода. Я уважаю ваше мнение и оно вполне справедливо для идеального случая. К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых полках или свободных винтов, которые можно запихнуть туда "про запас" на пол-года вперед. И проблема не в админе, а в финансировании (начальство на спичках экономит). Или, что тоже часто бывает, всплывает задача, которую надо решить "здесь и сейчас" без оглядки на планы КПСС для третьей пятилетки. Так что лишняя гибкость в конфигурации дискового пула никому не помешает. Если оно _вам_ не нужно, то это еще не значит, что оно _никому_ не нужно ⓒ
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	57. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 10:15
	> Я уважаю ваше мнение и оно вполне справедливо для идеального случая. Оно справедливо для случая, когда и админ, и руководство - вменяемы. В России это встречается не часто, угу. > К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых > полках или свободных винтов, которые можно запихнуть туда "про запас" на > пол-года вперед. Это проблема планирования нагрузки, и решается она административно. > И проблема не в админе, а в финансировании (начальство на спичках экономит). Ну Россия, да, угу... > Если оно _вам_ не нужно, то это еще не значит, что оно > _никому_ не нужно ⓒ Оно не не нужно, оно неправильно и рискованно.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	51. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 19-Дек-12, 08:27
	> А оно, простите, нужно? При наличии md / HW RAID? Да. Так как классические решения не обеспечивают сквозную целостность данных и другие полезные фишки на уровне свойств отдельных файловых систем. Кроме того, хардварный RAID стоит денег не только за саму железку, но и за гарантийные обязательства по её сопровождению и замене в случае отказа. Грубо говоря: всегда нужно где-то рядом иметь резервный контроллер на случай внезапного отказа рабочего. Софтверные решения здесь явно в плюсе, так как не требуют уникального оборудования минимум в двух экземплярах. Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что...
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	52. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 09:32
	> Да. Так как классические решения не обеспечивают сквозную целостность данных Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять. > полезные фишки на уровне свойств отдельных файловых систем Какие именно? > Кроме того, хардварный RAID стоит денег не только за саму железку, но и за > гарантийные обязательства по её сопровождению и замене в случае отказа Именно! В этом и плюс железки по сравнению с unsupported решением. > всегда нужно где-то рядом иметь резервный контроллер на случай внезапного > отказа рабочего В случае отказа софтового непонятного решения ака "RAID в FS" не поможет уже ничего. md в этом плане куда лучше - он достаточно стандартен, и не использует туевой хучи метаданных для поддержания собственной функциональности.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	63. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 19-Дек-12, 13:55
	> Твоя СЦД - это миф. Она не моя, а ваша — сквозная целостность в Btrfs, за которую я не поручусь. А вот ZFS уже спасла от разрушения многие терабайты данных. > Правда, не понимая принципов работы железа, этого не понять. Железо без софта мёртво. Не понимая работы софта, а так же какой драйвер кем пишется и в каких условиях, трудно прогнозировать надёжность такой системы хранения.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	65. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok) on 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 раз бОльших вложений средств. А вы пытаетесь заменить это нищебродским решением, в надежде, что "усё будет"
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	70. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 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.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	82. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:21
	> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять. Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я думаю что знаю ответ. И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? Если уж бряцать громкими терминами охота.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	92. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от iZEN (ok) on 19-Дек-12, 18:25
	> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? Обеспечит одно — прекращение работы с пулом.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	97. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 19:02
	> Обеспечит одно — прекращение работы с пулом. А как ты узнаешь когда тебе уже прекращать работать с пулом?
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	125. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 20-Дек-12, 07:33
	>> Обеспечит одно — прекращение работы с пулом. > А как ты узнаешь когда тебе уже прекращать работать с пулом? Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут доступны.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	129. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от AlexAT (ok) on 20-Дек-12, 08:05
	> Пул перейдёт в состояние STOPPED. Файловые системы в пуле, соответственно, не будут > доступны. Пул о повреждении памяти узнает очень и очень поздно.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

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

	101. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok) on 19-Дек-12, 19:25
	>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? > Обеспечит одно — прекращение работы с пулом. А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	126. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от iZEN (ok) on 20-Дек-12, 07:36
	>>> И да, если изен такой умный - пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? >> Обеспечит одно — прекращение работы с пулом. > А система об этом не узнает долго-долго, пока вновь не попытается считать поврежденный до записи блок с диска. Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками во время записи данных, и они не могут определить просираемость данных на этом этапе? Ошибаешься — это не "классика" на md.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	130. "Очередная порция улучшений в Btrfs"	+3 +/–
	Сообщение от AlexAT (ok) on 20-Дек-12, 08:06
	> Думаешь, у таких "монстров" Btrfs и ZFS нет обратной связи с дисками > во время записи данных, и они не могут определить просираемость данных > на этом этапе? Ошибаешься — это не "классика" на md. Бугага. 100% незнание предмета детектед. Запись-то корректно пройдёт. Вот только данные будут "не те".
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	121. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 06:19
	>> Твоя СЦД - это миф. Правда, не понимая принципов работы железа, этого не понять. > Просто спроси этого клоуна: у него оперативка с ECC хотя-бы есть? Я > думаю что знаю ответ. И да, если изен такой умный - > пусть скажет, что обеспечит целостность данных при сбое оперативки или проца? > Если уж бряцать громкими терминами охота. я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	151. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-12, 17:27
	> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше? Мы можете :) предположить что если уж понтоваться надежностью - то наверное на надежном железе. Где хотя-бы оперативка с ECC, etc. А не как изен - "без порток, но в шляпе".
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	165. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-12, 18:59
	>> я лучше спрошу тебя, клоуна: ты можете предложить что-то другое, лучше? > Мы можете :) предположить что если уж понтоваться надежностью - то наверное > на надежном железе. Где хотя-бы оперативка с ECC, etc. А не > как изен - "без порток, но в шляпе". а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи...
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	178. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 27-Дек-12, 23:39
	> а... ну т.е. ECC доверять можно 100%, хорошо. про процессор мне еще расскажи... На 100% во всех случаяю - нельзя, но как минимум если проблема, особенно на уровне железа а не частиц из космоса есть - шансы узнать о ней значительно повышаются. Процессор сложнее - стопроцентная проверка достоверности работы CPU штука сложная и дорогая. Тем не менее, соломку в виде ECC у кэшей там вполне себе подстеливают.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	108. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok) on 19-Дек-12, 20:24
	> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что... А вы вообще Linux в глаза видели?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	127. "Очередная порция улучшений в Btrfs"	–3 +/–
	Сообщение от iZEN (ok) on 20-Дек-12, 07:40
	>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что... > А вы вообще Linux в глаза видели? Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не русифицирован. Но в интернет вылез спокойно.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	132. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok) on 20-Дек-12, 12:46
	>>> Но md не обеспечивает сверки данных на лету в RAID-5 (для зеркала вроде сделали). Так что... >> А вы вообще Linux в глаза видели? > Да недавно запускал Linux Mint Кинамон-какой-то. Не понравилось то, что он не > русифицирован. Но в интернет вылез спокойно. Ну да, я к тому - что в ваших комментариях только и читается "обои не понравились".  Боюсь, более содержательных знаний о Linux, в частности по работе md - вы не имеете...
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	135. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok) on 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 научили делать синхронное сравнение блоков в зеркале при обычном чтении.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	138. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от myhand (ok) on 20-Дек-12, 16:40
	> Я слежу за новостями. То, что вы процитировали - не "новости", а срач на лоре. > Вот тройка ссылок про md: Вы еще "Московский Комсомолец" ссылки забыли, да.  Собственно, "тесты" показаны в расчете на школоту, которая доверчиво смотрит в рот "тестеру".  ЛОР есть ЛОР. > Но сравнительно недавно новость была на opennet.ru, что md научили делать синхронное > сравнение блоков в зеркале при обычном чтении. Скорее всего, вы просто не поняли все слова.  Я постараюсь вам помочь, если вы вспомните новость. PS: Уж никак чтение не может быть "обычное" - описываемая вами фича (о которой я сходу не вспомню и по логам тоже не вижу) носит явно опциональный характер.  Ввиду ограниченной сферы применения и сопутствующей деградации производительности.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	49. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от dalco (ok) on 19-Дек-12, 07:42
	Менять можно было, но неудобно и долго. Кажется, выглядело оно примерно так: 1. Даем команду на извлечение диска 2. Идет полный ребаланс FS (это очень долго) 3. Вытаскиваем диск, вставляем новый 4. По идее, надо делать ребаланс еще раз. Впрочем, могу и ошибаться в последовательности действий - у меня btrfs  в качестве эксперимента только на одном винте жила.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

68. "Очередная порция улучшений в Btrfs"	+/–
Сообщение от CssfPZS (ok) on 19-Дек-12, 15:23
>Кроме того, на повестке дня актуальным вопросом остается полное исправление коллизий >хэшей, так как потенциально это позволяет проводить атаки для вызова отказа в обслуживании. Что они там курят/колят в вену? =) Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть: https://ru.wikipedia.org/wiki/%D0%A5%D0%... P.S. Все меньше желания пробовать эту кривую поделку после вот таких вот новостей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	71. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от абыр on 19-Дек-12, 16:24
	То что вы процитировали это какие-то эротические фантазии аффтара новости. В pull-request'e нет ничего похожего на эту фразу.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	78. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:17
	> Любая хэш функция по определению имеет коллизии (Невозможно отобразить большее множество > в меньшем без коллизий). Сомневающиеся могу погуглить или в википедии глянуть: Речь про защиту от управляемого создание коллизий, как правило проблема решается добавлеием пары случайных байт к данным, полученным от пользователя.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	83. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (??) on 19-Дек-12, 17:24
	> Любая хэш функция по определению имеет коллизии Имелась в виду замена алгоритма CRC32 на иной, более устойчивый к целенаправленной массовой генерации коллизий со стороны вредителя. Пока починили только баг с обработкой очень массовой коллизии. Но сильное проседание скорости при таких махинациях никуда не делось.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

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

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