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

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

"Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
Сообщение от opennews on 26-Апр-13, 23:34
Хостинг-оператор Anchor опубликовал (http://www.anchor.com.au/blog/2013/04/the-btrfs-backup-exper.../) отчёт о тестовом внедрении файловой системы Btrfs на нескольких серверах, обеспечивающих работу системы резервного копирования. В итоге сделан вывод о том, что несмотря на обилие интересных возможностей и прогресс в развитии Btrfs, данная ФС ещё не готова для промышленного использования из-за наличия некоторых подводных камней и нерешённых проблем. Тем не менее для ознакомительного использования не на критически важных системах, таких как рабочие станции или персональные серверы, Btrfs уже можно использовать.  Компания Anchor вернула на Ext4 системы, на которых был произведён переход на Btrfs, но указала на то, что будет отслеживать состояние разработки ZFS и Btrfs для перехода на одну из данных ФС в будущем. В процессе эксперимента отсутствовали инциденты с потерей данных, успешно создавались тысячи снапшотов, средствами Btrfs было выявлено повреждение одного бита информации в RAID-массиве. Из проблем отмечалось блокирование ввода/вывода в пики создания разом большого числа резервных копий данных разных клиентов. Ошибка в коде с реализацией системы квот  qgroups приводит к мягким зависаниям  CPU, c восстановлением только после перезагрузки. Перезагрузка приводит к необходимости перестроения некоторых служебных структур из-за повреждения кэша свободных блоков. Перестроение достаточно длительный процесс, для  16TB раздела длящийся более часа. Ещё одна  серьёзная проблема связана с непредсказуемостью переполнения Btrfs-раздела и связанным с исчерпанием свободного места замедлением работы. Неаккуратный запуск rsync настолько замедил работу с ФС, что с ней невозможно было работать. URL: http://www.anchor.com.au/blog/2013/04/the-btrfs-backup-exper.../ Новость: http://www.opennet.me/opennews/art.shtml?num=36803
Ответить | Правка | Cообщить модератору

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

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

1. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+26 +/–
Сообщение от Анонимус_б6 on 26-Апр-13, 23:34
это вам не похороникс сравнил убунту и федору...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от z (??) on 26-Апр-13, 23:39
	>Ещё одна серьёзная проблема связана с непредсказуемостью переполнения Btrfs-раздела и связанным с исчерпанием свободного места замедлением работы. Превед от Шишкина =)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 00:00
	> Превед от Шишкина =) А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+3 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 00:27
	Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас в очках на аэроплане").
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 27-Апр-13, 01:53
	> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума > не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас > в очках на аэроплане"). Скорее, хватает ума понять, что метаданные - неотъемлемая часть ФС, и требовать 100% использования места под данные бессмысленно.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Deffic on 27-Апр-13, 03:56
	> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума > не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас > в очках на аэроплане"). "том на 600Мб" -- 10 лет нвзад "забитый мелкими файлами" -- Maildirs
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	23. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от angra (ok) on 27-Апр-13, 10:43
	Во-первых, не 10, а 15. Во-вторых, с учетом скорости развития IT это звучит примерно как жалоба на то, что современный пулемет за минуту тратит патронов больше чем, чем полтора века назад батальон с винтовками за неделю.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	72. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (??) on 28-Апр-13, 12:48
	Что характерно, общая сложность задач возросла может быть в разы, но не на порядки же.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	10. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 27-Апр-13, 01:54
	> А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина? Маловероятно. Одно дело - пригорание седалища у отдельно взятого разработчика, другое дело - опыт практической эксплуатации.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от z (??) on 27-Апр-13, 10:25
	Критика Шишкина, напомню, касалась 'разноса' ФС при определённых условиях, когда из-за непонимания 'практиками' выбранных ими алгоритмов происходила жуткая внутренняя фрагментация метеданных, съедающая ощутимую часть места на диске. И т.к. это дефект на уровне алгоритмов, значит в корне не лечится по определению, только костыли и подпорки. Вообщем, enjoy your practice, dear permanent beta-testers =)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от quux (??) on 27-Апр-13, 12:16
	Шишкин, перелогиньтесь.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	26. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 12:34
	> метеданных, съедающая ощутимую часть места на диске. Любую ФС можно загнать в ситуацию когда ее КПД равен нулю. Создаем до упора файлы нулевого размера - и все, вуаля: на томе 0 байтов данных и весь том забит до отказа метаданными. Катит на совершенно любой ФС. Приветы Шишкину и прочим идеалистам :).
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	33. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+4 +/–
	Сообщение от z (??) on 27-Апр-13, 13:50
	>Создаем до упора файлы нулевого размера >Приветы Шишкину и прочим идеалистам Приятно видеть человека, который пытается думать, даже несмотря на то, что у него это довольно плохо получается Ещё раз повторюсь: речь не о том, что метаданные занимают какое-то место, т.к. предложенным выше способом можно 'повалить' любую ФС Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных узлов и само дерево соотв. аномально растёт. Т.е. место тратится не непосредственно полезными (мета)данными - место просто уходит В НИКУДА. Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым monkey-тестерам =)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	36. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok) on 27-Апр-13, 15:51
	> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда > балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных > узлов и само дерево соотв. аномально растёт. Т.е. место тратится не > непосредственно полезными (мета)данными - место просто уходит В НИКУДА. А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? > Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым > monkey-тестерам =) Ну, автор поста, похоже, не прогуливал? И сейчас даст всем прикурить.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от z (??) on 27-Апр-13, 15:54
	>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? https://lkml.org/lkml/2010/6/18/144
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+3 +/–
	Сообщение от z (??) on 27-Апр-13, 16:07
	Хорошо сказал, между прочим: >If you decide to base your file system on some algorithms then please use the original ones from proper academic papers. DO NOT modify the algorithms in solitude: this is very fragile thing! All such modifications must be reviewed by specialists in the theory of algorithms. Such review can be done in various scientific magazines of proper level. Перевожу на русский: если вы решили создать вашу файловую систему на каких-то алгоритмах - тогда пожалуйста используйте оригинальные из соотв. научных работ. НЕ МОДИФИЦИРУЙТЕ алгоритмы самостоятельно: это очень хрупкая вещь! Все подобные модификации должны быть рассмотрены специалистами в теории алгоритмов. Подобные обзоры могут быть (уже) сделаны в различных научных журналах соотв. уровня Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное - не пытайся что-либо в этом менять, чтобы не было фейлов уровня дебиановского openssl
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	42. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok) on 27-Апр-13, 17:35
	> Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное > - не пытайся что-либо в этом менять, чтобы не было фейлов > уровня дебиановского openssl Там другое, авто-проверки ругнулись на непонятные им данные, инициализцию и екнули. Таки да, не двоечник и сам должен понять суть :) Вопрос-то теперь академический.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	39. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Bx (ok) on 27-Апр-13, 16:49
	>>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? > https://lkml.org/lkml/2010/6/18/144 Мде, пруф искать лень, что-то там про 640 килобайт тоже было, не 3 года, конечно, но... :) >> # for i in $(seq 1000000); \ >> do dd if=/dev/zero of=/mnt/file_$i bs=2048 count=1; done >> (terminated after getting "No space left on device" reports). >> >> # ls /mnt | wc -l >> 59480 Воспроизвел, правда, 1М на 100К поменял for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; done Filesystem     1K-blocks   Used Available Use% Mounted on /dev/loop1        674816 450664    220064  68% /mnt/0 System: total=4.00MB, used=8.00KB Data+Metadata: total=655.00MB, used=440.09MB 691011584 Apr 27 16:33 btrfs.img Сорри, забыл ls /mnt/0/ | wc -l 100003
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	43. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 27-Апр-13, 17:36
	>[оверквотинг удален] >>> 59480 > Воспроизвел, правда, 1М на 100К поменял > for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; done > Filesystem     1K-blocks   Used Available Use% Mounted > on > /dev/loop1        674816 450664   >  220064  68% /mnt/0 > System: total=4.00MB, used=8.00KB > Data+Metadata: total=655.00MB, used=440.09MB > 691011584 Apr 27 16:33 btrfs.img И что не нравится ? Трата места на метаданные ? Повторите этот же тест с разделом в 100 раз больше и сравните результаты.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	44. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok) on 27-Апр-13, 17:46
	> И что не нравится ? Трата места на метаданные ? Повторите этот > же тест с разделом в 100 раз больше и сравните результаты. Я, как-бы, защитник btrfs :) Потрудитесь почитать линк, на который я отвечал.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	45. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 18:21
	> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда > балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных > узлов и само дерево соотв. аномально растёт. И чем это так уж отличается от иных вырожденных случаев, типа забития тома нулевыми файлами? Где оценки масштаба эффекта в реальных применениях? Том на 600 метров забитый мелочью - откровенная синтетика. Я даже предложил доразвитие идеи до логичного финала :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	48. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от arisu (ok) on 27-Апр-13, 18:36
	в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда что попало разных размеров. этого с b-tree делать *нельзя*. от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл использования сей няшной структуры. и если бы это было единственное, что они решили «улучшить»… на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	51. "Хостинг-оператор Anchor протестировал Btrfs на..."	–2 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 22:24
	> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать. А что тут такого нехорошего?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	56. "Хостинг-оператор Anchor протестировал Btrfs на..."	+3 +/–
	Сообщение от arisu (ok) on 27-Апр-13, 23:44
	>> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать. > А что тут такого нехорошего? просто никогда не пиши реализацию хэш-таблиц, хорошо? воспользуйся готовой из стандартной библиотеки какого-нибудь языка: с вероятностью, близкой к 100%, она будет лучше того, что ты напишешь. потому что пользоваться гуглем — судя по этому вопросу — ты не способен.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

Часть нити удалена модератором

	66. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от arisu (ok) on 28-Апр-13, 00:59
	больше заискивающих смайликов, больше.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Хостинг-оператор Anchor протестировал Btrfs на..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 29-Апр-13, 18:01
	> больше заискивающих смайликов, больше. Сдаётся мне, это опять демагог debugger.  Порешил.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	68. "Хостинг-оператор Anchor протестировал Btrfs на..."	–1 +/–
	Сообщение от Аноним (??) on 28-Апр-13, 01:36
	> в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при > помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда > что попало разных размеров. этого с b-tree делать *нельзя*. Если уж на то пошло, у очень многих алгоритмов применяемых нынче в софте "средний" случай и "наихучший" очень сильно варьируются. Можно вспомнить например волну атак на хэш таблицы где подбором данных можно выпасть далеко за пределы O(1) который они обеспечивают "в среднем" :). > от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл > использования сей няшной структуры. Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки. > и если бы это было единственное, что они решили «улучшить»… на вскидку > — использование crc как хэш-функции: это тоже очень круто. настолько круто, > что просто обнять и плакать. Да вообще-то это обычная практика. А то что особо хитрый хакер может специальным образом файлы создавать - так я тебе твой же пример с хакером и солонками в столовой и приведу, хренли ты хотел? Прикольно же долбануть Кэпа его собственным вооружением в качестве легкого сарказма :)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	107. "Хостинг-оператор Anchor протестировал Btrfs на..."	–1 +/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 19:29
	> Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки. В новостях пробегало - достаточно создать всего 64 файла что бы убить  btrfs.. вот так..
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	4. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Аноним (??) on 26-Апр-13, 23:59
	Похороникс чуть раньше сравнил ZFS и EXT4. Результат был предсказуем...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	15. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–6 +/–
	Сообщение от iZEN (ok) on 27-Апр-13, 08:06
	Это что ли сравнение: http://www.phoronix.com/scan.php?page=news_item&px=MTM1ODk ?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	29. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 12:38
	> Это что ли сравнение: http://www.phoronix.com/scan.php?page=news_item&px=MTM1ODk Ты как-то очень изящно подтасовываешь результаты. Я про http://www.phoronix.com/scan.php?page=news_item&px=MTM1NTA разумеется. А то что на многодисковой конфиге ext4 не обязан хорошо работать - дык это, иди XFS там побивай. А на однодисковой конфиге ext4 просто разгромил zfs. Т.к. у самого по себе дизайна нет никаких особых поводов проявлять резвость самому по себе.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

3. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–4 +/–
Сообщение от iZEN (ok) on 26-Апр-13, 23:52
Справедливости ради, ZFS тоже не любит многопоточного доступа. Раньше были вилы вплоть до прекращения всякого I/O при работающей системе (почему-то это связано с функцией сжатия файлов в архивы tbz и tgz). Сейчас более-менее наладилось раскидывание запросов к дисковой подсистеме.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 27-Апр-13, 00:38
	Почему не используешь EXT4 или NTFS ?))
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+12 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 01:52
	С чего вы взяли, что он не использует NTFS?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–11 +/–
	Сообщение от iZEN (ok) on 27-Апр-13, 08:14
	> Почему не используешь EXT4 или NTFS ?)) EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263 На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516 — журнал нужно обязательно отключать и монтировать в read-only, а то скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей контроллера флешатины). NTFS успешно использую на корпоративной рабочей станции.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	19. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+16 +/–
	Сообщение от www2 (ok) on 27-Апр-13, 08:58
	Пруфлинк не прокатит, т.к. не ясно в чём было дело - в глюке оборудования, кривых руках настройщика, убунте или в самом деле в фс. Однако, зная что soko1 - бсдешник, предполагаю что в первую очередь в кривых руках, вторая возможная причина - в оборудовании. То, что чел не попытался разобраться в чём было дело, а сразу пошёл кричать о глючности линукса, кагбэ намекает, чего стоит этот пруфлинк. Я по собственному опыту знаю, что глючат все файловые системы, особенно если бывают проблемы с оборудованием или электричеством. У меня и UFS2 ломалась (ещё в те времена, когда бсдешники кричали о том что журнал не нужен и есть Soft Updates - чекалось по полтора часа в фоне), и NTFS ломалась, и FAT32 ломалась и ReiserFS ломалась и Ext3 ломалась. Из них, естественно, самая ненадёжная - FAT32. Для ReiserFS практически отсутствуют инструменты для восстановления, когда уж совсем всё поломалось так, что даже fsck не может справиться. Поэтому на винде - NTFS, на Linux - Ext3 или Ext4 (на домашнем компе стоит, на серверах - Ext3). На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти, в итоге скорость записи упала в разы, откатились обратно.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	78. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 17:42
	>На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J Я на DFBSD мигрирую на Hammer, бо после пары факапов UFS доверия уже нет. Хотя Hammer тоже мне сюрприз подкинул - понадеявшись на дефолтные настройки, я прохлопал исчерпание места на диске.:)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	95. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Andrew Kolchoogin on 29-Апр-13, 11:20
	> На фре уж не знаю что лучше использовать, пожалуй UFS+SU+J, потому что ZFS жрёт > неоправданно много ресурсов. На работе бсдешники пробовали с UFS на ZFS перейти, > в итоге скорость записи упала в разы, откатились обратно. "No silver bullet". (C) Универсальной файловой системы на все случаи жизни нет и не будет. Реализуемые файловой системой свойства -- это всегда результат некоей торговли. И ценность торгуемых свойств очень сильно зависит от парадигмы отношения к хранимым на ФС данным. Например, если исходить из парадигмы "данные бесценны" (то есть, принципиально никаким способом не восстанавливаемы -- например, являются результатами метеорологических наблюдений), тогда кагбэ чихать на стоимость ОЗУ -- надо 4 гигабайта под кэш для файлухи, значит, поставим. Надо 16 -- поставим 16. В этой парадигме разговорчики а-ля "ну, вероятность потери данных при сбое равна ... " считаются оппортунизмом. :) Если же таких требований к данным не предъявляется, можно и не использовать ZFS. При наличии процедуры регулярного резервного копирования плевать с балкона, какая ФС. :) Ну, потратится время на восстановление с бэкапа, да... Ну, что-то там потеряется, что в промежутке между бэкапами было...
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	119. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 29-Апр-13, 20:23
	> Например, если исходить из парадигмы "данные бесценны" То начинать надо не с ZFS, да и заканчивать не ей. Репликация и только репликация, + контроль ошибок на всех уровнях _до_ диска.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	144. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 30-Апр-13, 16:15
	>> Например, если исходить из парадигмы "данные бесценны" > То начинать надо не с ZFS, да и заканчивать не ей. Репликация > и только репликация, + контроль ошибок на всех уровнях _до_ диска. Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности и оверхеду?
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	151. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от ананим on 30-Апр-13, 17:43
	Вот куда-куда, а под rdbms (и oltp, и dss) кладут zfs только полные дауны.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	152. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 18:07
	> Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах > OLTP? М? С конечной латентностью ну и соответствующими требованиями к надежности > и оверхеду? Выше правильно ответили - положить ZFS да и вообще CoW под RDBMS может только конченый идиот. Потому что параметр latency будет совершенно непредсказуемым.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	22. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+4 +/–
	Сообщение от AlexAT (ok) on 27-Апр-13, 10:32
	Маргиналы такие маргиналы.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	41. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 27-Апр-13, 17:34
	>> Почему не используешь EXT4 или NTFS ?)) > EXT4 не собираюсь использовать — слишком много костылей нагородили вокруг EXT2, да > и малонадёжная эта ваша ФС. Пруфлинк: http://www.linux.org.ru/forum/talks/8896263 > На флешке использовать данную ФС — полный бред: http://www.linux.org.ru/forum/general/8874385?cid=8874516 > — журнал нужно обязательно отключать и монтировать в read-only, а то > скорость ниже плинтуса. (Уж лучше UFS2, там хоть метаданные не пострадают > при внезапном выдёргивании, зато скорость записи-чтения на уровне скоростных показателей > контроллера флешатины). > NTFS успешно использую на корпоративной рабочей станции. NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :)))
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	46. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 18:32
	> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... :))) "Фрибздшники" палятся.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	49. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Карбофос (ok) on 27-Апр-13, 19:35
	ой! если бы там дело в дефрагментации было...
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	79. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–3 +/–
	Сообщение от Аноним (??) on 28-Апр-13, 17:44
	> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... > :))) Слишком толсто.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	98. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 29-Апр-13, 11:46
	>> NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю ... >> :))) > Слишком толсто. Это не шутка, если не делать дефрагментацию то тормоза можно почуствовать уже через неделю :))
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	99. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 29-Апр-13, 12:42
	Мне трудно представить, что надо делать с томом, чтобы производительность деградировала так сильно и так быстро.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	145. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 30-Апр-13, 16:15
	> Мне трудно представить, что надо делать с томом, чтобы производительность деградировала > так сильно и так быстро. CoW?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	11. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 02:06
	Это было когда Solaris API пытались приладить к FreeBSD.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	12. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 27-Апр-13, 02:49
	> до прекращения всякого I/O при работающей системе Круто. Впрочем там и веселее было - дедлок ядра при попытке вызвать sendfile(). > функцией сжатия файлов в архивы tbz и tgz). А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	16. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–6 +/–
	Сообщение от iZEN (ok) on 27-Апр-13, 08:08
	>> функцией сжатия файлов в архивы tbz и tgz). > А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам. А синюшника видно по чему? Проблема явно где-то в zlib(3).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	25. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от quux (??) on 27-Апр-13, 12:18
	>>> функцией сжатия файлов в архивы tbz и tgz). >> А вот это врядли. Впрочем, видно птицу по помету. В смысле, жабиста по тупым заявам. > А синюшника видно по чему? Проблема явно где-то в zlib(3). А как связаны архивы tbz и zlib ?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	27. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–10 +/–
	Сообщение от iZEN (ok) on 27-Апр-13, 12:34
	Колбэками вызовов функций сжатия, очевидно.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	30. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+8 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 12:47
	> Колбэками вызовов функций сжатия, очевидно. Все бы ничего, но bzip не имеет к zlib'у вообще никакого отношения. Это вообще совершенно другое семейство алгоритмов даже :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	52. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+5 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 22:26
	>> Колбэками вызовов функций сжатия, очевидно. > Все бы ничего, но bzip не имеет к zlib'у вообще никакого отношения. > Это вообще совершенно другое семейство алгоритмов даже :) С точки зрения Изи, это одна программа - 7z.exe :)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

13. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
Сообщение от Anonus (ok) on 27-Апр-13, 03:43
Шо, уже 14 февраля 2012 года таки наступило ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–6 +/–
Сообщение от iZEN (ok) on 27-Апр-13, 08:57
"Как у BTRFS со стабильностью и производительностью?" Как, как? Никак! https://plus.google.com/117537647502636167748/posts/F3GC4T4W99g Справедливости ради: "Как у EXT4 со стабильностью и производительностью?" Как, как? Никак! http://serverfault.com/questions/454889/ext4-kernel-panic
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 27-Апр-13, 09:30
	Что за выхлоп? Обычный протухший бит на диске. Да, и RAM сбоит, и шины данных сбоят, и поверхность диска, и логика диска которая по идее должна исправлять некоторые ошибки тоже ни марсианами сделана из вручную отобраннвх кварков атомов и молекул. И космические лучи все таки бороздят вселенную и могут редко не метко попасть и вызвать ложный сигнал.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	28. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–7 +/–
	Сообщение от iZEN (ok) on 27-Апр-13, 12:37
	> Что за выхлоп? Обычный протухший бит на диске. Да, и RAM сбоит, > и шины данных сбоят, и поверхность диска, и логика диска которая > по идее должна исправлять некоторые ошибки тоже ни марсианами сделана из > вручную отобраннвх кварков атомов и молекул. И космические лучи все таки > бороздят вселенную и могут редко не метко попасть и вызвать ложный > сигнал. Вот здесь всё намного хуже: http://www.youtube.com/watch?v=QGIwg6ye1gE Но ведь выживает, собака такая!
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	32. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от anonymous (??) on 27-Апр-13, 13:37
	RAID6 и любая фс тоже самое сделают. Это как раз таки очень легкий случай: полный вывод из строя одного носителя. Это больше демонстрация возможностей zpool, чем zfs. Если поднять ext4 поверх lvm с raid6 томом, можно будет развлечься аналогичным способом.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от ваноним on 27-Апр-13, 13:26
	стабильность ext4 в 2.6.18? ну-ну. в 2.4 с ext4 вообще полная жопа была trollface.jpg
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	34. "Хостинг-оператор Anchor протестировал Btrfs на..."	+2 +/–
	Сообщение от arisu (ok) on 27-Апр-13, 14:28
	> стабильность ext4 в 2.6.18? ну-ну. это ж фанобздоиды, у них такое считается «свежачком».
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	47. "Хостинг-оператор Anchor протестировал Btrfs на..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-13, 18:36
	> это ж фанобздоиды, у них такое считается «свежачком». Ну так их линукслятор как раз до 2.6.22 не добирает по фичам :).В 2.6.22 уже куски lxc появилисьь А такие навороты они уже не смогли. А понтов то джайлами было, понтов...
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	40. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+3 +/–
	Сообщение от Карбофос (ok) on 27-Апр-13, 16:56
	пшшшшшш! сейчас изя ещё багрепорты из 2.4 ветки принесёт.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	54. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от linux must _RIP_ on 27-Апр-13, 22:39
	паника в ext4? это не модно.. А вот последний тред в linux-ext4 из-за того что оказывается в linux mm - LRU кривой и вытесняет не те странички из памяти - весьма веселит..
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	71. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 09:48
	> из-за того что оказывается в linux mm - LRU кривой и > вытесняет не те странички из памяти - весьма веселит.. А можно сцылочку?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	74. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от arisu (ok) on 28-Апр-13, 14:00
	а не важно, что это существо пишет: это всегда ложь.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	104. "Хостинг-оператор Anchor протестировал Btrfs на..."	–2 +/–
	Сообщение от Michael Shigorin (ok) on 29-Апр-13, 18:07
	> а не важно, что это существо пишет: это всегда ложь. Не-а, порой есть сигнал.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	106. "Хостинг-оператор Anchor протестировал Btrfs на..."	+1 +/–
	Сообщение от arisu (ok) on 29-Апр-13, 18:15
	при таком уровне зашумлености проще игнорировать полностью, нежели пытаться добыть что-то полезное.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	130. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от Led (ok) on 30-Апр-13, 01:33
	>> а не важно, что это существо пишет: это всегда ложь. > Не-а, порой есть сигнал. Когда играют длинную симфонию, в тысячном зале чисто случайно, теоретически кто-то может пёрнуть и попасть "в ноту", и даже в ритм. Можно ли пёрнувшего назвать музыкантом (тем более, что это случайное "попадание" вони не отменяет)?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	113. "Хостинг-оператор Anchor протестировал Btrfs на..."	–1 +/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 19:56
	ну да, когда эта проблема стала темой обсуждения на FS & Storage Summit в SF, в где-то в районе 20 апреля этого года - то да, ложь.. А ты еще не устал защищать то в чем не разбираешься?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	116. "Хостинг-оператор Anchor протестировал Btrfs на..."	–3 +/–
	Сообщение от Michael Shigorin (ok) on 29-Апр-13, 20:07
	> А ты еще не устал защищать то в чем не разбираешься? Обоим: умерьте тон.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	120. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 21:07
	да ну? то есть призывать к аборту это нормально? Хм.. интересно как бы ты сдержался если это сказано было о твоей матери? хотя да.. это же твой любимец линуксоид :-) чего уж тут - ему все можно.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	108. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 19:35
	>> из-за того что оказывается в linux mm - LRU кривой и >> вытесняет не те странички из памяти - весьма веселит.. > А можно сцылочку? http://marc.info/?l=linux-ext4&m=136695619430425&w=2 как-то так.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	123. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 29-Апр-13, 21:38
	Не кривой уж тогда, а слегка быстро удаляет страницы в очень специфичном юзкейсе. Пробежал тред - народ изучает и ищет пути сделать универсальное решение, чтобы всем было хорошо. Причем фикс данного специфичного юзкейса потенциально ставит под угрозу типовые юзкейсы, и выглядит костыльно, поэтому решение достаточно нетривиальное, и до сих пор обсуждается. Думается, что если бы это было в другой ОС / коммюнити - на решение бы просто положили, ибо юзкейс действительно специфичный.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	128. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 23:15
	> Не кривой уж тогда, а слегка быстро удаляет страницы в очень специфичном > юзкейсе. в сильно специфичном? хм.. это теперь так называют полное игнорирование aging у LRU и запихивание страниц в inactive list вместо active.. мда... А test case простой - просто пишем через DIO много, много .. и получаем постоянные чтения с диска в момент записи - потому что система убивает метаданные в памяти. А все почему.. потому что накапливаем в pagevec и игнорируем mark_page_accessed(). > Пробежал тред - народ изучает и ищет пути сделать универсальное решение, чтобы > всем было хорошо. Причем фикс данного специфичного юзкейса потенциально ставит под > угрозу типовые юзкейсы, и выглядит костыльно, поэтому решение достаточно нетривиальное, > и до сих пор обсуждается. плохо читал. Типовой аргумент - это слишком много знаний о потрохах mm в FS. > Думается, что если бы это было в другой ОС / коммюнити - > на решение бы просто положили, ибо юзкейс действительно специфичный. Говорят - что кур тоже доят.. Может не будем выдумывать чего не знаем? :) А в linux комьюнити на твоем примере - очень хорошо заметно желание принизить ошибку (игнорирование mark_page_accessed()) и свести - "это же специфический use case".. мда.. повеселили :-)
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	136. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:35
	> полное игнорирование aging у LRU и запихивание страниц в inactive list вместо active Пруф в студию. Хотя бы прочитайте кейс - там всё расписано, что и как делается. И для чего. Запихивание кеша в inactive - это штатное поведение - поскольку иначе кешем будут выпихиваться полезные страницы. В своп. > А test case простой - просто пишем через DIO много, много... Опять же - пруф в студию. В указанном выше кейсе ситуация связана с большим чтением (3-4GB/s), быстрее чем хочет автор, выпихиваются страницы из кеша, включая страницы метаданных. Это также штатное поведение. Однако со страницами метаданных народ начал разбираться - ибо это не очень хорошо. > и получаем постоянные чтения с диска в момент записи - потому что система убивает метаданные в памяти. Пруф. > А все почему.. потому что накапливаем в pagevec и игнорируем mark_page_accessed(). mark_page_accessed() в том пути исполнения никогда и не было. Это уже следствие работы над кейсом. > Говорят - что кур тоже доят.. Может не будем выдумывать чего не > знаем? :) Да а чего выдумывать? В той же фряхе ядро при использовании IPv6 уже года 3 так и падает в кору. Это тебе не деградация производительности на специфичных юзкейсах, а несколько хуже.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

35. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
Сообщение от Fracta1L (ok) on 27-Апр-13, 14:58
Имею ничтожный с точки зрения продакшн-одминов опыт использования на домашнем десктопе как Btrfs, так и ZFS. Стандартные задачи: гента + медиапомойка. Btrfs использовал более года на SSD под системные (/ + /home) нужды. Плюсы: 1) Снапшоты 2) Сжатие (lzo весьма увеличивает скорость ФС и экономит место на таких каталогах как исходники ядра или дерево portage) 3) Надёжность (было в общей сложности около 15 жёстких ребутов, ФС не теряла файлы и не требовала проверки/починки) 4) Томами (subvolumes) оперировать так же легко и прозрачно, как обычными каталогами Минусы: 1) То, что в Btrfs называется снапшотами - по сути клоны, а не снапшоты, т.к. снапшот - это просто состояние ФС, его можно лишь прочесть, а в Btrfs в снапшоты можно и писать, что несколько неочевидно и снижает безопасность и сохранность) 2) Невозможно штатными средствами узнать сколько занимают снапшоты. Вообще, с диагностикой и аудитом у Btrfs огромные проблемы 3) Заметная (хотя и небольшая) просадка скорости работы с течением времени, особенно на большом количестве мелких файлов ZFS в общей сложности использовал месяца четыре, как на SSD для / + /home, так и на HDD для файлопомойки. Плюсы: 1) Высокая скорость работы на SSD, и, главное, стабильность этой скорости 2) Средства аудита и мониторинга великолепны. Штатными средствами можно узнать любую мелочь о созданных ФС и пулах 3) На одном пуле можно создать множество отдельных ФС ZFS с отдельными опциями (сжатие, чексуммы, кэширование и т.д.) 4) Снапшоты (только на чтение, можно делать откаты), клоны (это то, что в Btrfs называется снапшотами), дедупликация (жрёт оперативку в невменяемых количествах), сжатие (несколько алгоритмов на выбор), чексуммы (тоже несколько алгоритмов) и ещё куча всего, чего я даже пока ещё не пробовал. 5) Надёжность. Не представляю что нужно сделать чтобы убить эту ФС Минусов тоже хватает: 1) Жрёт оперативку под кэши за обе щёки, при этом аппетит не поддаётся контролю. 2) При забитом кэше на HDD эта ФС демонстрирует просто редкостную слоупочность. Связано это с самими алгоритмами размещения файлов на носителе - ZFS и фрагментация это единоутробные братья. Пример: есть каталог со скриншотами, который на Ext4 открывается (в KSnapshot, например, или в Dolphin) мгновенно, на ZFS с полным кэшем же он открывается несколько десятков секунд 3) Как мне кажется, вполне способна убить HDD раньше времени, т.к. бешено дёргает головки туда-сюда 4) В Linux приходится замещать встроенные в ZFS средства монтирования штатным средством Linux (mount), т.к. при выключении какие-то траблы с отмонтированием 5) Этой ФС нет и не будет в ядре, поэтому приходится возиться с initramfs В данный момент использую ZFS на SSD под систему и на одном HDD под медиапомойку. Уже сожалею, что впилил её на HDD, но снова меремещать туда-сюда 700 Гб данных уже неохота.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	50. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от deadless (ok) on 27-Апр-13, 22:13
	c ZFS очень хорошо помогает иметь отдельные устройства для zil log и L2ARC (это если мозга мало). А я вот перехожу на линукс и с ужасом выбираю ФС, их там чуть более чем до=я но все они как-то более чем бесполезны на моих задачах, и после ZFS на них смотреть буэээ, а ext4 + снапшоты от LVM тот еще садо-мазо... и не дай Бог вам их надо много... а мне надо $ zfs list -t snapshot|wc -l 269 я боюсь даже представить что будет с ext4 + LVM снапшотами при таком количестве. Ну а btrfs все еще бетта к сожалению и некоторые тонкости дизайна изначально не рулят. Фишки которым ищу замену - удобство создания пулов/фс, монтирования/отмонтирования, кучи настроек для ФС, плюшки типа zfs send|receive, много бесплатных по скорости снапшотов. Полагаю что прямых аналогов в линуксах нету, просто там это видимо делается по другому. Вопрос только как. :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	53. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от 666некто on 27-Апр-13, 22:30
	Я думал ФС нужна для хранения данных необходимых для решения задач бизнеса. А вам для создание пулов, настроек и send/receive...
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	55. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Карбофос (ok) on 27-Апр-13, 23:00
	а если это не бизнес, а "just for fun", то фс не подходит? как страшно жить! бизнесу, вообще жизненно необходима кнопка "решить все проблемы разом и бесплатно", как я понял
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	58. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 00:23
	> а если это не бизнес, а "just for fun", то фс не > подходит? как страшно жить! > бизнесу, вообще жизненно необходима кнопка "решить все проблемы разом и бесплатно", как > я понял В данном случае "для бизнеса" можно заменить "для использования".
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	70. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Fracta1L (ok) on 28-Апр-13, 07:25
	А что вам мешает использовать ту же ZFS и на Линуксе?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	77. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от iZEN (ok) on 28-Апр-13, 17:19
	> А что вам мешает использовать ту же ZFS и на Линуксе? Линукс и так переусложнён, а тут ещё столько же строк кода, как у XFS... Думаете, Росинант вынесет двоих (вместе с недоделанной Btrfs — троих)?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	87. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 20:22
	Ядро не сильно засрано в отличие от юзерспейсов, гнома с их зависимостями ...
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	73. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от Аноним (??) on 28-Апр-13, 13:16
	ZFS орудие будущего, когда уже не будет механики и такого понятия как "фрагментация".
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	75. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 16:19
	> ZFS орудие будущего, когда уже не будет механики и такого понятия как > "фрагментация". Почему это орудие будущего тогда не поддерживает TRIM?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	76. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–4 +/–
	Сообщение от iZEN (ok) on 28-Апр-13, 17:18
	>> ZFS орудие будущего, когда уже не будет механики и такого понятия как >> "фрагментация". > Почему это орудие будущего тогда не поддерживает TRIM? CoW ФС несовместимы с TRIM.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	81. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 18:47
	> CoW ФС несовместимы с TRIM. Бугага. BTRFS прекрасно совместим. Может быть, ZFS несовместима с TRIM? Хотя TRIM туда припёрли, да, напомнили в этой ветке. А можно объяснить - почему CoW несовместим с TRIM, и как выжить на флеше без этой операции?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	101. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от iZEN (ok) on 29-Апр-13, 15:56
	>> CoW ФС несовместимы с TRIM. > Бугага. BTRFS прекрасно совместим. Может быть, ZFS несовместима с TRIM? Хотя TRIM > туда припёрли, да, напомнили в этой ветке. > А можно объяснить - почему CoW несовместим с TRIM, и как выжить на флеше без этой операции? CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком. Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных. Если случается сбой ФС, то она должна откатиться на то состояние, которое было подтверждено предыдущей транзакцией, если это состояние тоже неконсистентно, то откат происходит дальше — и так до самого конца, когда на носитель делалась самая первая запись. Только в этом случае CoW ФС в принципе не нуждается в отдельной процедуре проверки целостности всех данных, а только в проверке консистентности последней транзакции при своей инициализации. Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство для манёвра отката и не способствует глубокому восстановлению ФС в случае значительных разрушений — в последнем случае необходима внешняя утилита для полной проверки целостности и фиксации нарушений (почти что сделано в Btrfs). В ZFS же повреждения ФС обходятся откатом на последнее консистентное состояние, монтированием (импортом) с последующим выяснением характера повреждения и недоступных данных (scrubbing). Если все физические устройства, из которых состоят виртуальные, физически целы, но часть из них перезаписаны внешними инструментами (dd, например, в то время, как ZFS находилась в оффлайне), при наличии отказоустойчивых конфигураций виртуальных устройств вероятность полного восстановления ZFS практически 100% без использования ручного запуска проверочных утилит.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	105. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Michael Shigorin (ok) on 29-Апр-13, 18:09
	> CoW ФС распространяется на всё доступное пространство блочного устройства hint: blocksize PS: в смысле тот, который устройство показывает наружу, а то ведь будете спорить.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	111. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от AlexAT (ok) on 29-Апр-13, 19:42
	Извини, бред про восстановления глубокие и неглубокие поскипан - не имеет отношения к теме. > CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком. Не CoW ФС, а ZFS. Более того, ZFS (как и почти любая FS) вообще ничего не знает об организации подлежащего устройства, и, как следствие, на ВЕСЬ флеш распространится не может ну совершенно никак - у него есть рабочий набор, который ОС не виден. > Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных. К сожалению, в нашем случае это решает левелер флеша. Который де факто та же самая CoW и есть. > Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство > для манёвра отката TRIM вообще не может никак уменьшать пространство - это функция только передает контроллеру флеша - какие блоки можно стереть. Ну и запускает GC, как правило. Тогда уж давайте говорить о том, что конкретно ZFS с текущей реализацией дисков на флеше несовместим вообще, ну никак. Ему можно дать голый MTD - и он будет выступать в роли недолевелера, но вот только незадача: стираться забитые блоки флеша будут только при перезаписи, а не в фоне, как левелером в SSD, и производительность при заполнении девайса транзакциями под завязку будет сильно ниже плинтуса. --- Да, CoW пытается взять на себя работу левелера, заполняет полностью дисковое пространство. Казалось бы - где бы прибахать TRIM к CoW? Всё просто: когда место подходит к концу - CoW FS, как правильно замечено, начинает стирать старые данные. И вот тут-то и можно очень легко помочь левелеру: CoW FS может сTRIM'ать не только то, что перезаписывается, а всю транзакцию, подлежащую удалению с диска, целиком. Сразу. И левелеру хорошо - в рабочий набор попал целый блок пространства флеша сразу, и CoW-механика поддерживается. Но это так, о птичках.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	131. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от iZEN (ok) on 30-Апр-13, 01:36
	> Извини, бред про восстановления глубокие и неглубокие поскипан - не имеет отношения > к теме. >> CoW ФС распространяется на всё доступное пространство блочного устройства и занимает его целиком. > Не CoW ФС, а ZFS. Более того, ZFS (как и почти любая > FS) вообще ничего не знает об организации подлежащего устройства, и, как > следствие, на ВЕСЬ флеш распространится не может ну совершенно никак - > у него есть рабочий набор, который ОС не виден. Я говорил про CoW ФС вообще. >> Со временем новые данные пишутся поверх помеченных к удалению самых старых не нужных данных. > К сожалению, в нашем случае это решает левелер флеша. Который де факто та же самая CoW и есть. В вашем случае он решает. В нашем случае TRIM ещё нестабилен и не перенесён из -CURRENT в -STABLE. >> Таким образом, TRIM (и последующий GC) для CoW ФС фактически уменьшает пространство >> для манёвра отката > TRIM вообще не может никак уменьшать пространство - это функция только передает > контроллеру флеша - какие блоки можно стереть. Ну и запускает GC, > как правило. ФС не скажет контроллеру: "TRIM", — GC в контроллере флэша никогда не заработает. А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?! Сам подумай. > Тогда уж давайте говорить о том, что конкретно ZFS с текущей реализацией > дисков на флеше несовместим вообще, ну никак. Ему можно дать голый > MTD - и он будет выступать в роли недолевелера, но вот > только незадача: стираться забитые блоки флеша будут только при перезаписи, а > не в фоне, как левелером в SSD, и производительность при заполнении > девайса транзакциями под завязку будет сильно ниже плинтуса. Вот только не заметил я что-то у себя ухудшения производительности ZFS на SSD. Когда ждать-то? > Да, CoW пытается взять на себя работу левелера, заполняет полностью дисковое пространство. Наконец-то, просвещение настало. > Казалось бы - где бы прибахать TRIM к CoW? Всё просто: > когда место подходит к концу - CoW FS, как правильно замечено, > начинает стирать старые данные. И вот тут-то и можно очень легко > помочь левелеру: CoW FS может сTRIM'ать не только то, что перезаписывается, > а всю транзакцию, подлежащую удалению с диска, целиком. Сразу. И левелеру > хорошо - в рабочий набор попал целый блок пространства флеша сразу, > и CoW-механика поддерживается. Но это так, о птичках. А она разве не это же делает, без всякого TRIM'а и GC со стороны контроллера флэша?
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	138. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:44
	> Я говорил про CoW ФС вообще. CoW FS бывают разные. > В вашем случае он решает. В нашем случае TRIM ещё нестабилен и > не перенесён из -CURRENT в -STABLE. Логично - ибо припёрт сравнительно недавно из нашего случая. > ФС не скажет контроллеру: "TRIM", — GC в контроллере флэша никогда не > заработает. Бредовое заявление. GC срабатывает при заполнении рабочего набора, или близкого к тому состояния. Если не тримать специфично - то сработает во время одной из записей, замечательно вогнав систему в ожидание операции. > А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?! Простой вопрос: каким образом TRIM удаляемой (подлежащей удалению) транзакции CoW мешает собственно логике CoW? > Вот только не заметил я что-то у себя ухудшения производительности ZFS на > SSD. Когда ждать-то? Когда флеш осыпется от числа перезаписей. А осыпется без TRIM он сравнительно быстро. Ну и да - устройство уже 100% заполнено данными CoW? Если нет - пока что говорить о чем-то рано. Еще возможен случай, когда устройство досталось уже заполненным, и никакой деградации уже не будет - просто потому, что уже достигнут нижний предел производительности при записи. > А она разве не это же делает, без всякого TRIM'а и GC со стороны контроллера флэша? Нет, не делает. Флеш еще и стирать надо иногда. И желательно - не в процессе записи, а в фоне. Чтобы не встать в ступор при очередной записи на время стирания. И - да - не путайте SSD и MTD.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	148. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от iZEN (ok) on 30-Апр-13, 17:20
	> GC срабатывает при заполнении рабочего набора, или близкого к тому состояния. Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно блоки освобождены, а пространство занято под ФС всё? ФС же не сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)? > Если не тримать специфично - то сработает во время одной из записей, замечательно вогнав систему в ожидание операции. Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется. >> А если скажет, то нафик ей хранить стадии собственного состояния, и нафик ей вся механика откатов CoW?! > Простой вопрос: каким образом TRIM удаляемой (подлежащей удалению) транзакции CoW мешает собственно логике CoW? Кто говорил что мешает? TRIM сокращает оперативный простор для отката CoW ФС, уменьшает глубину отката в случае серьёзных повреждений. Это — из-за того, что на флэше будет два набора: занятые блоки и готовые к записи/предварительно очищенные блоки. В случае отсутствия TRIM флэш под CoW ФС полностью занимается (со временем, конечно, не сразу): новые данные пишутся с предварительным очищением блоков от самых старых, помеченных к удалению блоков, размеры которых очень велики (128k) по сравнению с аппаратными блоками (4k). Очистка и перезапись больших блоков ФС (состоящих из наборов мелких аппаратных блоков флэша при условии выровненности по границам блоков) производится гораздо быстрее, чем если бы размеры блоков были равны или ненамного отличались (в случае классических ФС размеры блоков могут быть равны или в всего лишь в несколько раз превышать размер аппаратных блоков). >> Вот только не заметил я что-то у себя ухудшения производительности ZFS на SSD. Когда ждать-то? > Когда флеш осыпется от числа перезаписей. А осыпется без TRIM он сравнительно быстро. Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях. Про осыпания флэша без TRIM — вообще бред, я считаю. TRIM увеличивает деградацию носителя, так как помимо GC запускает процесс освежения данных.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	156. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 18:38
	> Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно > блоки освобождены, а пространство занято под ФС всё? ФС же не > сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)? Бугага. Ты не в курсе, что у левелера имеется невидимый ОС рабочий набор? И контроллер, когда ты пишешь данные на "заполненный" диск - пишет это в тот самый пресловутый рабочий набор. А освобождает его по мере возможности - в рамках GC. GC срабатывает не только на TRIM. > Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется. Хоть чего ты там группируй - а операция записи встанет на существенное для машины время. > TRIM сокращает оперативный простор для отката CoW ФС Это как, простите? TRIM'ается только то, что реально подлежит удалению. Далее бред поскипан. > Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи > от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях. И какова ныне скорость? А если сделать Factory Erase?
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	159. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от iZEN (ok) on 30-Апр-13, 19:56
	>> Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно >> блоки освобождены, а пространство занято под ФС всё? ФС же не >> сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)? > Бугага. Ты не в курсе, что у левелера имеется невидимый ОС рабочий > набор? И контроллер, когда ты пишешь данные на "заполненный" диск - > пишет это в тот самый пресловутый рабочий набор. А освобождает его > по мере возможности - в рамках GC. GC срабатывает не только > на TRIM. Нет, не в курсе. Я не сомневаюсь в том, что в SSD есть определённый набор запасных блоков флэш памяти для подмены "плохих секторов"и этот набор довольно велик, чтобы обеспечить безотказную работу массива многоуровневых ячеек MLS без деградации продолжительное время. А про "леверный набор" поёшь только ты. >> Если используется асинхронная запись (ZFS) и предварительная компоновка групп транзакций в памяти (UFS2 и ZFS), то это не так страшно, как кажется. > Хоть чего ты там группируй - а операция записи встанет на существенное для машины время. Как его прочувствовать, если операции записи происходят асинхронно?! >> TRIM сокращает оперативный простор для отката CoW ФС > Это как, простите? TRIM'ается только то, что реально подлежит удалению. > Далее бред поскипан. Устал протирать глаза на очевидные вещи. >> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи >> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях. > И какова ныне скорость? % diskinfo -t /dev/ada4 /dev/ada4     512             # sectorsize     64023257088     # mediasize in bytes (59G)     125045424       # mediasize in sectors     0               # stripesize     0               # stripeoffset     124053          # Cylinders according to firmware.     16              # Heads according to firmware.     63              # Sectors according to firmware.     0000000012170909003D    # Disk ident. Seek times:     Full stroke:      250 iter in   0.039546 sec =    0.158 msec     Half stroke:      250 iter in   0.038466 sec =    0.154 msec     Quarter stroke:      500 iter in   0.070313 sec =    0.141 msec     Short forward:      400 iter in   0.054375 sec =    0.136 msec     Short backward:      400 iter in   0.053934 sec =    0.135 msec     Seq outer:     2048 iter in   0.091451 sec =    0.045 msec     Seq inner:     2048 iter in   0.090278 sec =    0.044 msec Transfer rates:     outside:       102400 kbytes in   0.416739 sec =   245717 kbytes/sec     middle:        102400 kbytes in   0.413515 sec =   247633 kbytes/sec     inside:        102400 kbytes in   0.415535 sec =   246429 kbytes/sec > А если сделать Factory Erase? Но ЗАЧЕМ?
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	160. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 20:42
	> ячеек MLS без деградации продолжительное время. А про "леверный набор" поёшь > только ты. Если бы ты хоть немножко вникал - было бы проще. В левелерном наборе находятся все свободные блоки флеша. Как правило, у SSD есть некоторый overprovisioning - эти блоки используются как для замещения сбойнувших, так и в качестве рабочего набора FTL. Пассивно простаивающих блоков у SSD, как правило, нет - используется всё доступное рабочее пространство. Вообще я с FTL работал еще лет 10 тому назад - и уже тогда на NAND-флеше, используемом в псевдодисках (ныне модное название оных - SSD) по сей день, были все эти механизмы. Сейчас они усовершенствовались, но основная идеология не изменилась - основополагающие принципы работы всё те же, бородатые. На почитать - есть вот здесь: Вот здесь немножко "на пальцах"по принципам работы: http://www.flashmemorysummit.com/English/Collaterals/Proceed... А здесь уже серьёзно вокруг FTL: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.163... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.178... http://research.microsoft.com/pubs/63596/usenix-08-ssd.pdf http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=10... Ну и вот нашлись даже некоторые данные по флешам: http://forums.anandtech.com/showthread.php?t=2158353 > Устал протирать глаза на очевидные вещи. Блин, протираешь-протираешь, и всё никак не протрёшь. Протри глаза уже, >>> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи >>> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях. >> И какова ныне скорость? > Transfer rates: >  outside:       102400 kbytes in   >  0.416739 sec =   245717 kbytes/sec >  middle:        102400 kbytes in >   0.413515 sec =   247633 kbytes/sec >  inside:        102400 kbytes in >   0.415535 sec =   246429 kbytes/sec Это read. Read не интересно, интересно write - как раз таки всё зависит от состояния левелера и рабочего набора. >> А если сделать Factory Erase? > Но ЗАЧЕМ? Сравнить загаженный диск с чистым. Причем чистым не на уровне FS, а на уровне FTL.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	162. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 30-Апр-13, 23:16
	>[оверквотинг удален] >>>> Вот я и спрашиваю, когда ожидать первых весточек о деградации производительности записи >>>> от SSD 64 ГБ. Суточная перезапись идёт примерно по 200 МБ, что, естественно, никак не сказывается на общей скорости или какой-либо латентности в дисковых операциях. >>> И какова ныне скорость? >> Transfer rates: >>  outside:       102400 kbytes in >>  0.416739 sec =   245717 kbytes/sec >>  middle:        102400 kbytes in >>   0.413515 sec =   247633 kbytes/sec >>  inside:        102400 kbytes in >>   0.415535 sec =   246429 kbytes/sec Наш друг от маркетологии лишь тонко намекает что диски с контролером sandforce2 сначала сжимают данные, а потом пишут и что то что пишется может очень сильно отличаться от исходного. Не даром же на всех форумах рекомендуют избегать это г... > Это read. Read не интересно, интересно write - как раз таки всё > зависит от состояния левелера и рабочего набора. Прежде всего это зависит от того насколько сожмутся  записываемые данные.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	163. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 23:51
	> Прежде всего это зависит от того насколько сожмутся  записываемые данные. Подсовывайте в тестировании рандом, делов-то. У меня стоит SSD на SandForce SF-2281 - ей вообще имхо монопенисуально при записи - сжимаемые данные или нет - показатели одни и те же. Во всяком случае серьезной разницы при записи нулей и видео не увидел. А вот при чтении - да, определенная разница имеется.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	164. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 02-Май-13, 00:13
	>> Прежде всего это зависит от того насколько сожмутся  записываемые данные. > Подсовывайте в тестировании рандом, делов-то. У меня стоит SSD на SandForce SF-2281 > - ей вообще имхо монопенисуально при записи - сжимаемые данные или > нет - показатели одни и те же. Во всяком случае серьезной > разницы при записи нулей и видео не увидел. А вот при > чтении - да, определенная разница имеется. О мой всегда говорящий правду и только правду друг, вы можете предоставить видео того что вы только описали ? :)))))))
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	166. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 02-Май-13, 09:32
	> О мой всегда говорящий правду и только правду друг, вы можете предоставить > видео того что вы только описали ? :))))))) Видео вот специально ради тебя писать не буду, но вывод с консоли покажу. SSD стоит на десктопе с виндой. Файлы для теста чтения были созданы следующим образом, и помещены на SSD: C:\>dd if=/dev/zero of=test_zero bs=1M count=4096 C:\>dd if=/dev/random of=test_random bs=1M count=4096 На машине 8Гб памяти, из них более 4Гб занято запущенным софтом, и файлы в кэш полностью не влезут. Далее читаем нули: C:\>dd if=test_zero of=/dev/null bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 11.66 seconds, 368 MB/s C:\>dd if=test_zero of=/dev/null bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 10.765 seconds, 399 MB/s А теперь читаем рандом: C:\>dd if=test_random of=/dev/null bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 19.891 seconds, 216 MB/s C:\>dd if=test_random of=/dev/null bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 20.074 seconds, 214 MB/s Как бэ разница при чтении на лице. А теперь проверим запись. Чтобы запись проверить, пришлось создать рамдиск. К сожалению, рамдиск размером в 4 Гб в память не влез, поэтому создал только рамдиск в 2 Гб. Файлы формировались следующим образом: G:\>dd if=/dev/zero of=test_zero bs=1M count=2048 G:\>dd if=/dev/random of=test_random bs=1M count=2048 Сначала протестировал на нулях: G:\>dd if=test_zero of=C:\test_zero bs=1M 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 16.047 seconds, 134 MB/s G:\>dd if=test_zero of=C:\test_zero bs=1M 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 16.585 seconds, 129 MB/s Потом грохнул нули, сформировал рандом, и протестировал на рандоме: G:\>dd if=test_random of=C:\test_random bs=1M 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 23.036 seconds, 93.2 MB/s G:\>dd if=test_random of=C:\test_random bs=1M 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 23.833 seconds, 90.1 MB/s Итого: разница некая в синтетике, конечно, имеется - но всего в ~35Mb/s, против разницы в 150Mb/s при чтении.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	161. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 30-Апр-13, 22:48
	>> GC срабатывает при заполнении рабочего набора, или близкого к тому состояния. > Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекретно > блоки освобождены, а пространство занято под ФС всё? ФС же не > сообщает ничего, не посылает команду TRIM контроллеру (в моём случае)? А помните рекомендацию оставлять 5-10% дискового пространства SSD неразмеченным ? Наверно не от нехрен делать это придумали.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	168. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 02-Май-13, 09:46
	> А помните рекомендацию оставлять 5-10% дискового пространства SSD неразмеченным ? Наверно > не от нехрен делать это придумали. Естественно не зря. В случае ФС без поддержки TRIM это делать просто необходимо (и предварительно делать Factory Erase), чтобы флеш прожил несколько дольше и работал несколько быстрее. В случае FS с поддержкой TRIM особой необходимости в этом нет - сама FS будет отдавать блоки в рабочий набор по мере удаления данных.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	173. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от edo (ok) on 13-Июн-13, 19:56
	AFAIK TRIM - медленная операция, так что не всё так радужно.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	174. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 13-Июн-13, 20:11
	> AFAIK TRIM - медленная операция, так что не всё так радужно. Ее надо грамотно использовать просто. А если ее не использовать - то ее "медленность" размазывается по обычным операциям, плюс за счет снижения объёма рабочего набора идёт дополнительная деградация по производительности.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	175. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от iZEN (ok) on 13-Июн-13, 23:03
	> AFAIK TRIM - медленная операция, так что не всё так радужно. Ах, вот оно что. А я-то думал, почему это поддержку TRIM со стороны файловых систем преподносят как панацею от всех-всех проблем с SSD. Оказывается, нет никакого преимущества от увеличения скорости записи на SSD даже с использованием оного функционала ФС. Тогда уж точно: способность асинхронной записи ФС нивелирует преимущество использования TRIM.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	176. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 14-Июн-13, 07:14
	Ты просто не понимаешь, как работает флеш с левелером. Даже при том, что тебе уже 100500+ раз объясняли. Отсюда и такие "умозаключения". "Асинхронная запись" не расскажет левелеру флеша, какие блоки можно использовать для внутренних операций в качестве рабочего набора. TRIM для SSD - не просто "фича", а жизненная необходимость.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	80. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 18:11
	# sysctl -a| grep -i trim vfs.zfs.vdev.trim_on_init: 1 vfs.zfs.vdev.trim_max_bytes: 2147483648 vfs.zfs.vdev.trim_max_pending: 64 vfs.zfs.trim_disable: 0 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.max_interval: 1 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 270 kstat.zfs.misc.zio_trim.failed: 0 # uname -por FreeBSD 10.0-CURRENT amd64
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	82. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 18:48
	Прошу прощения - почему не поддерживала до недавнего времени? Совсем забыл, что из Linux-ZFS притащили-таки...
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	83. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 18:50
	> Прошу прощения - почему не поддерживала до недавнего времени? Совсем забыл, что > из Linux-ZFS притащили-таки... проблемы с GEOM
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	84. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 18:52
	> проблемы с GEOM И где тогда оно "оружие будущего", если оно только-только научилось поддерживать девайсы без ротации/фрагментации? Об оптимизации речи нет - речь о минимальной поддержке. А еще г-н выше утверждает, что ZFS (и вообще CoW) несовместимы с TRIM. Это конечно лол (хотя в плане ZFS - может быть и так). Но какое тогда отношение эта FS вообще имеет к флешу?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	85. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 18:55
	Ну там не все так просто и логи нужно хранить на отдельном девайсе, Котлеты отдельно, мухи отдельно.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	86. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 18:57
	>> проблемы с GEOM > И где тогда оно "оружие будущего", если оно только-только научилось поддерживать девайсы > без ротации/фрагментации? Об оптимизации речи нет - речь о минимальной поддержке. > А еще г-н выше утверждает, что ZFS (и вообще CoW) несовместимы с > TRIM. Это конечно лол (хотя в плане ZFS - может быть > и так). Но какое тогда отношение эта FS вообще имеет к > флешу? Не золотая пуля, но, под нагрузкой не прогибаеться так сильно
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	88. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 20:23
	Разве кто-то кроме тебя говорил об отношении ZFS к устройствам на flash? Сказано было в том ключе, что эта ФС эпохи устройств без механики. Ну, например, завтра придумают "суперфлеш" не с тысячами а с триллионами циклов перезаписи да к тому же не нуждающиеся в "сборке мусора"? Мелко мыслишь сегодняшними категориями. И да, подумай на досуге, как концепция CoW сочетается со сборкой мусора, особенно это касается труЪ CoW файловых систем типа JFFS и подобных ей.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	89. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 22:37
	К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	90. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 28-Апр-13, 22:41
	Судя по всем линуксовским файловым системам она не умрет Да и управление ZFS куда приятинее У некоторых ФС на линуксе нету проверки диска :) что уж там про потерью инфы говорить
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	91. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 28-Апр-13, 22:44
	Точнее - не успеет даже ожить... Юзкейсов слишком мало.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	92. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (??) on 29-Апр-13, 07:08
	> К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ. В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	93. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 29-Апр-13, 07:10
	>> К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ. > В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься. точнее, "клинского"
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	94. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 29-Апр-13, 07:33
	> В любом случае, она переживет поколение пепси, ярким представителем которого ты являешься. Ути-пути. Во-первых, телепатия не прокачана, двойка. Во-вторых, FAT уже пережила минимум одно поколение. Вот только ничего хорошего от ее наличия не было и нет. И не будет.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	100. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от deadless (ok) on 29-Апр-13, 14:43
	ну и где твоя супер пупер линуксовая фс которая рвет ZFS в клочья? Я как раз ищу такую. Требования: обеспечение целостности данных на уровне FS, быстрые снапшоты не влияющие на скорость, легкость управления, про разные настройки для каждой FS ладно промолчу.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	102. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от 666некто on 29-Апр-13, 17:39
	снапшоты ради снапшотов?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	110. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 19:38
	> снапшоты ради снапшотов? ради быстрых бэкапов..
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

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

	124. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от nagual (ok) on 29-Апр-13, 22:52
	>>> снапшоты ради снапшотов? >> ради быстрых бэкапов.. > ... вполне достаточно снапшота LVM ... Сразу видно кто не пробовал их делать на больших винтах :))
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	132. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:16
	> Сразу видно кто не пробовал их делать на больших винтах :)) Для "больших винтов" (точнее - объемов данных выше 5-10 Тб) есть несколько иные способы снятия бэкапа, чем тупое копирование. Например - лог операций. Но это опять же о птичках. Тупое копирование хоть со снапшотом, хоть без, длится вечность и напрягает дисковую систему.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	150. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от iZEN (ok) on 30-Апр-13, 17:26
	>> Сразу видно кто не пробовал их делать на больших винтах :)) > Для "больших винтов" (точнее - объемов данных выше 5-10 Тб) есть несколько иные способы снятия бэкапа, чем тупое копирование. Ага — инкрементное бэкапирование. > Например - лог операций. А что это такое? Что нам даст лог операций?
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	157. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 18:39
	> Ага — инкрементное бэкапирование. Заколебешься инкременты сверять. А если изменяющийся файл в пару терабайт объёмом (БД)? >> Например - лог операций. > А что это такое? Что нам даст лог операций? Это журнал событий/изменений. По нему можно восстановить систему от последнего полного бэкапа до любого момента времени в журнале с момента полного бэкапа. Простейший пример - binlog в СУБД.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	171. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok) on 07-Май-13, 03:22
	Напомните как там в linux с поддержкой ntfs ? Писать можно или только читать ?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	172. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 07-Май-13, 07:39
	> Напомните как там в linux с поддержкой ntfs ? Писать можно или > только читать ? Можно и читать и писать. Модуль ntfs-3g.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	125. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 23:01
	>>> снапшоты ради снапшотов? >> ради быстрых бэкапов.. > И чем снапшот конкретно убыстряет бэкап? Для рядового бэкапа вполне достаточно снапшота > LVM, для огромных объёмов уже нужны специальные механизмы в любом случае. lvm snapshot не обеспечивает консистентности содержимого FS. так как представляет из себя слепок блочного устройсва - в тоже время fs snapshot (UFS / ZFS / тестовые варианты для EXT4) гарантирует что с данными и метаданными у тебя все в порядке. Это все не считая того что при количестве снапшотов больше 10 - LVM томозит просто неприлично.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	135. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:23
	> lvm snapshot не обеспечивает консистентности содержимого FS > Это все не считая того что при количестве снапшотов больше 10 - > LVM томозит просто неприлично. Ну, для бэкапа достаточно и одного. Тут вопрос - что важнее - снапшоты, или всё-таки высокая производительность в боевом режиме. Если снапшоты - то BTRFS/ZFS, если всё остальное - то классика.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	117. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 29-Апр-13, 20:08
	Юзкейс? Требования: высокая производительность при приличном заполнении диска, отсутствие гиперфрагментации файлов при перезаписи блоков внутри файлов, минимальный расход памяти на поддержание структур FS, поддержка TRIM на флеше, поддержка экстентов для быстрой работы с файлами большого объёма, поддержка DIRECT_IO, кеширование средствами системного кэша, поддержка барьерной записи. Типовой юзкейс для вышеперечисленного - СУБД. Ну и где ZFS при таких требованиях? А если до кучи впилить в требование нативную поддержку Linux, поскольку весь стабильный и поддерживаемый, что немаловажно, серверный софт в основном под оный... и имеем в сухом остатке не так уж и много вариантов.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	126. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от linux must _RIP_ on 29-Апр-13, 23:04
	> Юзкейс? > Требования: высокая производительность при приличном заполнении диска, отсутствие гиперфрагментации > файлов при перезаписи блоков внутри файлов, минимальный расход памяти на поддержание > структур FS, поддержка TRIM на флеше, поддержка экстентов для быстрой работы > с файлами большого объёма, поддержка DIRECT_IO, кеширование средствами системного кэша, > поддержка барьерной записи. > Типовой юзкейс для вышеперечисленного - СУБД. Ну и где ZFS при таких > требованиях? после чего начинаем думать - а почему это для СУБД советуют использовать raw storage.... Хотя ты прав - ZFS в этих условиях не нужна, а вот zpool - будет очень удобен. потому как ему не нужны вские струтукруры на диске - он просто предоставляет сторадж с поддержкой транзакций. PS. кэширование средствами системного кэша и DIO - это противоположные требования. DIO - подразумевает cache by pass..
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	133. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:19
	> PS. кэширование средствами системного кэша и DIO - это противоположные требования. Это разные требования, однако в боевых случаях нужно как то, как и другое. СУБД может работать как в DIO, так и без оного. Важно то, что кеш в случае его использования должен быть системным. А не на соплях сбоку.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	137. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 30-Апр-13, 07:39
	> Важно то, что кеш в случае его использования должен быть системным. Системный кэш нужен только под метаданные ФС, в случае raw storage не нужен и он. А самой СУБД системный кэш нафег не уперся. У нее свой собственный, гораздо гораздючее под ее собственные особенности. И логичнее будет отдать ту память ей.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	141. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 08:13
	> Системный кэш нужен только под метаданные ФС, в случае raw storage не > нужен и он. А самой СУБД системный кэш нафег не уперся. > У нее свой собственный, гораздо гораздючее под ее собственные особенности. И > логичнее будет отдать ту память ей. Именно. И тем более ей не уперся гвоздями прибитый сбоку ZFS ARC. Который хочет over 100500 RAM, и не отключается... Ну и размер метаданных в ZFS "слегка" побольше.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	146. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 30-Апр-13, 16:21
	>> Системный кэш нужен только под метаданные ФС, в случае raw storage не >> нужен и он. А самой СУБД системный кэш нафег не уперся. >> У нее свой собственный, гораздо гораздючее под ее собственные особенности. И >> логичнее будет отдать ту память ей. > Именно. И тем более ей не уперся гвоздями прибитый сбоку ZFS ARC. > Который хочет over 100500 RAM, и не отключается... Ну и размер > метаданных в ZFS "слегка" побольше. Слушай, ну не трындите уже, о том чего вы не знаете, а? "Не отключается". Вафелы вы неграмотные: set zfs:zfs_arc_max=1073741824 set zfs:zfs_immediate_write_sz=1000000000 set zfs:zvol_immediate_write_sz=1000000000 Чо-чо там не отключается, не ограничивается, итп.???????
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	153. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 18:08
	> Слушай, ну не трындите уже, о том чего вы не знаете, а? > "Не отключается". Вафелы вы неграмотные: > set zfs:zfs_arc_max=1073741824 > set zfs:zfs_immediate_write_sz=1000000000 > set zfs:zvol_immediate_write_sz=1000000000 И где там отключение? zfs_arc_max=0 работать будет?
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	155. "Хостинг-оператор Anchor протестировал Btrfs на..."	+1 +/–
	Сообщение от arisu (ok) on 30-Апр-13, 18:34
	да тут бы у Иксперта сначала кнопку для включения мозгов найти…
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	158. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 30-Апр-13, 19:06
	>> zfs_arc_max=0 работать будет? Пока не закончиться оперативка :)
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	129. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 30-Апр-13, 01:18
	zfs create tank/mysql zfs set atime=off tank/mysql zfs set mountpoint=/var/db/mysql tank/mysql zfs create tank/mysql/ibdata zfs set recordsize=16k tank/mysql/ibdata zfs create tank/mysql/iblogs zfs set recordsize=128k tank/mysql/iblogs zfs set primarycache=metadata data/mysql/ibdata innodb_flush_method = O_DIRECT skip-innodb_doublewrite innodb_data_home_dir=/var/db/mysql/ibdata vfs.zfs.prefetch_disable=1
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	134. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 07:21
	От гиперфрагментации (ибо CoW) это не избавит.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	140. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 30-Апр-13, 07:49
	> От гиперфрагментации (ибо CoW) это не избавит. Так мы таке почитали вики что такое CoW? Ну и как вам CoW + TRIM? Расскажите, интересно же.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	143. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 08:15
	> Так мы таке почитали вики что такое CoW? Ну и как вам CoW + TRIM? Расскажите, интересно же. Почитали? Ну идите еще почитайте. Особенно по логике работы флеша.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	147. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 30-Апр-13, 16:49
	в zfs нету CoW
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	149. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (??) on 30-Апр-13, 17:24
	> в zfs нету CoW в raidz есть
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	154. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 18:09
	> в zfs нету CoW it's epic, bro
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	139. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–3 +/–
	Сообщение от Аноним (??) on 30-Апр-13, 07:47
	> Юзкейс? > Требования: Нагромождение требований к дизайну ФС плюс дикий микс разных к этому дизайну плюшек не относящихся. Ты что, дурак?
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	142. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 30-Апр-13, 08:14
	Так юзкейс для своего варианта уже приведёшь, или пустопорожнее?
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	165. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–3 +/–
	Сообщение от deadless (ok) on 02-Май-13, 00:27
	вот как ограниченность файловых систем в линуксах не дает даже возможности представить где можно использовать сотни снапшотов и какой от этого может быть профит. реальной альтернативы ZFS не представлено, и судя по фанатичности отстаивания позиций православного линукса дальнейшее обсуждение перспектив не имеет. В качесте ликбеза сходите и посмотрите как архитектурно построены правильные ФС типа того жу WAFL и почему разработка 20летней давности до сих пор кроет как бык овцу все современные ФС начиная от костыльных ext(2,3,4) кончая всевозможными CoW. PS: По степени упоротости AlexAT пожалуй превосходит и юзера294 и _Nick_ вместе взятых.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	167. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от AlexAT (ok) on 02-Май-13, 09:33
	Слив засчитан. Пока, господа, для ваших академических поделок не будет _широкого_ юзкейса - они так и останутся узкоспециализированным раритетом, выбирать который будут только в исключительно специфичных случаях. И то - постоянно смотря на более универсальные альтернативы, ибо в эксплуатации проще поддерживать одну сущность, чем несколько.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	169. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (??) on 02-Май-13, 12:32
	http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-more
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	170. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от AlexAT (ok) on 03-Май-13, 20:03
	> http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-more Адовый гибрид Illumos + QEMU + KVM + тонны маркетингового булшита. Спасибо, избавьте.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

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

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