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

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

"Проект CoreOS рассматривает возможность ухода от использован..."	+/–
Сообщение от opennews (ok) on 20-Дек-14, 11:00
Брендон Филипс (Brandon Philips), технический директор компании  CoreOS Inc, развивающей основанное на идеях контейнерной изоляции серверное окружение CoreOS (http://www.opennet.me/opennews/art.shtml?num=40275), выступил (https://groups.google.com/forum/m/#!topic/coreos-dev/NDEOXch...) с предложением ухода от использования по умолчанию файловой системы Btrfs в пользу связки из Ext4 и многослойной файловой системы OverlayFS (http://www.opennet.me/opennews/art.shtml?num=40947). В качестве причины прекращения использования по умолчанию Btrfs упоминается периодическое поступление от пользователей жалоб о работе Btrfs, в том числе об ошибках при исчерпании свободного дискового пространства, требующих ручного вмешательства проблемах с ребалансировкой метаданных и низкой производительности (https://docs.google.com/presentation/d/1npITxQaHSq0QZlZYL7cJ...), по сравнению с другими ФС. Выбор в пользу OverlayFS обусловлен более высокой производительностью, простотой реализации и появлением данной ФС в составе штатного ядра Linux 3.18 (http://www.opennet.me/opennews/art.shtml?num=41210). URL: https://groups.google.com/forum/m/#!topic/coreos-dev/NDEOXch... Новость: http://www.opennet.me/opennews/art.shtml?num=41312
Ответить | Правка | Cообщить модератору

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

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

1. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
Сообщение от A.Stahl (ok) on 20-Дек-14, 11:00
Ура, здравый смысл восторжествовал! Пусть пилят и пилят свою лучшую файловую систему с деревьями, обмазанными маслом:) Файловая система не пасьянс -- тут несколько более высокие требования к стабильности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 20-Дек-14, 22:46
	Они все с деревьями. Которые современные.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	66. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от A.Stahl (ok) on 20-Дек-14, 23:45
	Не сомневаюсь. Ты это к чему? Если ты про мою фразу, то я намекал на название ФС, в котором фигурируют деревья и даже, по некоторым сведениям, масло:)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	78. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:20
	А я думал что это просто чемпионат по тормозизму.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

2. "Проект CoreOS рассматривает возможность ухода от использован..."	+6 +/–
Сообщение от YetAnotherOnanym (ok) on 20-Дек-14, 11:06
Ага, а  OverlayFS прямо вся такая годами обкатанная в боевых условиях. Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%, и не заменят регулярный бэкап.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Проект CoreOS рассматривает возможность ухода от использован..."	+19 +/–
	Сообщение от A.Stahl (ok) on 20-Дек-14, 11:13
	>если юзер допускает заполнение диска на 100% Можно подумать что это не штатная ситуация. Это нормально. И это уж никак не повод рассыпаться.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	111. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 13:28
	> Можно подумать что это не штатная ситуация. Это нормально. И это уж > никак не повод рассыпаться. Так обычно и не рассыпается. Но может потребоваться костыль в виде ребаланса.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	220. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 23-Дек-14, 22:52
	> Так обычно и не рассыпается. Но может потребоваться костыль в виде ребаланса. UPD: В ядре 3.18 костылирование автоматизировано :)
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	9. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от anonymous (??) on 20-Дек-14, 11:47
	годами обкатана пользователями openwrt условия правда больше не боевые, а домашние, зато полет вроде у всех нормальный в отличие от
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	56. "Проект CoreOS рассматривает возможность ухода от использован..."	+7 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 22:47
	> условия правда больше не боевые, а домашние, зато полет вроде у всех > нормальный в отличие от Правда условия тепличные, типа записи мегабайта в год...
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	120. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Куяврег on 21-Дек-14, 15:44
	> зато полет вроде у всех нормальный в отличие от в отличие от?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Проект CoreOS рассматривает возможность ухода от использован..."	+4 +/–
	Сообщение от Александр Патраков on 20-Дек-14, 12:30
	> Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%, и не заменят регулярный бэкап. Чтобы юзер не допускал заполнение диска на 100%, нужно, чтобы системный вызов statfs (используемый командой df и всеми существующими решениями для мониторинга в искоробочной конфигурации) не врал. А вся претензия тут именно в том, что он врет, и вместо его починки предлагается гонять какой-то нестандартный btrfs-специфичный.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	57. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 22:50
	> искоробочной конфигурации) не врал. А вся претензия тут именно в том, что он врет, Он не врет. Просто btrfs может на ходу кроить произвольные уровни RAID и ответ на вопрос "сколько места?" зависит от "в каком RAID будете сохранять?".
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	65. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от iZEN (ok) on 20-Дек-14, 23:42
	> Просто btrfs может на ходу кроить произвольные уровни RAID Это какие? RAID-0 (который RAID'ом называется чисто условно) и RAID-1 разве что.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	79. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:26
	> Это какие? RAID-0 (который RAID'ом называется чисто условно) и RAID-1 разве что. Теоретически - любые, которые набор девайсов позволяет. Есть девайсы и свободное место на них. Если надо зеркало - значит пишем на 2 девайса (свободного места на них станет меньше). Если stripe - аналогично. Практически есть "no raid", RAID0, RAID1, а в экспериментальном виде RAID5/6. Кстати в 3.19 рекавери с райдов 5/6 улучшили и оно приближается к продакшновому состоянию. Если уж на то пошло. А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов? Как ты понимаешь, совсем не факт что все данные имеют одинаковую ценность. Поэтому какая нибудь шара с видео с корпоратива - одно, а рабочие документы - другое. И логично их хранить с разными уровнями райда.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	119. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от G0Dzilla (ok) on 21-Дек-14, 15:24
	>А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов? LVM в AIX давно это умеет. Лет 20, наверное...
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	135. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 17:33
	> LVM в AIX давно это умеет. Лет 20, наверное... Что, оно прямо так уж пофайлово может принимать решения? Дескать, вон тот файл мы как RAID-1 запишем, а этот как RAID-5? Если да - ну я рад за ибмщиков, здорово обогнавших остальных. Но боюсь что мне aix - ни в п...у, ни в красну армию.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	200. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от sdog (ok) on 22-Дек-14, 15:31
	ППС
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	121. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Куяврег on 21-Дек-14, 15:48
	> Кстати в 3.19 рекавери с райдов 5/6 улучшили и оно приближается к > продакшновому состоянию. > рекавери > продакшновому состоянию рекавери приближается к продакшновому состоянию?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	134. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 17:30
	> рекавери приближается к продакшновому состоянию? Для RAID5/6, поддержка которых как известно была заявлена экспериментальной фичой. Собственно оно экспериментальное в том числе и потому что там не было кода который бы делал рекавери порушеных данных по избыточным данным райдов 5/6. В 3.19 судя по коммитам за это дело взялись и этот код появляется. Обычная сборка автомобиля во время гонки, которой так славится опенсорс :).
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	227. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Классический анонимус on 24-Дек-14, 09:35
	"А покажи мне еще ФС где можно разные уровни райдов на одном и том же наборе девайсов" А зачем это всё в одну ФС утрамбовывать? Уже много лет доступен вариант с mdadm и часть HDD добавляешь в RAID0, другую часть в RAID1. То что можно отформатировать в разные ФС - это бонус, а не недостаток.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	232. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 26-Дек-14, 17:44
	> А зачем это всё в одну ФС утрамбовывать? Уже много лет доступен > вариант с mdadm и часть HDD добавляешь в RAID0, другую часть > в RAID1. То что можно отформатировать в разные ФС - это > бонус, а не недостаток. В случае btrfs по задумке райды могут сосуществовать и возможно их перегонять 1 в другой. Постепенно. Это пока в зачаточном состоянии, но на уровне архитектуры - заложено. И возможность гибко прогибать уровни райда под текущие нужды, без огромных перетрясок - это фича. А какая-то там возможность откусить кусок - заявка на головную боль, ибо потом это на ходу переконфигурировать - сплошной гемор. Надо решения на столетия вперед принимать.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	82. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:33
	Он врет. Уровни RAID никак не связаны с числом байт которые в данный момент времени система может не использует.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	87. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 02:14
	> Он врет. Уровни RAID никак не связаны с числом байт которые в > данный момент времени система может не использует. Можно сколько угодно выводить количество байт, которые система не использует - эта характеристика бесполезна при определении возможности заполнения устройства, а значит, в вашей терминологии, является враньем. Дано: два винта по 1000Гб в одном пуле btrfs. На каждом из них занято по 990Гб. Не используется, таким образом, 20Гб. Вы хотите узнать, достаточно ли на них места для записи 15Гб файла. Если вы будете записывать его в режиме stripe, потратится 15Гб. В режиме mirror - 30Гб. Помогли, сынку, тебе твои поляки?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	93. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 04:35
	> Помогли, сынку, тебе твои поляки? Вот этот момент замшелые мамонты никак понять не могут :). А тем временем иметь возможность менять уровни райда и назначать разным данным разные уровни и все это на лету и без многотерабайтных перетрясок - более чем. А так ждем когда эти ретарды заметят у себя в системе оверкоммит и возмутятся тем что программам вывешивается больше адресов чем в системе есть памяти.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	154. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от user (??) on 21-Дек-14, 21:24
	оверкоммит давно выключен, ибо нефиг
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	163. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 01:57
	> оверкоммит давно выключен, ибо нефиг Правильно, давайте неиспользуемые адреса оперативой обеспечим.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	117. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 15:01
	> Можно сколько угодно выводить количество байт, которые система не использует - эта характеристика бесполезна при определении возможности заполнения устройства, а значит, в вашей терминологии, является враньем. Ну-ну. И какое отношение число байт которые можно записать в файловую систему имеет к числу байт которые система не использует на устройстве? Или может вы хотите сказать, что в рамках ОДНОЙ файловой системы Btrfs один файл может записать как RAID0 а второй как RAID10? И я не хочу узнать достаточно ли места для 15Гб файла. Я хочу что бы Btrfs как xfs/ext*/ufs*/ntfs/fat*(!) когда осталось на доступных устройствах осталось 0 байт продолжала нормально работать на чтение. Увы, но самая прогрессивная ФС современности почему то в этом уступает даже fat16.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	164. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 02:04
	> Или может вы хотите сказать, что в рамках ОДНОЙ файловой системы Btrfs > один файл может записать как RAID0 а второй как RAID10? Именно - оно спроектировано так, что технически при создании файла можно заказать ему любой поддерживаемый ФС уровень райда. Далее если на достаточном кол-ве девайсов есть достаточно места, файл будет записан с именно такой схемой размещения. Реально пока есть не все уровни райда, а утиля умеет конфигурирование по субволумам. Что тоже довольно неплохо - каждый сабволум может иметь свой уровень RAID и они все используют один и тот же пул девайсов и спободного места на них, что как бы намекает. > осталось 0 байт продолжала нормально работать на чтение. Так она при этом нормально работает на чтение?
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	159. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от YetAnotherOnanym (ok) on 21-Дек-14, 23:23
	> Вы хотите узнать, достаточно ли на них места для записи 15Гб файла Кто Вам сказал такую глупость? Я хочу, чтобы, когда у меня возникнет потребность записать файл 15ГБ, я мог его просто взять и записать, не задумываясь о том, сколько туда ещё можно записать. Для этого я хочу знать, когда надо начинать освобождать место. И вообще, если задаётся вопрос "сколько свободного места" то надо отвечать именно на этот вопрос, а не подменять его вопросом "сколько ещё можно записать".
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	165. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 02:06
	> И вообще, если задаётся вопрос "сколько свободного места" то надо отвечать именно > на этот вопрос, а не подменять его вопросом "сколько ещё можно записать". Полный ответ на этот вопрос содержит список девайсов и список места на них. Это делается командой btrfs filesystem df или соответствующими вызовами. Видя эту информацию уже можно делать некие выводы по части влезет ли такой-то файл с такой-то запрошенной схемой размещения. Но это далеко от архаичного простого сискола.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	171. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 22-Дек-14, 07:13
	И даже это не верно. Потому что этот ответ не доступен пользовательскому ПО бау_дезигн уже несколько поколений как. К примеру — вот место есть. Но 5% (или 3%, или 10%. От админа зависит, а не от фс, lvm или ещё чего) заресервировано для рута. Или например админ квоты выставил. Пользовательское ПО должно просто грамотно обрабатывать исключение нехватки ресурсов и всё. И делать это до того, как потеряются данные (например вначале попытаться выделить место и только потом писать туда). Именно такая логика при разработке ПО для юзер-спейса в многозадачной (и много-пользовательской) среде. Не понимающие этого — просто недоученные ламеры (вопли которых на форумах, кстати, всё равно ничего не решают)
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	181. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 10:27
	А в более-менее однопользовательской среде что делать? Качаем пол-дня большой файл и посреди закачки натыкаемся на нехватку места - как здесь, черт возьми, "грамотно обрабатывать исклбчения нехватки ресурсов"? На ПК, знаете ли, обычно нет квот и извращенных рейдов. А необходимость пользователю (и его софту) знать, сколько места свободного - есть. Хрен с ними, со сложными ситуациями - там спецы будут разбираться. Простые надо вменяемо обрабатывать. Где древнего сисколла ещё как хватит.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	189. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 22-Дек-14, 11:32
	> А в более-менее однопользовательской среде что делать? И более-менее однозадачной? Ну ставьте дос, раз вам так всё плохо. > Качаем пол-дня большой файл и посреди закачки натыкаемся на нехватку места - как здесь, черт возьми, "грамотно обрабатывать исклбчения нехватки ресурсов"? Выделять место зарание. Уже было сказано. > На ПК, знаете ли, обычно нет квот и извращенных рейдов. А необходимость пользователю (и его софту) знать, сколько места свободного - есть. Удаляешь одно ненужное и закачиваешь поновой другое очередное ненужное. Как все более-менее пользователи и делают. И даже не знают как называется их ФС. И для безпардонных умников, с претензией на профессионализм, такая мелочь всё-равно не перебивает плюсы работы со снэпшотами (которые не в пример гибче, чем у zfs), работы с субволумами, возможности компрессии на лету и тд, и тп.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	196. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 14:20
	Почему однозадачной? В однопользовательской среде пользователь отлично знает, что и насколько может забить диск. Потому что, по факту, кроме его деятельности и каких-нибудь торрентов больше это делать и нечему. И в таком сетапе нет вообще никакого резона не отдавать нормлаьно свободное место. Сейчас число совсем от балды - а так она будет осмысленной для частного, но распространённого случая. И правильно - прибиваешь одно и качаешь или создаёшь другое. Но для этого нехудо бы знать, сколько именно надо прибить, например. Или сколько видео с камеры влезет. В общем, как по мне - ты старательно пытаешься спорить с тем, что вода мокрая, приводя в пример Чукотку. А что до фич - угу, снапшоты. Обычно только они (плюс COW иногда) и нужны во всей этой чехарде. Остальное - для сильно специальных применений. как та же компрессия, подходящая для полутора случаев - большинство объёмных данных, как правило, ни хрена не жмётся, так как уже сжаты.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	221. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 23-Дек-14, 23:19
	> От админа зависит, а не от фс, lvm или ещё чего) > заресервировано для рута. Или например админ квоты выставил. Насколько я помню, это работает только на EXT2/3/4. И управляется специфичным для них образом через tune2fs. Который специфичен для ext-ов. Остальные ФС не умеют такой резерв. Если я прогнал - ок, покажи как это сделать на, допустим, XFS. У меня с ним том под рукой есть - я это дело проверю :). > Пользовательское ПО должно просто грамотно обрабатывать исключение нехватки ресурсов и всё. Несомненно. В случае btrfs фокус в том что даже удаление файла требует ... сделать CoW выносок для хотя-бы метаданных. А если места нет - ээээ... как бы это сказать... стереть файл - фигвам! :). Потому что для этого надо записать измененный вариант диры. А поскольку CoW и неразрушающая запись - пропатчить старый вариант диры, как в классике - не вариант. Да, инженеры иногда могут не подумать о некоторых вещах на краевых условиях и иногда это может смотреться довольно забавно. Против такого обычно помогает ребаланс, т.к. chunk'и могут быть заполнены не 100% идеально и получится отыграть какие-то крохи достаточные для удаления. Начиная с 3.18 нечто подобное в такой ситуации делается автоматически. > Именно такая логика при разработке ПО для юзер-спейса в многозадачной (и много-пользовательской) среде. В случае btrfs одного простого сискола недостаточно для понимания поместится ли файл на том что есть. Из-за его умений работать с RAIDами и потенциальной способности столкнуться с произвольной смесью уровней избыточности и на самом фундаментальном уровне - нужде наперед знать в какой схеме будут данные хранить. Даже сейчас это известно не на 100% а план таков что не будет известно совсем - такая структура нормально относится к произвольной смеси. Уже сейчас данные и метаданные могут храниться с разными уровнями избыточности, etc.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	95. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 04:47
	> Уровни RAID никак не связаны с числом байт которые в > данный момент времени система может не использует. Вот только если я записываю 100500 байтов как RAID0 - это один случай. А как RAID1 - другой. А ответ на вопрос "получится ли записать 100500 байтов с такой-то схемой хранения?" зависит от конкретики в плане девайсов и свободного места на них. И это не ограничивается 1 примитивным сисколом.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	118. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 15:07
	>> Уровни RAID никак не связаны с числом байт которые в >> данный момент времени система может не использует. > Вот только если я записываю 100500 байтов как RAID0 - это один > случай. А как RAID1 - другой. Я может чего не знаю, но одна ФС - одна схема RAID. > А ответ на вопрос "получится ли записать 100500 байтов с такой-то схемой > хранения?" зависит от конкретики в плане девайсов и свободного места на > них. И это не ограничивается 1 примитивным сисколом. Как верно подмечено зависит от схемы хранения. Определяемой ФС. И таки да, ограничивается 1 примитивным вызовом. Это похоже на разговор слепого с глухим. Да, за счет сжатия и дедупликации файл может физически занять меньше места. Но ФС должна быть способна понять способна она записать файл размера X или не способна. И ведь количество копий блоков данных зависит не от имени или атрибутов файла, а от разметки самой ФС.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	122. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Куяврег on 21-Дек-14, 15:52
	> Я может чего не знаю, но одна ФС - одна схема RAID. Тут профессионалы продакшенов. У них на каждом из стапятисот серверов свой уникальный ни с чем несравнимый компот. И им нормально не знать что, где, чего и сколько.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	140. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 18:13
	>> Я может чего не знаю, но одна ФС - одна схема RAID. > Тут профессионалы продакшенов. Куяврикам не понять что смесь RAIDов на одной файлухе это гибко и рационально в плане использования площади накопителей. А вот нормальные архитекты и те кто им ставит задачи - догадываются.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	169. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 05:38
	При всей крутости такой системы (респект разработчикам, серьёзно) подозреваю, что для 99.99% юзкейсов лучше сгодилась бы пачка отдельно примонтированных томов с разными рейдами. Да, менять размер томов, если что, пришлось бы руками - но на то и LVM, и при разумном планировании вряд ли это составило бы хоть какую-то проблему. Зато софту в таком варианте легко принимать решения - что куда влезет. А вариант "решаем по ходу", как видим, слишком усложняет жизнь. Эх, взять бы эту btrfs, выкинуть всё кроме COW со снапшотами - глядишь, давно была бы полностью готова, протестирована и предсказуема во всех мыслимых ситуациях, уже б, пожалуй, ext4 подвинула. А так... Комбайны - зло.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	170. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от ананим on 22-Дек-14, 06:55
	Софт никогда не принимал решения что и куда влезет. Вот вообще. Как 386 появились, так это точно. Максимум — оценить пытаться или нет. К примеру, по-умолчанию 5% в extX зарезервированы для рута, потом существуют квоты,... в общем куча механизмов. Полагаться только на df — идиотизм и не профессионализм (в системе куча процессов и ваше ПО конкурирует с ними за ресурсы, включая дисковую память. Вот сейчас она есть, а вот её уже и нет. Кто-то порнушку например поставил на закачку как раз между тем как вы вызвали df и начали что-то записывать на диск) Серьёзное ПО либо сразу выделяет место (субд например. да даже торренты. Опять же — либо само либо посредством админа/дба/..), либо корректно обрабатывает исключение нехватки места (ну либо и то, и другое сразу). И это всё. При этом поиметь механизм избыточности на голом месте более чем интересная фишка. Тем более, что (как вы там сказали?) при разумном планировании вероятность нехватки места в нужный момент стремится к нулю (вы либо расчитали это до такого момента, либо подготовились. купили таки винты/ссд/.. ну или хотя бы прикрыли попу в виде заявки руководству). Но это при разумном. При не очень разумном получить ситуацию, когда вот на этом вот волуме lvm места уже нет (а нужно именно на этом), а вот на этом его ещё дофига — раз плюнуть. Оцените вероятность такой ситуации в этом случае и в случае с бтр, когда всё доступное место в системе собственно... доступно.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	182. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 10:36
	Всё запланировать можно заранее - в "промышленных" ситуациях. На ПК - некому планировать, но там нет обычно ни квот, ни рейда. Там ситуация простая как пятак - пользователь знает, кто может забить его хомяк - он сам. И он должен знать, что ему поместится, а что - нет. И если он, скажем, распаковывает архив (про тот же .gz софт до распаковки не знает, сколько он займёт, а вот пользователь обычно неплохо это представляет) - он должен иметь возможность оценить, получится распаковать или нет. А в продакшне - насколько я знаю, предсказуемость всегда ценнее, чем колдовство на предмет выгадать место. Лучше я точно буду знать, что мне место для базы через месяц закончится, чем с шансами оно внезапно закончится завтра, хотя должно было протянуть ещё два.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	190. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от ананим on 22-Дек-14, 11:42
	> Всё запланировать можно заранее - в "промышленных" ситуациях. На ПК - некому планировать Да-да, как же тяжело быть обычным юзером. Ай-ай. Ай-ай-ай. Пляча, стирает старую порнушку и заливает новую. Зыж Только для совсем уж тyпoго тролля эта тема может быть ещё интересна.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	197. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 14:23
	Обычным юзером быть хорошо. Особенно когда понимаешь, какой минимум средств тебе нужен и не пытаешься в булочную летать на космическом корабле. И, что характерно, таких случаев - абсолютное большинство. Не серверов с крутыми СХД, а десктопов/планшетов/смартов, плюс облака вроде гугловского, rackspace и прочего, где все понимают преимущества простоты.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	223. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 23-Дек-14, 23:58
	> Всё запланировать можно заранее - в "промышленных" ситуациях. Во первых даже там это проблема. Через сколько-то лет эксплуатации резко носиться колбасой, подбирая правильные винты для стоража в правильном количестве - удовольствие здорово ниже среднего. Это сильно нагибает свободу маневра и вообще, требует или тратить деньги и становиться складом запчастей или сталкиваться с нуждой резко подрываться и экстренно что-то предпринимать в не самой удобной позе. > На ПК - некому планировать, но там нет обычно ни квот, ни рейда. Во вторых я не вижу почему бы мне не получить просто прибавку места в ФС на моем десктопнике при втыкании к 3 винчам 4-го, без фундаментального перетряса всего содержимого 3 винчей с  переносом ... на еще штуки три отдельных винча на это время? :) В третьих я не понимаю почему мощный домашний десктоп должен быть принципиально недостоин райда. > А в продакшне - насколько я знаю, предсказуемость всегда ценнее, чем колдовство > на предмет выгадать место. Если посмотреть на тенденции по оверселлу и оверкоммиту, можно заметить что бизнес выбирает выгоду и в курсе теории массового обслуживания :). Хинт: никто не строит например сотовую сеть с замахом на одновременное обслуживание ВСЕХ абоннтов. Критичен ли завал сотовой сети? В общем случае еще как. Но как-то так получается что с клином сетей в 00:00 01.01 все как-то смирились и считают неидеальную работу сети в этот период времени, скажем так, приемлимым. Просто потому что идеальная работа сети и в такой период тоже - потребует вбухать в инфраструктуру в несколько раз больше, а потом оно будет в основном простаивать почти весь год. А т.к. бабло побеждает зло... > место для базы через месяц закончится, чем с шансами оно внезапно > закончится завтра, хотя должно было протянуть ещё два. Энтерпрайзный админ хранилища должен знать как его файлуха работает и быть в состоянии понять когда пора расширяться. При том задолго до того как жареный петух клюнет. И грубо оценить что влезет на бтрфс - админ по любому обязан, по статистике девайсов и пониманию работы уровня райда.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	222. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 23-Дек-14, 23:46
	> юзкейсов лучше сгодилась бы пачка отдельно примонтированных томов с разными рейдами. Это не гибко. Любое изменение конфигурации == боль пониже спины. С факом мозга подбором винтов и их размеров, адскими временами рестрайпа, при том чаще всего оффлайнового и нуждой куда-то на это время деть кучу данных и прочее. Идея btrfs: доткнуть диск и, может быть, сделать ребаланс чтобы он принял на себя более-менее пропорциональную часть нагрузки/восстановил слетевшее парити (если надо, актуально для degraded RAID), etc. Это просто, круто и логично. И рациональнее в плане расхода места в mixed конфигурациях собранных "по месту", из накопителей разного объема. Эта конструкция не подразумевает что например RAID1 - группа дисков одинакового объема. Можно скажем воткнуть 1 большой винч и 2 половинной емкости и получить емкость 1 большого винча - парные блоки будут жить на парах накопителей. И критерий возможность выполнить запись в формате RAID1 - есть достаточное место на 2 дисках. Не обязательно одинаковых. Так можно сделать довольно необычные конфиги, типа RAID1 из 3 дисков - с емкостью 1.5 диска (при одинаковых дисках). Т.е. в целом это все сделано с пониманием со стороны архитекта одной из проблем эксплуатационщиков: довольно сложно и неудобно обеспечивать ФС идентичные девайсы и круто перетрясать все при желании например изменить схему райда. Btrfs сделан так что позволит в общем случае произвольно доткнуть 1 или N дисков в пул. Любых. Которые у вас под рукой есть. И это даст еще эн места. Собственно диск можно и изъять, главное чтобы не стало меньше минимального числа дисков нужных для затребованной схемы и на оставшихся дисках хватало бы места. Ну то-есть из "RAID1 @ 3 диска" можно взять да и вынуть 1 диск. Если на оставшихся 2 места хватит. При этом btrfs уберет блоки с вынимаемого диска. А ребаланс удостоверится что у каждого блока есть пара на другом девайсе. При том в это время все будет работать, данные будут доступны, их не надо будет никуда удвигать на время перекраивания схема райда и прочее. И я почему-то так считаю что в идеале управление сколь-нибудь заметным сторажем с несколькими дисками должно выглядеть именно как-то вот так. > на то и LVM, и при разумном планировании вряд ли это > составило бы хоть какую-то проблему. Распланировать все на века - затея довольно сложная. А в btrfs фича в том что никого не заствляют это делать - можно малой кровью все переиграть. Без того гемора который характерен для райдов работающих целиком на блочном уровне. > принимать решения - что куда влезет. А вариант "решаем по ходу", > как видим, слишком усложняет жизнь. Любой дизайн подразумевает некий tradeoff. В классических сисколах о такой крутизне не задумывались и поэтому такое в системных вызовах просто не предусмотрено. Да и классическая семантика POSIX - явно не предел мечтаний для интерфейса к дизайнам на основе CoW. Возможно иногда наступает пора признать что нужно что-то доработать и расширить. В том числе и системные вызовы. Или посчитать что админ должен посмотреть статистику по девайсам и врубить мозг, если он хочет впихнуть еще 1 терабайтный файл на стораж. > Эх, взять бы эту btrfs, выкинуть всё кроме COW со снапшотами - > глядишь, давно была бы полностью готова, протестирована и предсказуема ...только там не было бы фич ради которых с ней все носятся. Снапшоты - это хорошо. А возможность просто и гибко строить стораж, который потом можно плавно прогибать под фактические реалии - лучше. Энтерпрайзятники, думаю, догадываются и тоже хотят плюшку. > во всех мыслимых ситуациях, уже б, пожалуй, ext4 подвинула. А так... Комбайны - зло. И да и нет. Это дает ряд грабель. Но дает и ряд уникальных достоинств которые по иному просто и не получишь. Те же классические блочные райды - идут по пути наименьшего сопротивления и сделали ряд допущений. Удобных разработчикам, но геморных при эксплуатации. А тут - ровно наоборот. Не вижу почему так должно быть нельзя. С точки зрения эксплуатации я предпочту простой и гибкий стораж. Если разработчикам придется попахать - ОК. В моем понимании их цели того стоят.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	139. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 18:11
	> Я может чего не знаю, но одна ФС - одна схема RAID. Wrong. В случае btrfs файловая система на уровне своего устройства технически может принимать решение о том как раскладывать файл вообще индивидуально для каждого файла. Все определяется лишь доступными девайсами и местом на них. Реально пока сделана немного упрощенная настройка: уровень RAID выбирается для каждого subvolume отдельно. Что несколько более топорно и менее гранулярно, но тоже позволяет постепенные и плавные restripe путем нехитрых манипуляций с иерархиями. Но технически устройство ФС позволяет и пофайлово указывать желаемую схему размещения. > Как верно подмечено зависит от схемы хранения. Определяемой ФС. И таки да, > ограничивается 1 примитивным вызовом. В btrfs может быть произвольная смесь уровней на доступной площади накопителей. Такая вот интересная фигня. Мэйсон не стал утыкаться в архаичные схемы и сделал более гибко. Молодец чувак - мыслит масштабно. > дедупликации файл может физически занять меньше места. Но ФС должна быть > способна понять способна она записать файл размера X или не способна. Заранее неизвестно какую схему размещения вы запросите для очередного файла и как это будет согласоваться с реалиями доступными на девайсах. > И ведь количество копий блоков данных зависит не от имени или > атрибутов файла, а от разметки самой ФС. У btrfs нет никаких жестких принятий решений при создании файловой системы. Одна из причин по которым я считаю ее шагом вперед. Хоть это и дает некие странности с пониманием сколько места свободно, зато так площадь накопителей можно использовать более рационально. Например если у вас есть 2 диска, например, на терабайт и 2 терабайта - в обычном случае вы можете из них сделать например зеркало на терабайт. А в btrfs при этом терабайт двухтерабайтника будет доступен. Просто зеркально получится разложить не более терабайта. Но еще терабайт вполне можно положить "без RAID" (с хранением на 1 устройстве - 2-терабайтном диске). Профит очевиден - обычный RAID проcpaл бы "лишний" терабайт втупую. А тут можно терабайт некритичных данных без резервирования и терабайт более критичных с резервированием организовать. Но на самом деле с точки зрения btrfs есть 2 девайса. На терабайт и на 2. Как хотите так и пользуйтесь ими в пределах поддерживаемых схем RAID и доступного места на девайсах. И это довольно круто придумано :P. Можно забыть о тряске по поводу размера девайсов, уровни можно переиграть на лету и плавно, в том числе и например файловыми операциями. IMHO это весьма серьезный шаг вперед. Хоть и дающий такие странности в подарок. И нет, одного доисторического сискола не хватит для ответа на вопрос разложится ли вон тот файл по вон той схеме RAID на имеющейся конфигурации девайсов. Для ответа на этот вопрос надо как минимум знать свободное место о каждому девайсу и запрашиваемую схему RAID.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	142. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 21-Дек-14, 18:22
	>[оверквотинг удален] > девайса. На терабайт и на 2. Как хотите так и пользуйтесь > ими в пределах поддерживаемых схем RAID и доступного места на девайсах. > И это довольно круто придумано :P. Можно забыть о тряске по > поводу размера девайсов, уровни можно переиграть на лету и плавно, в > том числе и например файловыми операциями. IMHO это весьма серьезный шаг > вперед. Хоть и дающий такие странности в подарок. И нет, одного > доисторического сискола не хватит для ответа на вопрос разложится ли вон > тот файл по вон той схеме RAID на имеющейся конфигурации девайсов. > Для ответа на этот вопрос надо как минимум знать свободное место > о каждому девайсу и запрашиваемую схему RAID. Ты сам-то такой схемой пользуешься или это просто теоретические измышлизмы?
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	166. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 02:08
	> Ты сам-то такой схемой пользуешься или это просто теоретические измышлизмы? Да. Вот прямо это сообщение написано с компа с btrfs. И я не рассказываю про преимущества нтфс - потому что я давно забыл этот древний шит как страшный сон. Я никогда не вернусь на винды и нтфс. И наличие бтрфс - одна из причин, если что. Эта штука будет рулить моими накопителями в виде который я считаю разумным, хорошим и правильным. Хоть и не совсем классически.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	192. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от iZEN (ok) on 22-Дек-14, 13:41
	Я тебя про используемую схему спрашиваю, в частности, а не про Btrfs. Так у тебя эта схема работает или ты излагаешь только лишь что теоретически возможно?
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	150. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 20:24
	> Wrong. В случае btrfs файловая система на уровне своего устройства технически может принимать решение о том как раскладывать файл вообще индивидуально для каждого файла. Теоретик? Покажите команды для настройки такой схемы "индивидуально для каждого файла". > Реально пока сделана немного упрощенная настройка: уровень RAID выбирается для каждого subvolume отдельно. Can btrfs handle different RAID levels for different subvolumes? linux-btrfs@kernel.org : No, not yet. It's planned at some point (probably in the fairly distant future), but hasn't arrived yet. Для теоретиков: нет, различные уровни RAID для разных subvolume не поддерживаются и возможно будут введены в очень далёком будущем. RAID выбирается на всю файловую систему целиком. Ну или покажите нам тайные параметры "btrfs subvolume create" > В btrfs может быть произвольная смесь уровней на доступной площади накопителей. Такая вот интересная фигня. Мэйсон не стал утыкаться в архаичные схемы и сделал более гибко. LVM + любая ФС. ZFS. То о чем вы говорите не является каким-то нововведением. > Заранее неизвестно какую схему размещения вы запросите для очередного файла и как это будет согласоваться с реалиями доступными на девайсах. Мы же уже определились - одна ФС, одна схема. Она стала известна после создания ФС или изменения с последующей ребалансировкой. Так что известно какую и как это согласовывается с реалиями на девайсах. > У btrfs нет никаких жестких принятий .... и прочее Вы не поверите но все это можно сделать с помощью LVM + ext*/xfs/jfs/raiserjs, zfs, geom, да черт возьми даже в Windows 2000 с помощью динамических дисков и точек повторной обработки! > И нет, одного доисторического сискола не хватит для ответа на вопрос разложится ли вон тот файл по вон той схеме RAID на имеющейся конфигурации девайсов. Для ответа на этот вопрос надо как минимум знать свободное место о каждому девайсу и запрашиваемую схему RAID. И вот неожиданность именно Btrfs всё это знает. И свободное место и запрашиваемую схему. Как вы не можете понять, что не важно сколько дисков и уровней RAID, сколько subvolums и снепшотов и df и btrfs fi df выводят информацию по ФАЙЛОВЫМ СИСТЕМАМ а не отдельным файлам. Только df выводит сколько место используется и сколько свободно для ФС. А btrfs fi df выводит такую хрень, как сколько места заюзано по Data, System, Metadata и не в состоянии сказать, а сколько примерно ещё свободного места есть в системе. Конечно, сколько ФС заюзала под свои метаданные мне знать нужней объема свободного места. Но знаете в чем парадокс? ZFS в отличии от btrfs имеет не только работающий RAID (5/6 в btrfs так и не допилили) но и умеет указанное число раз дублировать данные в том, что вы именуете "subvolums" (вы неверно приписали это свойство btrfs). И почему то ей доисторического сискола хватает. И она в состоянии вывести объем свободного места, причем правильно. И судя по вашим утверждениям о RAID на файл вы не особо хорошо знакомы не с внутренним устройством btrfs, ни с её практическим применением.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	180. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 10:17
	> Теоретик? Покажите команды для настройки такой схемы "индивидуально для каждого файла". Их нет. Пока. Но архитектурно так можно. Если посмотреть на то как btrfs вообще сделан и как он выделяет пространство. Отсюда вытекает ряд, казалось бы, странностей. > Для теоретиков: нет, различные уровни RAID для разных subvolume не поддерживаются и > возможно будут введены в очень далёком будущем. Архитектурно - поддерживаются. Реально для этого надо изменения в утилитах настроек и аллокаторе чтобы как-то метить что и в какой схеме раскладывать. Но это заложено в устройстве ФС. А если этого не сделать - так не будет нельзя вообще совсем никогда. Это выглядит как-то так: в ФС есть некие наборы chunks. Chunks могут быть с разными вариантами избыточности. Даже сейчас, btrfs оперирует несколькими наборами chunks с разными настройками - системные данные, метаданные и данные это группы chunk-ов с отдельными настройками избыточности. Место на дисках выделяется как правило в юнитах равных chunk-у. На уровне архитектуры ФС нормально относится к тому факту что на дисках будет лежать произвольная смесь chunks с той или иной степенью избыточности. Такая ситуация возможна уже сейчас - при конвертации уровней RAID на ходу будет происходить именно это. При этом данные остаются доступны, etc. > RAID выбирается на всю файловую систему целиком. Ну или покажите нам тайные > параметры "btrfs subvolume create" Могу показать balance, который на ходу делает restripe chunk-ов по фильтру, что демонстрирует замашки авторов. И кстати subvolume как таковой - вообще лишь очередная иерархия и не имеет ничего общего с блочным разделом. А так - да, у них пока не все что позволяет их архитектура реализовано в утилитах настройки и отдельных закоулках логики ФС. Но даже сейчас - см. например как btrfs относится к ситуации когда есть 3 диска одинакового размера и запросили RAID1. Как это с точки зрения ФС? Раз просят RAID1 значит запись должна попасть на 2 разных девайса. В результате заняты будут все 3 девайса, а емкость будет 1.5 емкости девайса. Не очень похоже на то что мог бы сделать с 3-я дисками обычный RAID1, правда? > LVM + любая ФС. ZFS. То о чем вы говорите не является > каким-то нововведением. Btrfs удачнее реализует это архитектурно - см. выше, в конечном итоге архитектура позволяет раскидать на площади накопителей произвольную смесь райдов. Не говоря о рестрайпе в иной уровень без ухода в оффлайн, более полном использовании площадей дисков разного размера, рекавери только блоков которые реально выделены подо что-то, а не по всей площади и возможность проверить какая копия с райд правильная по чексуммам из ФС, при необходимости опробовав несколько вариантов чтения, etc. LVM, ZFS - они сделаны с допущением что схема райда выбирается 1 раз и на века и не может быть разной. Мэйсон низко не летает и решил сделать интереснее. Технически оно вполне может оперировать разными уровнями райда для разных объектов. Пока это не используется в полную силу. Но дизайн позволяет. > Мы же уже определились - одна ФС, одна схема. Это не так. Даже прямо сейчас возможны (и практикуются) нарушения этого допущения. Например в однодисковой конфиге данные по дефолт убудут лежать как "no raid" а метаданные и системные области - "DUP" (зеркалирование путем размещения в 2 разных местах накопителя). Уже 2 разные схемы размещения. А при создании райдов и ребалансе можно это переиграть. Это пока очень базово, но это не отменяет того что дизайн может намного больше. И вот такие странности - следствие гибкого дизайна с большим запасом на перспективу. > Она стала известна после создания ФС или изменения с последующей ребалансировкой. Это частный субсет возможностей дизайна который реализован прямо сейчас. И даже сейчас оно вполне себе оперирует разными схемами хранения блоков. Данные, метаданные и системные блоки могут лежать в разных схемах хранения уже сейчас. > Так что известно какую и как это согласовывается с реалиями на девайсах. Это не так. Даже сейчас. > Вы не поверите но все это можно сделать с помощью LVM + > ext*/xfs/jfs/raiserjs, zfs, geom, да черт возьми даже в Windows 2000 Можно. Только btrfs сможет все это регулировать пообъектно и не через ж...у. С перспективами гранулярного администрирования и неспешной перебазировки онлайн, с произвольной смесью уровней которая допускается комбинацией девайсов и свободным местом на них. Именно поэтому есть некоторые непонятки с свободным местом - в общем случае заранее неизвестно в какой схеме будут выделены следующие блоки. Поэтому нельзя сказать сколько и чего влезет. > с помощью динамических дисков и точек повторной обработки! А еще можно изловчиться правой пяткой почесать левое ухо. А попробуйте хотя-бы копирование с референсом (cp --reflink ...) изобразить по людски? На btrfs так можно сделать пять копий допустим виртуалки, изначально будут занимать места как 1 копия, а дальше - в зависимости от отличий. Этакий дедуп сразу на старте. А покажите такое на нтфс? > И вот неожиданность именно Btrfs всё это знает. И свободное место и > запрашиваемую схему. Это не так. Свободное место - знает. Схему - нет. Даже сейчас используется несколько схем которые не обязаны совпадать. > RAID, сколько subvolums и снепшотов и df и btrfs fi df > выводят информацию по ФАЙЛОВЫМ СИСТЕМАМ а не отдельным файлам. btrfs fi df выводит видение btrfs'ом групп chunk-ов для которых уже что-то где-то когда-то было выделено. А просто df - выводит <нечто>. Просто потому что должен что-то выводить. Я не понимаю какой физический смысл может нести единая цифирь при такой архитектуре. Легаси подходы просто не заточены на ТАКОЙ подход. Еще есть btrfs filesystem show. Он как я понимаю показывает как раз состояние дел по девайсам. Как вы понимаете, на девайсе может и не быть chunks по всей площади, что однако не означает что нельзя создать новый chunk и заюзать его. > Только df выводит сколько место используется и сколько свободно для ФС. Для btrfs он выводит некую сферическую фигню в вакууме, просто потому что там надо что-то вернуть. Физический смысл этой цифири при таком дизайне мне не очевиден. А еще там между прочим есть сжатие, при том заранее неизвестно на сколько сожмется. И референс блоков (некоторые называют это дедупликацией), которые делают понятие свободного места еще более интересной величиной. Например я могу сделать кучу копий файла через reflink. При этом изначально занимаемое место близко к размеру 1 файла, независимо от числа копий (плюс-минус метаданные). А дальше зависит от фактических отличий (некоторые называют это коэффициентом дедупликации). И даже в обычных ФС есть например sparse файлы, где логическое пространство и физически занимаемое место - 2 большие разницы. По поводу чего рассказы о свободном месте и "влезет ли вон тот файл" на самом деле далеки от тривиальных. Особенно для btrfs. > А btrfs fi df выводит такую хрень, как сколько места заюзано по > Data, System, Metadata и не в состоянии сказать, а сколько примерно > ещё свободного места есть в системе. Он выводит состояние по уже занятым областям накопителей которые btrfs "приватизировал" в chunk-и и расписывает какие группы chunk-ов с какой избыточностью вообще в ФС есть. Это полезно для тех кто понимает как работает btrfs-овская аллокация пространства (ну и смесь уровней избыточности). А вы видимо хотите нечто типа btrfs filesystem show... > Конечно, сколько ФС заюзала под свои метаданные мне знать нужней > объема свободного места. Это тоже достаточно актуальные величины для конкретно этого аллокатора. Они позволяют понимать внутреннее состояние аллокатора, чем он по факту оперирует и какое там состояние дел. > именуете "subvolums" (вы неверно приписали это свойство btrfs). Технически, subvolume - всего лишь "еще одна иерархия". С рядом индивидуальных настроек. Оно не имеет ничего общего с блочными разделами и прочим. > И почему то ей доисторического сискола хватает. И она в состоянии вывести > объем свободного места, причем правильно. Потому что там обычый архаичный подход к райдам, не имеющий ничего общего с btrfs. В btrfs все это архитектурно сделано намного интереснее. Откуда и странности с свободным местом. Потому что оно подразумевает произвольную смесь уровеней избыточности. > И судя по вашим утверждениям о RAID на файл вы не особо хорошо знакомы > не с внутренним устройством btrfs, ни с её практическим применением. Скорее слишком много смотрел на ее архитектуру и поэтому грань между тем что оно может архитектурно и тем что уже сделано начала размываться.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	183. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 10:44
	Всё красиво, а теперь надо, чтобы df выводил одну крайне простую штуку - свободное место в предположении, что никаких красот нет и всё быдет забито одним большим файлом. Если так сделать - это снимет 99% практических проблем. Потому что те, кто будет поьлзоваться вашими волшебными фичами - разберутся, как им там орудовать. А то подавляющее большинство, что не будет - получит понятное предсказуемое поведение. Опять же - задокументировать просто. Что касается меня - то я восемь раз подумаю, прежде чем закладываться на такую навороченную штуку. Когда рейд отдельно - он нормально ложится в голову, обкатан миллион раз на практике и не тащит гору нетривиального кода. А так - теперь понятно, почему ЭТО столько пишут. Надеюсь, до кого-ниббудь всё же дойдёт сделать btrlite - чтобы никаких рейдов в принципе не умела, а вела бы себя просто как приличная ФС - даже если архитектурно может больше, чтобы в коде этого не было - а значит, он был более простым, надёжным и предсказуемым.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	191. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от ананим on 22-Дек-14, 11:50
	> Всё красиво, а теперь надо... Кому надо, тот пусть и делает > Если так сделать - это снимет 99% практических проблем. Если количество крэзи увеличится на 99%, то мужет ну его нафик так делать. > А то подавляющее большинство Не, точно лучше не надо это делать. Кому "жмёт", пусть лучше чем-то другим пользуется и плачет в других форумах. Вон айзену пусть моск канифолит например по всяким пустякам.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	224. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 24-Дек-14, 00:12
	> - свободное место в предположении, что никаких красот нет и всё > быдет забито одним большим файлом. Так он нечто наподобие и выводит вроде. Только это сферическая цифирь в вакууме. > А то подавляющее большинство, что не будет ...может им проще ext4 поставить будет? Нет фич - нет проблем с ними! :) > - получит понятное предсказуемое поведение. Понятное? Предсказуемое? А что насчет сжатия? Заранее неизвестно насколько сожмется, поэтому то что показали и то что влезло по факту - разные вещи. Или sparse файлов? То что там написано что файл 100500 гигз - не значит что он реально занимает на физике столько. Сумма размеров файлов может люто превышать емкость стоража. А как насчет множественных референсов и CoW относительно этого? В примитивном виде нечто подобное даже в обычной ФС линками делается, при том половина софта которое явно не aware про это - норовит линки разобрать до полноценных копий файлов, со всеми вытекающими по части занимаемого ими места. > Что касается меня - то я восемь раз подумаю, прежде чем закладываться > на такую навороченную штуку. Я предпочитаю здравый смысл. И он говорит мне что штука обещает быть вкусной. Но для сильно ответственных применений я бы пока юзать не стал. Но в перспективе бы с точки зрения администрирования хотелось бы именно что-то такое. Потому что я не считаю хардкорный гемор присущий администрированию райдов чем-то нормальным и правильным. > Когда рейд отдельно - он нормально ложится в голову, В мою голову идея Мэйсона легла весьма нормально. И вообще, такой подход к райдам мне как-то импонирует намного больше. Глюки починят, а вот алгоритмы где сложности перепихнуты с разработчика на админа - так и останутся сложностями админов. > нетривиального кода. А так - теперь понятно, почему ЭТО столько пишут. Да, Мэйсон решил сделать настоящий next gen. Я склонен считать что по многим пунктам это у него получилось. Не везде идеально. Не везде без проблем. Но это новый набор tradeoff-ов и лично мне он вполне симпатичен. > Надеюсь, до кого-ниббудь всё же дойдёт сделать btrlite Пусть кому надо те и делают. ИМХО делать новый дизайн как-то так и потом кивать на архаичные классические райды - это как выкатить из произвоственного корпуса новый блестящий автомобиль. Аэродинамичный. С ксеноном. И долго матюкаться на то что неудобно пристраивать оглобли к привычной кляче.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	228. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Классический анонимус on 24-Дек-14, 10:07
	есть 2 диска, например, на терабайт и 2 терабайта - в обычном случае вы можете из них сделать например зеркало на терабайт С помощью mdadm всю жизнь можно было сделать зеркало 1ТБ + 1ТБ в любом другом виде. Вдобавок на надежных ФС, вылизываемых годами.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	233. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 26-Дек-14, 17:59
	> С помощью mdadm всю жизнь можно было сделать зеркало 1ТБ + 1ТБ > в любом другом виде. Вот только проблема в том что все это лоскутное одеяло нарезает админ, а любая реконфигурация - боль. И одномоментная кантовка кучи данных. И да, btrfs нормально сделает зеркало и если есть например 3 диска: один на 2 Тб и 2 на 1Тб. При этом для 2Тб блоков найдутся парные устройства. А админу надо только девайсы добавить и схему хранения выбрать. Дальше голова будет болеть у аллокатора. А у вас - лоскутное одеяло должен кроить сам админ. А чуть новый девайс добавил и прочее - перекройка. > Вдобавок на надежных ФС, вылизываемых годами. Волков бояться - FAT12 FTW. Уж его проверили годами.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	16. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от tehnikpc (ok) on 20-Дек-14, 14:42
	Не юзер, а системный администратор.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	23. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от онаним on 20-Дек-14, 15:43
	>если юзер допускает заполнение диска на 100% Если мне не изменяет память, то в btrfs как-раз другая ситуация. Речи о полной забивке диска речи не идет, более того - даже невозможно предсказать количество реально свободного места из-за не вполне адекватного разрастания метаданных (при некоторых видах нагрузки). Поправьте, если проблема уже не актуальна, или где наврал.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	30. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Анцифер on 20-Дек-14, 17:30
	OverlayFS тупая, как полено - там ломаться нечему.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	80. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:27
	> OverlayFS тупая, как полено - там ломаться нечему. Ну так замена самосвала на мопед с аргументом "лучше вписывается в повороты и проще парковать".
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	86. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 02:06
	Это и есть UNIX way: вместо одного самосвала, используется тысяча человек на мопедах (а лучше - самокатах). В результате, резко возрастает надежность - поломка отдельного мопеда слабо влияет на работоспособность системы. Ну а что не оптимально немного - так пусть за оптимальностью и быстротой всякие поттеринги гоняются, раз оно им так надо.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	94. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 04:42
	> Это и есть UNIX way: вместо одного самосвала, используется тысяча человек на > мопедах (а лучше - самокатах). Поэтому такие господа сливаются как только вопрос заходит о трансконтинентальных перевозках. Ведь мопеды не плавают и не летают. Ну да, главное правильно задачи под средства подбирать, а не наоборот. > В результате, резко возрастает надежность - Угу, изобразите мне множественные снапшоты с записью и динамически выбираемые на ходу уровня райда вашим вэем. Тогда поговорим. > поломка отдельного мопеда слабо влияет на работоспособность системы. Как интересно. То-есть, по вашему поломка ext4 или overlayfs мало повлияет на работоспособность системы? > за оптимальностью и быстротой всякие поттеринги гоняются, раз оно им так надо. Немного - это когда файлуху дико клинит при наличии снапшота, так что ей пользоваться без слез невозможно? Или когда надо небольшой райд на ...цать терабайтов разобрать? Всего полдня кантования данных - и уровень RAID изменен?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

3. "Проект CoreOS рассматривает возможность ухода от использован..."	–4 +/–
Сообщение от твой мозг on 20-Дек-14, 11:08
а поттер наоборот хочет все и вся завязать за свои поделки и btrfs
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
Сообщение от Спокойный Аноним on 20-Дек-14, 11:11
Хм, ведь вменяемые люди ещё 4 года назад выяснили (или, как я, безоговорочно поверили специалистам, например Э.Шишкину), что btrfs архитектурно ущербен. Однако ребята из СoreOS зная, что Btrfs сомнительная поделка, заставляли своих клиентов им пользоваться. Или не знали? Тогда вообще возникает вопрос об их профпригодности и доверию к СoreOS.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от grec on 20-Дек-14, 12:27
	Профпригодны. Расчитывают риски и на основе результатов что-то впаривают. И так по кругу.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от rob pike on 20-Дек-14, 13:09
	У инвесторов - не возникает.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	58. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 22:51
	> безоговорочно поверили специалистам, например Э.Шишкину), Пользуйся файловыми системами от эксперта Шишкина. Флаг тебе в руки и барабан на шею.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
Сообщение от Аноним (??) on 20-Дек-14, 11:18
ZFS который не поддался плагиаторам из Linux
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от res2500 (ok) on 20-Дек-14, 13:37
	точно, все сходится, это бсдшники писали жалобы в CoreOS по поводу btrfs, думали ZFS выберукт и опять облом (
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	15. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Онаним on 20-Дек-14, 14:27
	ZFS используют во многих ОС, а не только в BSD... Зато в Linux все как всегда - файловых систем полно, а доведенных до ума - почти ниодной :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Школьник (ok) on 20-Дек-14, 14:49
	+100500 И, что самое интересное, ситуация за 10 лет практически не изменилась.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 14:54
	Сантехники написали опенсорцную схд, похожую на фс, бздуны радуются, что её не включили в линуксовое ядро.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	22. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 15:35
	Покажите стабильно работающий аналог в Linux.BTRFS ведь совсем не торт :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	25. "Проект CoreOS рассматривает возможность ухода от использован..."	+4 +/–
	Сообщение от EHLO on 20-Дек-14, 15:53
	> Покажите стабильно работающий аналог в Linux.BTRFS ведь совсем не торт :) Если сравнивать только с ZFS, то Btrfs торт. Но так как в Линуксе выбор несколько шире, можно подобрать более подходящий инструмент.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	31. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от НуфНуф on 20-Дек-14, 17:40
	>Если сравнивать только с ZFS, то Btrfs торт. Ну, это неправда. Насчет широкого выбора - согласен.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	67. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:03
	> Ну, это неправда. В btrfs можно подыграть базе или файлу виртуалки, отключив CoW. Там не врут про ненадобность дефрагера. И экстенты делают по людски. И памятью управляют нормально. И даже уровни RAID могут делать в произвольной смеси. А не так что 1 раз и на века hardcoded схема, а потом ничего не переделать без перестройки немеряного пула. > Насчет широкого выбора - согласен. Кроме всего прочего кому сильно надо - могут и ZFS использовать.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	75. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Александр (??) on 21-Дек-14, 00:19
	Прекрасно. А теперь прочитайте новость. Не благодарите!
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	81. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:31
	> Прекрасно. А теперь прочитайте новость. Не благодарите! Почитал. И имею заметить что сдуру можно и ... сломать. Да, ext4 может быть несколько быстрее. Но он не делает полное журналирование, снапшоты можно только где-то сбоку приделать, тормозно и урезанно. Смена уровня RAID потребует ребилдить весь пул. Ну и так далее. А так то да, мопед входит в повороты лучше самосвала.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	148. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 20:12
	Перестаньте онанировать на экстенты - переменный размер блока это примерно тоже. Опять же - у экстентов свои проблемы.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	34. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 20-Дек-14, 18:56
	Назовите хоть 10 функций btrfs которых нет в zfs :) P.S. zfs отлично работает в продакшн в разных ОС, а btrfs пока еще пытается избавится от детских болезней при работе только в одной ОС :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	49. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от ананим on 20-Дек-14, 21:52
	Ну назовите 10 ОС, в которых zfs "работает в продакшн". Зыж Под виртуалки и контейнеры zfs подходит ещё хуже. Или как минимум — не лучше (как минимум cow можно в бтр отключить по-файлово) Например вот такой эпиквын — шhttp://habrahabr.ru/company/hostkey/blog/179151/ Ззыж > которых нет в zfs Например закрузка со снепшота. одно это 10 заменит.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	63. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 20-Дек-14, 23:34
	гружусь со снапшота на zfs, ЧЯДНТ?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	83. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от ананим on 21-Дек-14, 00:53
	> ЧЯДНТ? Э-э-э, врёшь? Zfs позволяет создать из снэпшота новый boot environment (ручками), но не загрузиться с любого снэпшота корневой фс.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	68. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:05
	> Назовите хоть 10 функций btrfs которых нет в zfs :) http://www.opennet.me/openforum/vsluhforumID3/100963.html#67 - может не 10, но вам хватит. > P.S. zfs отлично работает в продакшн в разных ОС, Понятия о хорошем у всех разные. И кстати ZFS как-то так заметно постарше будет.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	43. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от anonimouse on 20-Дек-14, 20:10
	>Если сравнивать только с ZFS, то Btrfs торт. бтрку хоть с чем сравнивай - все одно эпическое она *вно. В чём центосовцы _прямо_ и пишут, мол поддались пиз****лам с форумов - перешли, теперь вылим с неё быстрее собственного визга :) Ну а по делу ZFS - хорошая СХД, но на песюг - овекилл. Ранше, давным давно в Линуксе была JFS которая служила верой и правдой, за ~7 лет жёсткой 24х7 експлуатации в продакшене с ней небыло проблем ... ВООБЩЕ! От слова напрочь. Но она скучная - без свисулек и колокольчиков, в линуксах еЯ забыли, там такое больше не живёт ...
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	46. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от EHLO on 20-Дек-14, 20:50
	>бтрку хоть с чем сравнивай - все одно эпическое она *вно. В чём центосовцы _прямо_ и пишут, мол поддались пиз****лам с форумов - перешли, теперь вылим с неё быстрее собственного визга :) Не надо утрировать. Абсолютно аналогично ZFS, она просто не годится в ФС общего назначения пока, а возможно и не будет годиться. Тем не менее юзкейсы у нее есть. >Ну а по делу ZFS - хорошая СХД Не знаю где и с кем ты ее сравнивал как СХД, но глядя на все эти недо-NetApp-ы с ZFS внутри, я категорически в этом сомневаюсь.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	50. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от ананим on 20-Дек-14, 21:57
	> Ранше, давным давно в Линуксе была JFS которая служила верой и правдой, за ~7 лет жёсткой 24х7 експлуатации в продакшене с ней небыло проблем. Хм. Вон xfs рядышком. С 2007 как раз живёт например. Зыж > бтрку хоть с чем сравнивай - все одно эпическое она *вно. Да пфу на вас и ваше мнение.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	110. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 13:25
	> Хм. Вон xfs рядышком. > С 2007 как раз живёт например. Только до 2.6.28 данные нулями затирала только в путь. И с тех пор так и осталась ФС где журналятся только метаданные. И которая противно тупит на куче мелочевки (e.g. распаковка ядра линукс). p.s.докопаться можно к любой ФС - идеальных не бывает ;)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	132. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Crazy Alex (ok) on 21-Дек-14, 17:13
	Нули? Вы о продакшне говорите, или о чем? Или у вас на продакшне бесперебойников нет? Это, если что, единственная ситуация, где xfs могла нули нарисовать. Кстати, не тупит на мелочевке она уже с год, если не больше. Но так - да, для мелочевки и не предназаначалась. JFS зато зашибись какая "быстрая". А полное журналирование, кстати - дурь для подваляющего большинства случаев. Потому что даже если все данные записаны на момент сбоя - это никак не гарантирует их логическую целостность. Целостность метаданных как раз и даёт возможность задействовать высокоуровневые тулзы, которые понимают, что вы там писали, и могут проверить целостность.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	184. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 11:02
	> Нули? Вы о продакшне говорите, или о чем? Или у вас на > продакшне бесперебойников нет? Да-да, в тепличных условиях - любая ФС это образец надежности :). Собственно без упсы я XFS вообще не рискую использовать. Хотя это дело с нулями всех достало и вроде опосля 2.6.28 это более-менее сошло на нет. > Это, если что, единственная ситуация, где xfs могла нули нарисовать. А еще оно журналит только метаданные и не парится что с данными случится. Режима полного журнала нет совсем, что как бы намекает. > Кстати, не тупит на мелочевке она уже с год, если не больше. Где-то в свежих ядрах ее действительно подтянули в плане интенсивной работы с метаданными. Но стало вместо "уу, как все плохо" всего лишь "да ну его, что тут хорошего?". В смысле, какой-нибудь ext4 довольно сильно воткнет в таких нагрузках. Ну так, по наблюдениям. В общем файлуха под видеомонтаж и есть файлуха под видеомонтаж. Оно ничего так если распихать на несколько дисков да под большие файлы. И только. > Но так - да, для мелочевки и не предназаначалась. JFS зато зашибись какая "быстрая". JFS слоупочный что так что сяк. По поводу чего я им и перестал пользоваться. Но на слабых машинах, где проц относительно хилый а диск относительно быстрый и все начинает упираться в проц - JFS может быть интересной опцией и даже кого-то обыграть по скорости. Главное чтобы все в проц упиралось ;). Так что не самая плохая опция для всяких малохольных мипсов и армов. > А полное журналирование, кстати - дурь для подваляющего большинства случаев. Не знаю кому оно "подваливает", но дурь - это когда у вас в файле оказывается половина новых данных и половина старых. После этого файл обычно напрочь неюзабелен. > Потому что даже если все данные записаны на момент сбоя - это никак > не гарантирует их логическую целостность. Зато обрывание записи на середине - почти гарантирует дальнейшую непригодность содержимого файла. > Целостность метаданных как раз и даёт возможность задействовать высокоуровневые > тулзы, которые понимают, что вы там писали, и могут проверить целостность. Ну окей, допустим у меня образовался в результате жыпег который наполовину новый и наполовину старый. Декодер жпега в середине файла поймает какую-нибудь ошибку декодирования. И? Нормальной фотографией это уже не будет являться. И никакие высокоуровневые тулзы нормальный вид этому уже не вернут. Вот например откатить все снапшот (или просто достать из иерархии снапшота нужный файл) - это прокатит. В плане того что все вернется в вид как было на момент его создания. Но это уже не про XFS...
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	198. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 15:01
	>Да-да, в тепличных условиях - любая ФС это образец надежности :). Собственно без упсы я XFS вообще не рискую использовать. Хотя это дело с нулями всех достало и вроде опосля 2.6.28 это более-менее сошло на нет. Не просто "более-менее сошло на нет", а сошло на нет напрочь. Во всяком случае, после этого жалоб не видел ни в интернете, ни живьём - был случай плотно полюбоваться на xfs, умирающую по причине периодических отказов диска из-за хренового БП. > Где-то в свежих ядрах ее действительно подтянули в плане интенсивной работы с метаданными. Но стало вместо "уу, как все плохо" всего лишь "да ну его, что тут хорошего?". В смысле, какой-нибудь ext4 довольно сильно воткнет в таких нагрузках. Ну так, по наблюдениям. В общем файлуха под видеомонтаж и есть файлуха под видеомонтаж. Оно ничего так если распихать на несколько дисков да под большие файлы. И только. Я, если что, её бенчил на этот счёт, могу данные подкинуть. там расхождение в пределах 10-20 процентов с ext4, и не всегда в пользу последней (удаление на xfs быстрее, iirc). И это был далеко не самый комфортный для xfs режим - потому что не на RAID, где она себя показывает круче всего. >JFS слоупочный что так что сяк. По поводу чего я им и перестал пользоваться. Но на слабых машинах, где проц относительно хилый а диск относительно быстрый и все начинает упираться в проц - JFS может быть интересной опцией и даже кого-то обыграть по скорости. Главное чтобы все в проц упиралось ;). Так что не самая плохая опция для всяких малохольных мипсов и армов. Экзотика - ну да ладно, может пригодиться. В любом случае не серверная и не десктопная ФС получается. >Не знаю кому оно "подваливает", но дурь - это когда у вас в файле оказывается половина новых данных и половина старых. После этого файл обычно напрочь неюзабелен. Разумеется, неюзабелен. Ситуация, никак не отличающаяся от той, когда программа-писатель успела пол-файла записать (в смысле вызова write), а  потом система умерла. Что, собственно, в большинстве случаев би будет происходить. Попасть в промежуток, когда write() все прошли и файл консистентен, но еще (частично) не записан на диск - это суметь надо. Опять же - на каких-то ворклоадах, может, это и частая ситуация, но так с ходу в голову ничего не приходит. >Вот например откатить все снапшот (или просто достать из иерархии снапшота нужный файл) - это прокатит. В плане того что все вернется в вид как было на момент его создания. Но это уже не про XFS... Дык. И это не про журналирование вообще. Снапшоты - штука хорошая, не спорю. Хотя, опять же, если софт не закладывается на их существование (а он и не должен) то старого доброго "переименовал - создал новое - прибил старое" достаточно, если, конечно, система каждый час не падает. Но да - согласен, снапшоты на уровне ФС - приятно и удобно.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	218. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 23-Дек-14, 00:39
	> Не просто "более-менее сошло на нет", а сошло на нет напрочь. Это отлично, но сколько лет это чинили? Да и из интересного в XFS разве что структура при которой оно хорошо работает на нескольких дисках с большими файлами. В остальном ФС как ФС, без каких-то гигантских преимуществ. > Во всяком случае, после этого жалоб не видел ни в интернете, ни > живьём - был случай плотно полюбоваться на xfs, умирающую по причине > периодических отказов диска из-за хренового БП. Мне тоже после 2.6.28 такое не попадалось - наверное более-менее дожали. > расхождение в пределах 10-20 процентов с ext4, и не всегда в > пользу последней (удаление на xfs быстрее, iirc). У меня до сих пор есть несколько томов в XFS и мне в целом не особо нравится как они работают. Если не лениво - попробуй забенчить например получение полной иерархии (обход директорий и получение списка файлов) на холодную для ext4 и xfs. Это разумеется надо делать на холодную для каждой ФС (записали файлы - ребут - обход иерархии) и никуда не выводить весь список (чтобы IO и рендеринг от большого списка нигде не клинило). Есть ощущение что xfs на холодную как-то довольно неспешно делает обход vs остальные. Очевидный юзкейс где это может анноить - поиск по вилдкардам в mc, например. На горячую конечно все шустро, но это не заслуга ФС. > RAID, где она себя показывает круче всего. Ну да, он с его allocation groups заточен на то чтобы его на несколько дисков раскладывали. Если охота работать с большими файлами и на RAID - вариант. Но это как-то не мои типовые юзкейсы. А например как оно выдерживает несколько иерархий линуксного кернела мне не нравится - на холодную оглавление как-то долго обходится. > Экзотика - ну да ладно, может пригодиться. В любом случае не серверная > и не десктопная ФС получается. Еще не врут про неубиваемость (насколько это понятие применимо для классики с журналом только метаданных). Но в остальном - серая мышка. Единственное разумное что приходит - ФС для винча прицепленного к роутеру со слабым процом и подобные странноватые применения. > успела пол-файла записать (в смысле вызова write), а  потом система умерла. Если программа не атомарно пишет файл и потом не может это прочитать - это продолб программы и за это спрос с авторов. А если прога сделала 1 большой write на весь файл и файлуха при этом сделала ни два ни полтора - это уже предъявы к файлухе. > Что, собственно, в большинстве случаев би будет происходить. Попасть в > промежуток, когда write() все прошли и файл консистентен, но еще (частично) > не записан на диск - это суметь надо. По идее достаточно сделать 1 большой write() со стороны программы, переписывающий весь файл или его заметный кусок, а потом нарваться на крах, когда это стало по факту выдавливаться на блины? В результате получится файл который ни туда ни сюда. Хотя программа со своей стороны все нормально сделала. Если не считать нормальным адские костылищи, типа записи в темпарь и ренейм, что почем зря гадит фрагментацией и заметно усложняет код. И является гнусным хаком для компенсации непотребного поведения ФС на уровне приложений. Хотя по идее им бы вообще про журналирование знать не следовало. > Дык. И это не про журналирование вообще. Снапшоты как таковые в нормальном виде - некое логическое доразвитие неразрушающего однократного журналирования (CoW и все что подобное по смыслу). Их можно конечно делать и иначе, но получается дрянь. В случае CoW все необходимое для снапшота - уже есть, а сама механика подразумевает легкое и беспроблемное обеспечение сохранности снапшота. Это, в паре с скоростью записи близкой к скорости совсем без журнала, при эффекте близком к полному журналированию настолько жирный и очевидный плюс что большинство новых дизайнов ФС - пытаются делать как-то вот так в основном. Бонусом такие дизайны лучше для флешовых носителей - read-patch-write со стороны фс они не любят, поскольку очень маловероятно что это совпадет с блоками флеша и в результате получится усиление протирания флеша. > (а он и не должен) то старого доброго "переименовал - создал > новое - прибил старое" достаточно, Со своей стороны я считаю это у...щным application layer костылем недожурналу. Этот подход должен умереть - программы не должны делать работу ФС без сильной причины. Я знаю только 2 сильные причины: БД и CoW диски виртуалок, которые могут иметь какие-то свои очень кастомные пожелания по поводу того чтобы ФС была для них почти интерфейсом к блочному уровню, с минимумом помех. Чисто блочные девайсы лучше - но их неудобно админить. > Но да - согласен, снапшоты на уровне ФС - приятно и удобно. Бонусом я еще считаю крайне у..щным когда программы вынуждены заниматься левым oнaнизмoм усложняющих их код, для компенсации неспособности ФС нормально журналировать.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	69. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:09
	> Ранше, давным давно в Линуксе была JFS которая служила верой и правдой, Только журнал, как обычно только метаданных. И скорость работы довольно хилая. А так ФС как ФС. Но какой-то смысл имеет только на конфигах с слабым процом - ресурсы кушает очень скромно. > проблем ... ВООБЩЕ! А жесткая эксплуатация включала слеты питания, ребуты и кернелпаники? Или в чем жесткость состояла? > Ну а по делу ZFS - хорошая СХД, но на песюг - овекилл. А мне вот и btrfs даже на нотике ничего так. Снапшоты штука хорошая. И в отличие от всяких LVM они просто и быстро делаются и потом не тормозят всю файлуху. А некие фичи СХД не так уж плохо смотрятся на десктопнике с кучей хардов. Возможность добавить +1 хард при недостатке места без перетрясок данных терабайтами - очень мило.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	116. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 14:21
	btrfs збс пока не начинает рассыпаться
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	185. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 11:07
	> btrfs збс пока не начинает рассыпаться Это же верно для любой ФС. А у бтрфс на крайний случае есть неразрушающая "читалка" позволяющая цепляться к остаткам структур и выцеплять файлы без риска все испортить еще сильнее. Какие-то аналоги этого я видел разве что в паре коммерческих утилей для фат и нтфс. А так у меня бтрфс есть на некоторых машинах. Некоторые уже с полгода наверное пользуются оной. Вроде не рассыпается. Не буду утверждать что это хардкорный тест на убиение, с зашкаливащей нагрузкой и тыканием в краевые условия типа окончания места каждые 5 минут или пулы с 100500 дисков, но все-таки.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	193. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 22-Дек-14, 13:49
	> А так у меня бтрфс есть на некоторых машинах. Некоторые уже с > полгода наверное пользуются оной. Вроде не рассыпается. С какой периодичностью вы запускаете утилиту верификации данных на ФС? (по типу scrub)
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	213. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 17:25
	> С какой периодичностью вы запускаете утилиту верификации данных на ФС? (по типу scrub) Как правило - примерно раз в месяц. И нет, ошибок не обнаруживалось. Но это на грани test flight и неответственного продакшна. В системах с btrfs используются свежие ядра. Наверное поэтому все оки-доки.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	199. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 15:07
	Для ext2 такое добро точно есть, в репах дебиана лежит. Даже пользовался как-то. На тот момент (а было это года 4 назад) работало для ext2/3, для ext4 не пахало. дальше не копал, так как вытаскивать надо было с ext3. Ну и из общих соображений - чем сложнее труктуры данных тем больше проблем что-то из них вытащить в нештатной ситуации и тем больше шансов на эту самую ситуацию нарваться. В том числе поэтому там, где можно обойтись простой ФС - надо ей обходиться. Это, если что, безотносительно btrfs - так, общий принцип. Вполне верю, что её в плане востстановления сделали достойно и сам код довели до приличного уровня стабильности.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	214. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 17:52
	> вытаскивать надо было с ext3. Я забыл что такое ext3. Его производительность на фоне ext4 - ни о чем. > проблем что-то из них вытащить в нештатной ситуации и тем больше > шансов на эту самую ситуацию нарваться. В принципе все это так, но лажа случается везде а спецутиля для этого самого, готовая к такому обороту в явном виде - лучше чем самому в хексэдиторе пыхтеть, знаете ли. > где можно обойтись простой ФС - надо ей обходиться. Надо? Обходитесь. Берите FAT и радуйтесь простоте. А я как-то так несколько раз налетал на перезаписывание куска иерархии и терял данные именно по этому поводу. Раскатав относительно старый бэкап при отсутствии более нового, например. Или переписав вон тот файл более старым. Бэкап в целом достаточно длинная и затратная операция и часто ее делать не будешь. А снапшот - можно. В CoW все есть для его создания - снапшот это лишь некая довольно формальная пометка. Это не занимает много времени и ресурсов само по себе. Мне это нравится. Я привык к этому на VM и считаю что настает время сделать мне столь же удобно и на железных хостах. Как по мне - выбор ФС сложный и многофакторный процесс, без единого универсального критерия. Есть некие задачи и пожелания. Есть разные ФС. И простота ФС - да, это некий плюсик. Но в целом мое время стоит дорого и у меня есть ряд более интересных вещей чем занятие патологоанатомией с хексэдитором в останках ФС. Поэтому мной прото будет предпринят ряд мер которые не требуют много моего времени но позволяют восстановить в случае аварии большинство данных без такого хардкора. Это сэкономит мне кучу времени. > в плане востстановления сделали достойно и сам код довели до приличного > уровня стабильности. Просто как-то радует подход. Судя по списку рассылки - те кто доигрывался до совсем убитой ФС как правило отколупывали этими утилитами наиболее ценные данные и при своем все-таки обычно оставались. Что довольно неплохо на мой вкус. И с точки зрения дата рекавери мне недеструктивное чтение наиболее симпатично - при этом надо только дисковую емкость под спасаемые файлы и не надо места под образ и отпадает длительная операция снятия образа. Потому что нет шанса напортачить. Хотя если проблема в самом носителе - там конечно лучше образ сделать штуками типа myrescue, чтобы накопитель не сдох в процессе восстановления. Но тут уж здравый смысл никто не отменял.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	215. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 18:41
	Ну, что было (ext3) - то и вытаскивал. Там, где она жила, скорость диска вообще роли не играла, даже не заню, с каких времен она там жила. Я к тому, что не стоит приводить тулзу для btrfs как что-то экстраординарное. Навскидку в сети нашлись проги и для ext4, и для xfs на эту тему. Так что про время и хексэдитор - не надо. И да, если у тебя три десятка файлов, которые пишутся раз в три года - можно и FAT взять, или ext2, которую многие до сих пор любят юзать для /boot. А снапшоты... где они нужны, где нет. Что-то сомнительно мне, что в /tmp нужны снапшоты. Да и в большинстве других случаев "снапшот" делается переименованием изменяемого директория на *.backup, если места хватает, конечно. Но его почти всегда хватает. Я не спорю, что у btrfs прикольный дизайн и, возможно, крутая реализация. Но в результате имеем сложную штуковину, до сих пор не "благословлённую" для продакшна как те же ext*, xfs или, упаси шайтан, FAT.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	216. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 19:25
	> Ну, что было (ext3) - то и вытаскивал. Со своей стороны могу похвалить ext-ы за неплохой fsck - обычно удается догнать до моунтабельного состояния и вынуть данные штатно. > тулзу для btrfs как что-то экстраординарное. Таких утилит не слишком много. > Навскидку в сети нашлись проги и для ext4, и для xfs на эту тему. И все-таки штатная утилита такого плана прямо от авторов ФС - это очень симпатично придумано и я склонен считать это ощутимым достоинством пакета утилит к ФС. > Так что про время и хексэдитор - не надо. Возможно. Но у btrfs такая утиля идет сразу в комплекте и если она даст маху - про нее можно спросить у тех кто делал ФС. Т.е. тех кто в своей ФС лучше всего и разбирается как раз. > И да, если у тебя три десятка файлов, которые пишутся раз в > три года - можно и FAT взять, Можно. Но у меня обычно больше файлов, мне не фиолетово с какой скоростью это будет работать, я не считаю что меня устраивают ограничения по иерархиям и размерам и хотелось бы чтобы на случай продолбов был откат. В ряде случаев я бы не отказался от прозрачной расширяемости по принципу доткнул диск - получил место. И возможности гибко переиграть. Понятно что без ряда возможностей можно прожить. Но так в принципе можно прожить и без электричества... > или ext2, которую многие до сих пор любят юзать для /boot. Я в общем случае не считаю нужным городить лоскутное одеяло из кучи разделов. Если загрузка с физически отдельного носителя - я еще это понимаю. Но там обычно вся система. А какую самоценность представляет лысый бутлоадер без ОС? > А снапшоты... где они нужны, где нет. Что-то сомнительно мне, что в /tmp нужны снапшоты. Ну так необязательно делать /tmp со снапшотами. Хотя тут тоже очень зависит от софта и прочего. > Да и в большинстве других случаев "снапшот" делается переименованием > изменяемого директория на *.backup, если места хватает, конечно. Но его почти > всегда хватает. Вот только копирование разлапистых иерархий может занимать ощутимо времени. Снапшот делается условно-мгновенно, поскольку ничего никуда не копирует. А просто ставит некие метки и потом изменения в этой иерархии будут идти относительно вот этого вот. Мне это как-то кажется разумным и логичным. Я привык к этой механике в виртуализаторах, где cow based диски виртуалок - норма жизни. И считаю что на железках мне это тоже хочется. > для продакшна как те же ext*, xfs или, упаси шайтан, FAT. Вообще-то по мнению разработчиков - уже можно юзать со свежими ядрами. Ну кроме RAID5/6. Этому же мнению вторили и фуджики, при том они вообще куда-то в ответственные применения метят и потому явно будут пинать причастных и сами подпрягутся остатки закидонов вылавливать. А так я вижу довольно много интересных заделов на будущее в таком дизайне и склонен считать это еще на поколение опосля ZFS. Этакий CoW сделанный с оглядкой на современные продакшны и их проблемы.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	102. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:28
	> чём центосовцы _прямо_ и пишут, Какие центосовцы? В новости про CoreOS. Это весьма нишевая и своеобразная операционка с весьма своеобразными задачами. > мол поддались пиз****лам с форумов - Пиз****лы с форумов похоже не различают CentOS и CoreOS в своих приступах понoса...
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	52. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 22:04
	zfs в линуксе достаточно стабильно работает для показывания?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	61. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Andrew Kolchoogin (ok) on 20-Дек-14, 23:21
	Приемлемо. Есть определённые грабли, но есть и хорошее средство защиты от них: при создании ZFS-пула просто сказать "-o version=28".
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	27. "Проект CoreOS рассматривает возможность ухода от использован..."	+4 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 16:38
	> ZFS используют во многих ОС, а не только в BSD... > Зато в Linux все как всегда - файловых систем полно, а доведенных > до ума - почти ниодной :) Ну, и покажи что-то надёжнее семейства ext*, особенно ext4! Ищи во всех ОС и неОС. Из неродных, как родная работают jfs, zfs.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	35. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 19:01
	>> ZFS используют во многих ОС, а не только в BSD... >> Зато в Linux все как всегда - файловых систем полно, а доведенных >> до ума - почти ниодной :) > Ну, и покажи что-то надёжнее семейства ext*, особенно ext4! > Ищи во всех ОС и неОС. > Из неродных, как родная работают jfs, zfs. ext4 уже научилась хотя-бы делать snapshot`ы? btrfs начали лепить со стыда перед возможностями zfs )))
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	107. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 11:24
	Снэпшоты есть в снэпшотных ФС, а не экстентных.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	115. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 13:59
	> Снэпшоты есть в снэпшотных ФС, а не экстентных. А бтрфс использует экстенты и умеет снапшоты. Ы?
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	153. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от maximnik0 on 21-Дек-14, 21:21
	>>> ZFS используют во многих ОС, а не только в BSD... >>> Зато в Linux все как всегда - файловых систем полно, а доведенных >>> до ума - почти ниодной :) >> Ну, и покажи что-то надёжнее семейства ext*, особенно ext4! >> Ищи во всех ОС и неОС. >> Из неродных, как родная работают jfs, zfs. > ext4 уже научилась хотя-бы делать snapshot`ы? Снапшоты при помощи костылей  может делать и ext3 -проект  ext3cow .Читал про такой же  проект и  для  ext4 ,вроде в какие то ветку Аллана падчи  даже и включены ,почему падчи не принемают в основную ветку не знаю .
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	186. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 11:09
	> ,почему падчи не принемают в основную ветку не знаю . Потому что нафиг никому не упало делать из запорожца аэроплан, когда под боком есть аэродром с нормальным самолетом.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	41. "Проект CoreOS рассматривает возможность ухода от использован..."	–6 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 19:58
	NTFS. не троллю,  серьёзно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	44. "Проект CoreOS рассматривает возможность ухода от использован..."	+7 +/–
	Сообщение от anonimouse on 20-Дек-14, 20:13
	> NTFS. не троллю,  серьёзно. Курам на смех, и что характерно - тоэе не троллю, тоэе - серьёзно. :)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	70. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:11
	> NTFS. не троллю,  серьёзно. Дисковые технологии ранних девяностых. С соответствующими скоростями работы и костылями. В чем разница? Когда у меня на btrfs лежит кучка снапшотов я даже не задумываюсь что они есть. Когда на NTFS делается снапшот - всю систему клинит нафиг.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	125. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 15:59
	>> NTFS. не троллю,  серьёзно. > Дисковые технологии ранних девяностых. С соответствующими скоростями работы и костылями. > В чем разница? Когда у меня на btrfs лежит кучка снапшотов я > даже не задумываюсь что они есть. Когда на NTFS делается снапшот > - всю систему клинит нафиг. Сынок, может, ты asyncIO просто не знаешь, где включается?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	158. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 23:18
	>Сынок, может, ты asyncIO просто не знаешь, где включается? Сынок а ты не хочешь озвучить с какой форточки это стало доступно ? :-) И самое главное - насколько это помогло :))))
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	187. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 11:10
	> Сынок, может, ты asyncIO просто не знаешь, где включается? Не отменяет того факта что в случае нтфс файлуха при снапшотировании истошно тормозит, дяденька. И если файлуха тормозит - там хоть синхронный io, хоть асинхронный. Стоять колом он будет одинаково. И нет, я не считаю что все это должно работать настолько погано...
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	51. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от анонко on 20-Дек-14, 22:04
	> ZFS используют во многих ОС, а не только в BSD... > Зато в Linux все как всегда - файловых систем полно, а доведенных > до ума - почти ниодной :) и не только файловых систем...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	96. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:05
	> и не только файловых систем... Только почему-то мегаконцептуальные системы вообще взлететь не могут, академичные бзды отовсюду повылетали, etc. При том заслуженно. Потому что когда господа делают убер-мега-слой журналирования которым потом пользуется аж целый гунявый UFS, который доброго слова не стоит ни так ни эдак - это просаживание кучи времени в унитаз.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	127. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Куяврег on 21-Дек-14, 16:03
	> а доведенных до ума - почти ниодной :) jfs, xfs, reiser3, не?  я не возражаю, что во фряхе есть и толковая ZFS, и геом прекрасен, но "ни одной" в Линуксе - это перебор, не находишь? и лично я бы не отказался от xfs на фряхе, например.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	138. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 21-Дек-14, 18:07
	Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи (Разве что с ядром не идёт одним тарболом). И пишут (если можно так назвать процесс без участия ораклп) её уже года 2 совместно. Более того, линуксоиды даже больше остальных.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	141. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от iZEN (ok) on 21-Дек-14, 18:18
	> Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи (Разве > что с ядром не идёт одним тарболом). > И пишут (если можно так назвать процесс без участия ораклп) её уже > года 2 совместно. Более того, линуксоиды даже больше остальных. Можно взглянуть на выхлоп линуксового "zpool upgrade -v"?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	146. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 21-Дек-14, 19:16
	ровно такой же, как в бзд релиз. Да, писюн в бзде карент и стэбл длиннее. А поддержка lz4 например в линухе была раньше. И что? Что ты этим хотел доказать? "Родственность" определяется использованием (и в линухе, и в бзде) spl (Solaris Porting Layer) — эдакий вайн, но вместо вантуза — соляра. Так что, "родственник", гони рубль. Мне Афоня рубль должен. И ещё не факт, в силу тех или иных причин, в какой системе будет работать надёжнее, быстрее и тд. В линухе работы только чуть больше, потому что начали позже. Поэтому и пилят сейчас больше. А когда дойдут до предела вываленных ораклом сырцов, так все и встанут. Вот такой вот вендор-лок'с. (Есть вариант пилить дальше, наплевав на совместимость. Весело короче)
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	147. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 21-Дек-14, 19:29
	> ровно такой же, как в бзд релиз. > Да, писюн в бзде карент и стэбл длиннее. А поддержка lz4 например > в линухе была раньше. Что, есть документальные подтверждения этого? У FreeBSD есть: http://svnweb.freebsd.org/base?view=revision&sortby=date&rev... > И что? Что ты этим хотел доказать? То, что линукс с поддержкой ZFS всё-таки позади.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	149. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 21-Дек-14, 20:23
	Тогда повторяю ещё раз фразу, на которую ты выдал этот спич: > Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи А какой там актуальный номер стабильной (критерии стабильности где? ещё раз в бсд-релиз точно такая же, что и в лине) версии — не имеет никакого значения. Всё. Занавес. Зыж Другое дело, что линуксоиды понимают, что эта фс с вендор-локом — инородное тело. Было, есть и будет. Причём и для линуха, и для бсд. А бсдишнеги (вернее конкретно ты. чего это я обобщаю то?) делают вид, что не понимают.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	157. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от iZEN (ok) on 21-Дек-14, 22:27
	> Тогда повторяю ещё раз фразу, на которую ты выдал этот спич: >> Вообще-то zfs для линуха сейчас не менее "родная", чем для фряхи Более новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич. > А какой там актуальный номер стабильной (критерии стабильности где? ещё раз в > бсд-релиз точно такая же, что и в лине) версии — не > имеет никакого значения. > Всё. Занавес. Так какая версия в линуксе? "zpool upgrade -v" что говорит? > Зыж > Другое дело, что линуксоиды понимают, что эта фс с вендор-локом — инородное > тело. Было, есть и будет. Причём и для линуха, и для > бсд. > А бсдишнеги (вернее конкретно ты. чего это я обобщаю то?) делают вид, > что не понимают. Лично я не вижу в ZFS никакого vendor lock-in, так как версии ZFS от Oracle и Illumos давно несовместимы и развиваются параллельными ветками. А тот код ZFS, который используется на FreeBSD, открыт под CDDL - признанной свободной Open Source лицензией. "CDDL несовместима с лицензией GPL. Это происходит из-за того, что GPL требует удаления всех лицензий и применения GPL вместо них, в то время как CDDL запрещает это."
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	173. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от ананим on 22-Дек-14, 07:55
	> Более новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич. Именно. Например с соляры на бзд. На любой бзде. (Что там с шифрацией?) Что на линухе не можешь, что на бзде (о чём я и говорил). И? Каков диагноз? > Лично я не вижу в ZFS никакого vendor lock-in, так как версии ZFS от Oracle и Illumos давно несовместимы и развиваются параллельными ветками. Апофиоз мaрaзма. Ты себе так зaсpaл свой мозг своим же фанатизмом, что даже признавая тот факт, что это по существу уже разные фс, продолжаешь гнать пypгу про какую-то исключительную поддержку zfs в бзде. > А тот код ZFS, который используется на FreeBSD, открыт под CDDL - признанной свободной Open Source лицензией. Да-да. А сша — демократическая страна. И вполне по демократически уничтожила 1,2 миллиона мирных жителей Ирака. А теперь демократически признала, что Ирак к 11 сентября не имел никакого отношения. Ещё раз — zfs для линукса такая же "родная", как и для бзд. Ну допишут эти фьючерсы рано или поздно (добавят пару мелочей, вида lz4, не более), а дальше — обоим ждать гумманитарных бомбардировок от оракла.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	195. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 22-Дек-14, 14:18
	>> Более новая версия ZFS не прочитается в ОС, которая не поддерживает новых фич. > Именно. Например с соляры на бзд. На любой бзде. (Что там с > шифрацией?) ZFS поверх GEOM ELI или BDE — отлаженные решения. > Что на линухе не можешь, что на бзде (о чём я и говорил). > И? Каков диагноз? Диагноз: на линуксе всё гораздо сложнее, чем на фре.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	211. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 17:18
	> Диагноз: на линуксе всё гораздо сложнее, чем на фре. Какой нахальный подгон решения под ответ от пользователя putty.exe. Ишь, шалунишка.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	177. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 22-Дек-14, 08:12
	>> А поддержка lz4 например  в линухе была раньше. > Что, есть документальные подтверждения этого? айзен, ты в курсе что это так (отмечался в новости про это тут, на опеннете) но если твой фанатизм блокирует твой мозк, то могу напомнить: >illumos    Jan 2013 >FreeBSD    Feb 2013 >ZFS on Linux    Jan 2013 >OpenZFS on OS X    Jan 2013 http://open-zfs.org/wiki/Features#lz4_compression
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	28. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 16:41
	> ZFS который не поддался плагиаторам из Linux Слова вантузятнега. Эталонные. Сферические и в вакууме.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	36. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 19:03
	>> ZFS который не поддался плагиаторам из Linux > Слова вантузятнега. Эталонные. Сферические и в вакууме. Ух ты! Во это аргумент! А что же с вашей точки зрения случилось с поделкой под названием btrfs которая собиралась догнать и перегнать zfs, а сейчас отправляется на свалку истории?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	71. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:12
	Батхерт пользователя putty.exe засчитан.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	88. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 02:15
	> ZFS который не поддался плагиаторам из Linux Зато поддается плагиаторами из FreeBSD )))
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	161. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 23:32
	>> ZFS который не поддался плагиаторам из Linux > Зато поддается плагиаторами из FreeBSD ))) Дык! Resistance is futile, you will be assimilated. :)
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	188. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 11:13
	> Дык! Resistance is futile, you will be assimilated. :) Да, вы правильно поняли - вам придется мимикрировать под Linux :)
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

8. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
Сообщение от Аноним (??) on 20-Дек-14, 11:38
очевидный шаг, поздравляю разработчиков с очередным проявлением здравого смысла в мире обезумевшего от бизнеса микрософта (редхета)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
Сообщение от res2500 (ok) on 20-Дек-14, 13:13
> Выбор в пользу OverlayFS теперь я знаю за какую ФС будут холиварить линуксоиды, а btrfs который был хорош и давно готов для продакшена, уже не надо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
Сообщение от Kroz (??) on 20-Дек-14, 14:57
Что-то мне материал по ссылке "низкой производительности" кажется весьма сомнительным. Я такого могу наклепать сколько угодно относительно чего угодно и "доказать" что угодно. Есть другие источники говорящие о низкой производительности btrfs? Также неплохо бы пруфы относительно "ошибки при исчерпании свободного дискового пространства".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Вадик (??) on 20-Дек-14, 15:47
	Согласен, нужны тесты и цифры и желательно у себя их еще прогнать, а это так мазня для детей, нарисовали график и рады...
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	45. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от anonimouse on 20-Дек-14, 20:40
	> Согласен, нужны тесты и цифры и желательно у себя их еще прогнать, > а это так мазня для детей, нарисовали график и рады... Точно! Кто такие эти центосовцы против целого Васи?!?!? Правду они сказали. Не стали прогибаться как демьяновцы под политический момент, а сказали неприятную праву. Теперь у публики лопнет пердак, а эту команду красношляпые попрут вон из команды. А то ведь неровён час они и подЦeD из системы тоже выкинут :-\
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	54. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Kroz (??) on 20-Дек-14, 22:35
	> Точно! Кто такие эти центосовцы против целого Васи?!?!? При чем здесь центос? > Правду они сказали. Где факты, доказывающие? Без фактов это и есть политическое решение - вот тебе и неприятная правда.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	72. "Проект CoreOS рассматривает возможность ухода от использован..."	+4 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:16
	> Точно! Кто такие эти центосовцы против целого Васи?!?!? Какие центосовцы? В сабже про Core OS, которому без году неделя. > красношляпые попрут вон из команды. Вот это я понимаю - честное и совсем не ангажированное мнение. В новости про какой-то CoreOS нам рассказали про редхат, политику и что там еще. Осталось только придумать при чем тут они. И, кстати, редхат никогда и не был основным локомотивом стоящим за btrfs. Там в основном оракл, а потом фуджики и фэйсбук упираются. Еще IBM некое отношение к появлению этой штуки имеет. Но если хочется полить линуксы гуано (то что анонимаус соплярщик с батхертом по понятному поводу - достаточно известный факт) - на это можно не обращать внимание.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

21. "Проект CoreOS рассматривает возможность ухода от использован..."	–6 +/–
Сообщение от bOOster (ok) on 20-Дек-14, 15:16
Хаха. Сколько мы слышали хвалебных од про btrfs! И про есть и про будет. А результат то, как говориться - "на лице" :) Ну как только ZFS допилят на линь, сразу увидим продолжение истории с переездом туда.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 20-Дек-14, 16:35
	год назад поднимал. Убунта и зфс. Работает, доволен. ЧЯДНТ?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	29. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от czarj on 20-Дек-14, 17:00
	FUSE?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	47. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Andrew Kolchoogin (ok) on 20-Дек-14, 20:55
	Native, даже HOWTO есть. Правда, если на современных платформах, то GRUB надо пересобирать, потому что, например, в openSUSE он не собран с поддержкой ZFS статически, а insmod вырублен, если включен Secure Boot (что логично).
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	108. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 11:30
	> FUSE? Хотите - можно и фузю, но мена модуль ведра устраивает. Быстрее всё-таки.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	33. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Kroz (??) on 20-Дек-14, 18:03
	> ЧЯДНТ? - Не следишь за используемыми ресурсами и/или не заботишься о скорости работы - Не думаешь о людях, у которых 32bit система - Скорее всего (но это ты расскажи) не используешь zfs на рутовой партиции (точнее на той, на которой /boot), или лишний раз усложняешь себе жизнь не получая профита, или поведай какие уникальные фичи zfs ты используешь?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	59. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Andrew Kolchoogin (ok) on 20-Дек-14, 22:56
	> - Не следишь за используемыми ресурсами и/или не заботишься о скорости работы А зачем? ZFS следит за распределением ОЗУ сама. > - Не думаешь о людях, у которых 32bit система А также о людях, у которых 80286. :) Впрочем, на FreeBSD ZFS работает и на 32-разрядном ядре. > - Скорее всего (но это ты расскажи) не используешь zfs на рутовой партиции (точнее на > той, на которой /boot), или лишний раз усложняешь себе жизнь не получая профита, или > поведай какие уникальные фичи zfs ты используешь? Какой-такой /boot ещё? host:~ # df Filesystem                     1K-blocks     Used Available Use% Mounted on rpool/BE/openSUSE_13_2         194798592  4621824 190176768   3% / devtmpfs                         1983780        8   1983772   1% /dev tmpfs                            1991156       76   1991080   1% /dev/shm tmpfs                            1991156     1300   1989856   1% /run tmpfs                            1991156        0   1991156   0% /sys/fs/cgroup /dev/sda2                         262144   108904    153240  42% /boot/efi rpool/home                     190176896      128 190176768   1% /home rpool/home/user                190317440   140672 190176768   1% /home/user rpool                          190176896      128 190176768   1% /rpool rpool/BE/openSUSE_13_2/var     190392192   215424 190176768   1% /var rpool/BE/openSUSE_13_2/var/lib 190213760    36992 190176768   1% /var/lib rpool/BE/openSUSE_13_2/var/log 190255488    78720 190176768   1% /var/log rpool/BE/openSUSE_13_2/var/tmp 190366080   189312 190176768   1% /var/tmp host:~ # Зачем он вообще нужен?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	60. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Andrew Kolchoogin (ok) on 20-Дек-14, 22:58
	P.S: GRUB слегка пропатчен (ибо его мэйнтейнеры не любят тестировать программное обеспечение, которое пишут) и пересобран стандартным rpmbuild -bb в присутствии libzfs.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	74. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:18
	> А зачем? ZFS следит за распределением ОЗУ сама. Да, особенно в ARC, только это с ядром не интегрировано. Поэтому когда в системе наступает душняк с памятью - совсем не факт что память удастся выкроить за счет кэша.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	91. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Andrew Kolchoogin (ok) on 21-Дек-14, 02:56
	> Да, особенно в ARC, только это с ядром не интегрировано. Особенно с ядром Соляриса. :)
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	97. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:09
	> Особенно с ядром Соляриса. :) А с ядром соляриса - придется выкраивать чемодан бабла для оракла. И рты для ублажения вендорлокера. Театры одного актера заканчиваются как-то так.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	84. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Kroz (??) on 21-Дек-14, 00:53
	> А зачем? ZFS следит за распределением ОЗУ сама. Сравни потребление памяти при использовании zfs, и с другими ФС. Да, при условии, что ты достигнешь сходной скорости работы. > А также о людях, у которых 80286. :) Людей, у которых 32-битная архитектура несравнимо больше, чем тех, у которых 80286. > Какой-такой /boot ещё? Обеспечение загрузки с zfs не такое тривиальное, как, скажем, с ext4 или reiserfs. Мне было интересно, грузишься ли ты с zfs или нет. Грузишься. Ок. Теперь ответь на вопрос, ради чего все это было нужно. Какие уникальные фичи zfs ты РЕАЛЬНО используешь на практике.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	89. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Andrew Kolchoogin (ok) on 21-Дек-14, 02:30
	>> А зачем? ZFS следит за распределением ОЗУ сама. > Сравни потребление памяти при использовании zfs, и с другими ФС. Да, при условии, > что ты достигнешь сходной скорости работы. ZFS по скорости работы просто не с чем сравнивать. BtrFS неработоспособна, а остальные файловые системы просто не умеют того, что умеет ZFS. Да, и мы, конечно, помним, что one can be arbitrarily fast if data integrity is not a question. А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно. KDE. >> А также о людях, у которых 80286. :) > Людей, у которых 32-битная архитектура несравнимо больше, чем тех, у которых 80286. Intel Atom, что ли? Что за последние пять лет было выпущено, что бы не поддерживало 64 бита? >> Какой-такой /boot ещё? > Обеспечение загрузки с zfs не такое тривиальное, как, скажем, с ext4 или reiserfs. Пересобрать GRUB, запустить mkinitrd. Всё. Весь код для dracut'а устанавливает ZFS. > Мне было интересно, грузишься ли ты с zfs или нет. Грузишься. Ок. > Теперь ответь на вопрос, ради чего все это было нужно. > Какие уникальные фичи zfs ты РЕАЛЬНО используешь на практике. 1. Сквозную проверку целостности данных. 2. copies=3 на домашнюю директорию. Для ноута самое то.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	98. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:13
	> ZFS по скорости работы просто не с чем сравнивать. Изен уже показал нам чего можно получить в ZFS :) > BtrFS неработоспособна, а остальные файловые системы просто не умеют того, > что умеет ZFS. Очередное мнение от эксперта, который этот btrfs в глаза не видел, но мнение имеет. > А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно. > KDE. Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами. > 1. Сквозную проверку целостности данных. > 2. copies=3 на домашнюю директорию. Ты так говоришь как будто это не делается в btrfs :) > Для ноута самое то. Странно что мсье не пришло в бошку использовать для начала хотя-бы снапшоты. Чтобы в случае если что-то пошло не так - иметь возможность отмотать назад за несколько секунд.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	114. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Andrew Kolchoogin (ok) on 21-Дек-14, 13:53
	>> ZFS по скорости работы просто не с чем сравнивать. > Изен уже показал нам чего можно получить в ZFS :) Throughput 951.964 MB/sec 4 procs На ноутбучном харде. Мне хватает гигабайта в секунду пока. :) >> BtrFS неработоспособна, а остальные файловые системы просто не умеют того, >> что умеет ZFS. > Очередное мнение от эксперта, который этот btrfs в глаза не видел, но мнение имеет. Очередной бред от "телепата", который почему-то решил, что он знает, кто что в глаза видел. >> А по ОЗУ -- 0 байт в свопе, 780 Мб физики свободно. >> KDE. > Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами. Вызови себе психиатра, если твои ряды косит шиза. Свежезагруженные кеды + Firefox на стандартных 4 ГБ ОЗУ. >> 1. Сквозную проверку целостности данных. >> 2. copies=3 на домашнюю директорию. > Ты так говоришь как будто это не делается в btrfs :) Нет, не делается. Поизучай внутреннюю структуру BtrFS. >> Для ноута самое то. > Странно что мсье не пришло в бошку использовать для начала хотя-бы снапшоты. > Чтобы в случае если что-то пошло не так - иметь возможность отмотать назад > за несколько секунд. Ты, по-моему, не понимаешь, от чего защищают снапшоты, а от чего -- copies. Это про разное.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	202. "Проект CoreOS рассматривает возможность ухода от использован..."	+3 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:42
	> Throughput 951.964 MB/sec 4 procs Круто, к сферическим мегабайтам памяти в вакууме добавился сферический почти гиг в вакууме. > На ноутбучном харде. Мне хватает гигабайта в секунду пока. :) Единственная заковывка - ноутбучный хард даже на уровне физики с такой скоростью не пишет. Что показывает что нам втирают очки. Показывая какой-нибудь cache hit, для которого гиг в секунду - не больно то и дофига. Глядя на такой ...дец - прямо хоть квест-комикс в формате ace attorney делай, с делом zfs vs btrfs :). Наверное могло бы получиться довольно эпично, в свете неаккуратных заявлений. > Очередной бред от "телепата", который почему-то решил, что он знает, кто что в глаза видел. Это заметно по уровню понимания работы ФС. Если видел - ну ок, тем хуже - тогда обнаружено махровейшее ламерство. Тоже вариант :) >> Шиза косила наши ряды - сферические 780 мегов в вакууме. С кедами. > Вызови себе психиатра, если твои ряды косит шиза. Так это не я шизанулся - писать про какие-то 768 мегов, без указания конфиги и почему-то мнить что это очень хорошо. > Свежезагруженные кеды + Firefox на стандартных 4 ГБ ОЗУ. Осталось уточнить про то что если всю память при этом скушать приложениями - мы явно не получим тех 954 Мб в секунду. Особенно на ноутбучном диске. Кого вы пытаетесь на..ть? Меня? А зачем? Я более-менее понимаю как это работает и такой номер не пройдет. Себя? Это вообще бессмысленно и беспощадно. Правда жизни - в том что дизайн ZFS без подпирания гигазами рамы тормознут. Я не вижу с фига ли этому странному блочному дизайну быть быстрым. А если эти гигазы выкроить - совсем не факт что их потом при нужде сможет забрать ядро когда это понадобится программам, потому что все это живет вообще отдельно от управления памятью ядра. Еще веселее CoW без дефрагера. Не, ну если диски вовремя дотыкать в пул - в продакшновом пуле можно и избежать крутого штопора. Но на ноуте новые диски втыкать некуда - придется трястись как кощею над местом на диске. Ведь если оно начнет зашкаливать за 70% - аллокатор наделает вермишели, а линеризовать эти макароны потом не выйдет - за отсутствием дефрага. Предел мечтаний дисковых технологий, блин. > Нет, не делается. Поизучай внутреннюю структуру BtrFS. Поизучал. Да, на 1-дисковой конфиге влобовую пока с этим будет сложновато. Можно придумать костыли, но будет менее эстетично. А сколько копий метаданных твой zfs при этом хранит? А то упор на число копий данных без числа копий метаданных наводит меня на некие подозрения... Что скажете, маэстро? > Ты, по-моему, не понимаешь, от чего защищают снапшоты, а от чего -- copies. Я прекрасно понял о чем вы и даже согласен что в случае 1-дисковой конфиги ноута это не так уж плохо, хоть я вижу всего 1 реалистичный сценарий отказа в котором это может помочь - если вылезло несколько бэдов. И то - вероятность что попортятся ценные файлы в /home не особо большая, а как ZFS реагирует на бэды на лисяре уже было, с хексэдитором :). А тут мне странно то, что про снапшоты не было упомянуто. Ибо тройное копирование не спасет от лажи по типу rm -rf /home/username /somedir. И это как-то сильно более вероятно чем какое-нибудь вылезание бэдов точно под ценными файлами хомяка. > Это про разное. Спасибо, Кэп.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	128. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Куяврег on 21-Дек-14, 16:12
	>> ZFS по скорости работы просто не с чем сравнивать. > Изен уже показал нам чего можно получить в ZFS :) "Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%" http://www.opennet.me/openforum/vsluhforumID3/100963.html#2 У вас, аптгетчиков как всегда - для ZFS другая линейка?
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	201. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:05
	> "Никакие ухищрения с ФС не помогут, если юзер допускает заполнение диска на 100%" > http://www.opennet.me/openforum/vsluhforumID3/100963.html#2 > У вас, аптгетчиков как всегда - для ZFS другая линейка? Странно, мне показалось что это бсдшные кулсисопы поливают btrfs за плохую работу в таком режиме, при этом старательно верещя что на ZFS так ни-ни. При том btrfs после такого еще можно отколупать с асфальта производительности дефрагером, если надо. А в ZFS дефрагера нету - есть только 1 метод: разобрать такой пул на...й или удвинуть с него все данные, что примерно одно и то же по смыслу.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	236. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Куяврег on 25-Янв-15, 13:09
	> Странно, мне показалось что это бсдшные кулсисопы поливают btrfs за плохую работу именно поэтому в темы про фряху набигают звёзды аптгета районного масштаба? вообще подсказываю: отказ от наркотиков сильно сократит количество показавшегося.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	109. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 11:48
	>> ЧЯДНТ? > - Не следишь за используемыми ресурсами и/или не заботишься о скорости работы 1ГБ ОЗУ для вращения З-пула. Скорость у снэпшотных фс по любому ниже экстентных. > - Не думаешь о людях, у которых 32bit система Согласен, ибо в мире х86 они не нужны. > - Скорее всего (но это ты расскажи) не используешь zfs на рутовой Корень в сквэше, находящимся в ОЗУ. Файл ЗФС-блоба включен в образ, ибо необходим для старта пула. > партиции (точнее на той, на которой /boot), или лишний раз усложняешь > себе жизнь не получая профита, или поведай какие уникальные фичи zfs > ты используешь? Снэпшоты. А других усложнений там намного больше.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	112. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 13:48
	> 1ГБ ОЗУ для вращения З-пула. Скорость у снэпшотных фс по любому ниже экстентных. yolo, снапшоты и экстенты - разные вещи. Экстенты - всего лишь компактные записи, адресующие большие регионы. Что в большинстве случаев оказывается эффективнее чем если бы регион метился поблочно (что требует дофига метаданных для описания большого региона). В ZFS сделали некое недоразумение с блоками переменного размера. Получив сложность устройства на уровне близкому к экстентам, но не получив при этом производительности файлух которые могут многомеговые регионы оформлять в один присест. Зачем оно вот так - никто внятно рассказать не может, саночный маркетинговый булшит этот момент тактично упускает :). А снапшоты - всего лишь состояния ФС в тот или иной момент времени. Btrfs умеет нормальные экстенты и при этом самые разнообразные действия со снапшотами. Одно другому не мешает. И кстати CoW на записи может быть очень быстрый, почти как нежурналируемая ФС. При свойствах близких к полному журналированию данных и метаданных. > Корень в сквэше, находящимся в ОЗУ. Файл ЗФС-блоба включен в образ, ибо > необходим для старта пула. Мсье знает толк в извращениях.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	137. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 21-Дек-14, 18:01
	> В ZFS сделали некое недоразумение с блоками переменного размера. Получив сложность устройства > на уровне близкому к экстентам, но не получив при этом производительности > файлух которые могут многомеговые регионы оформлять в один присест. Зачем оно > вот так - никто внятно рассказать не может, саночный маркетинговый булшит > этот момент тактично упускает :). Ну ты-то лучше Джефа Бонвика разбираешься в устройстве ZFS. Тебе явно верить можно, а разработчику нет доверия никакого. ;)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	143. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 21-Дек-14, 18:23
	Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь", почему же тогда от тебя этот "аргумент" должен что-то значить? Зыж 2аноним: > саночный маркетинговый булшит этот момент тактично упускает :). Почему же? Ещё при Джонатане Шварце они честно признались, что обобсались и решили вопрос в стиле традиционных фс (чтобы не вылезать за сроки).
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	155. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 21:28
	> Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь" Верить Мэйсону резона уже нет никакого. Он облажался по полной. На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые углы в виде введения опций принудительного отката последних транзакций  и рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так никуда и не слез с тестовых сетапов. Epic fail, как говорится.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	156. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от EHLO on 21-Дек-14, 22:01
	>> Ну вот Мэйсону ты регулярно в новостях про бтр "не веришь" > Верить Мэйсону резона уже нет никакого. Он облажался по полной. > На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые > углы в виде введения опций принудительного отката последних транзакций  и > рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так никуда > и не слез с тестовых сетапов. Epic fail, как говорится. За 8 лет копипасты WAFL так и не поняли, что копировали СХД, а не ФС общего назначения. Ага, эпично.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	167. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 02:14
	> копировали СХД Я так понимаю, это комплимент авторам ZFS. Делали FS, а получилась СХД! :-) > 8 лет копипасты WAFL Там не просто копипаста, а с творческими доработками. RAID-Z супротив WAFL-овского варианта RAID-4 имеет как и плюсы - в виде размазанного checksum, так и минусы в виде невозможности легко менять формат райда. Применение MFU-кеша тоже является хорошим ново?введением. Ну и так далее можно продолжать. > Ага, эпично. Эпичны те товарищи, у которых чувство NIH-а заставило игнорировать шишки NetUP-а и Sun-а и пилить свой кукольный театр со своими черепахами тортилами. Результаты 8-ми лет разработки мы все видим в топике.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	168. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от EHLO on 22-Дек-14, 03:45
	> Там не просто копипаста, а с творческими доработками. RAID-Z супротив WAFL-овского варианта > RAID-4 имеет как и плюсы - в виде размазанного checksum, так > и минусы в виде невозможности легко менять формат райда. Применение MFU-кеша > тоже является хорошим ново?введением. Ну и так далее можно продолжать. _Допустим_ как СХД для бедных сойдет, в конце концов сервер с терабайтом DDR3 сейчас наверно многие могут себе позволить. Но как там в ZFS с масштабированием и распределенным хранением, с кластеризацией в целом? > Результаты 8-ми лет разработки мы все видим в топике. Так пишешь, как будто у ZFS нет перечисленных проблем с переполнением, падением производительности и странными багами. Кстати, даже если допустить полное отсутствие проблем, ZFS по определению не подходит под топиковый юзкейс по причине жора памяти под кэши.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	206. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:52
	> производительности и странными багами. На лисяре можно найти приключения перца после вылезания пары бэдов на харде. Он там так rock stable хардкорил в хексэдиторе... :)
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	212. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от iZEN (ok) on 22-Дек-14, 17:19
	///---http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ Был RAID-Z-пул собранный из трёх дисков по 1.5 Тб фирмы X, модели Y. Работал он работал, и изредка стали появляться в логах сообщения о том, что произошла ошибка чтения или ошибка записи на один из дисков пула. ZFS, ругаясь в логи на ошибки контрольных сумм, отлично отрабатывала такие моменты и пул продолжал нормально функционировать со статусом "ONLINE". Ошибки повторялись, но были не систематичными: различные диски, различные сектора, различное время. Назвав ошибки идиопатическими (неизвестной природы) решил, что обязательно разберусь с ними, но не сейчас. Эпик фейл подкрался незаметно, но всё же наступил. В один, не самый удачный момент, после перезагрузки, файловая система не cмонтировалась. ... Год спустя Ещё весной задал на форуме вопрос о поддержке "отмотки" транзакций. И был направлен тов. Anon Y Mous на путь истинный, т.е. в последние (на тот момент) правки HEAD-ветки. Немного покопавшись в репозитории, нашёл нужную правку[3], в которой была добавлена поддержка той самой "отмотки" транзакций. Но это всё предисловие. После обновления, в правке за номером 219089 [3], ZFS до версии 28, в zpool(8) появилась возможность откатываться на несколько транзакций назад при передаче параметра -F. Так что описанный в статье приём восстановления стал обычной рутинной задачей. За подробностями по ссылке на правку или в подсказку, выводимую zpool(8). ---///
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	225. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 24-Дек-14, 00:51
	Изя, мне это можно и не пересказывать - я более менее уловил смысл того фикса. А если бэды порушат что-то еще - тогда, таки, хексэдитор? :) > И был направлен тов. Anon Y Mous на путь истинный, Удачи вам с вашим комьюнити. Где ламероватые кадры даже центось от кореоси не отличают, хотя это фундаментально разные дистры :)
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	174. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 22-Дек-14, 08:02
	> На 8-й год жизни в соляре ZFS была rock-stable На 8 год жизни соляра как была подстилкой под субд оракл, так только ей (особенно после покупки) и осталась. И под субд оракл zfs как не рекомендовалась, так и не рекомедуется. Прям как бтрфс в линухе (которую оракл также поддерживает в своём унбрикэбл линухе)
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	207. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:54
	> И под субд оракл zfs как не рекомендовалась, так и не рекомедуется. Потому что ее CoW ораклу только мешается, а отключить - никак. Думаешь с фига ли Мэйсон сделал отключение CoW в btrfs даже пофайлово? Не надо быть крутым телепатом чтобы догадаться кто его об этом попросил и почему.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	204. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:49
	> Верить Мэйсону резона уже нет никакого. Он облажался по полной. Ну а шайка Бонвик и Ко которые невнятно мямлят на вопросы почему они так странно сдлали блоки - это ничего, сойдет? И что у нас там насчет маркетингового булшита что CoW не надо дефрагер? А может они скажут что-то ценное про изъятие дисков из пула? Или про улучшение жизни файлов БД и виртуалок, которым CoW имеет свойство мешать жить в ряде ситуаций? > На 8-й год жизни в соляре ZFS была rock-stable, добивала последние острые > углы в виде введения опций принудительного отката последних транзакций Это в смысле когда перец на лисяре заметил что после нескольких бэдов на харде файлуха встала в позу и ее штатными тулзами - вообще никак? И надо хэксэдитором номер транзакции подделывать? Интерсное понимание rock stable. > и рассматривалась как безальтернативная. На 8-й год жизни btrfs-а он так > никуда и не слез с тестовых сетапов. Epic fail, как говорится. Цыплят по осени считают :).
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	203. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:45
	> Ну ты-то лучше Джефа Бонвика разбираешься в устройстве ZFS. А чего там разбираться? Слепили как умели. Получилось нечто. Местами довольно странное и не сказать что сильно оптимально сделанное. Как-то конечно работает. Если 100500 гигз оперативы подпереть и другие программы на эти гигазы претендовать не будут. > Тебе явно верить можно, а разработчику нет доверия никакого. ;) А разработчик лицо заинтересованное, особенно когда работает в коммерческой компании льющей со своего сайта ведра маркетингового булшита.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

32. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
Сообщение от Нанобот (ok) on 20-Дек-14, 17:41
связка из двух, взаимоподпирающих ФС - как-то это криво
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 19:04
	> связка из двух, взаимоподпирающих ФС - как-то это криво Это же Linux way!
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	99. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:14
	> Это же Linux way! А bsd way - сделать музейный экспонат и поставить на полочку...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	205. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 16:50
	> Это же Linux way! Sun way: компенсирвать технические проблемы громким маркетинговым булшитом.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

39. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
Сообщение от Аноним (??) on 20-Дек-14, 19:26
Использую btrfs уже 4 года на десктопе, и 2 года на файловых и веб серверах, за всё время ФС ни разу не упала, тормозов с ядра 3.14.1 вообще не видел, надо просто думать головой, ставить на её таблицу разделов, и выбирать под задачи компрессию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Проект CoreOS рассматривает возможность ухода от использован..."	–3 +/–
	Сообщение от Аноним (??) on 20-Дек-14, 19:31
	Как всегда в Linux: "тщательно обработайте напильником перед использованием".
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	42. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от а on 20-Дек-14, 20:05
	> Как всегда в Linux: "тщательно обработайте напильником перед использованием". рассуждения гамбургероеда
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

64. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
Сообщение от Ilya Indigo (ok) on 20-Дек-14, 23:42
Ну а почему нельзя просто продолжать использовать ext4 как и раньше?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	77. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 00:19
	> Ну а почему нельзя просто продолжать использовать ext4 как и раньше? Можно. Используйте. Я разрешил.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

73. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
Сообщение от Аноним (??) on 21-Дек-14, 00:18
btrfs - ужасная файловая система. Ее присутствие в ядре вообще загадка...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	85. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 21-Дек-14, 01:35
	Взятка Торвальдсу за зонд отдали...
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	101. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 05:21
	> Взятка Торвальдсу за зонд отдали... Пользователей putty.exe всегда так волнуют проблемы Linux... :)
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	105. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 09:46
	Это не отменяет того, что включение в ванилу было исключительно политическим (наш ответ zfs), как и не включение reiser4
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	113. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 13:50
	> Это не отменяет того, что включение в ванилу было исключительно политическим (наш > ответ zfs), как и не включение reiser4 Btrfs на момент включения хоть как-то работал и там была какая никакая команда разработчиков. А рейзер не только сырой, но и без внятной команды которая бы его допилить могла. И нет, в майнлайне не приветствуют откровенное решение чужих проблем (в том числе с руками) за их счет.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	152. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 21:14
	> команда разработчиков. А рейзер не только сырой, но и без внятной > команды которая бы его допилить могла. И нет, в майнлайне не > приветствуют откровенное решение чужих проблем (в том числе с руками) за > их счет. Все из себя "внятные" команды разработчиков только дерьмо пихают, а хорошую файловую систему по умолчанию им никто не предложит. Давно уже пора понять.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	208. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 17:06
	> Все из себя "внятные" команды разработчиков только дерьмо пихают, а хорошую файловую > систему по умолчанию им никто не предложит. Давно уже пора понять. А лично я посмотрев на архитектуру btrfs я склонен посчитать что его включили не зря - Мэйсон явно целился и в разные юзкейсы, и в всякие перспективные сценарии администрирования с нулевым даунтаймом и возможностью все переиграть прямо по ходу пьесы. Несомненно, любое решение несет как плюсы так и минусы. И btrfs в этом ничем таким не особенный. Но в целом лично мне многие тамошние идеи нравятся. И я по крайней мере понимаю "а зачем вот тут вот это делали вот так".
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	219. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Прохожий (??) on 23-Дек-14, 00:44
	Когда говорил, что "btrfs - ужасная файловай система" речь шла как раз о ее реализации.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	226. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Аноним (??) on 24-Дек-14, 01:03
	> Когда говорил, что "btrfs - ужасная файловай система" речь шла как раз > о ее реализации. У рейзера с реализацией все намного запущеннее и там для начала нет нормальной команды разработчиков. Шишкин который иногда анонсирует как рейзер героически портирован на новое ядро - это круто. А в майнлайне это надо в реалтайме, с релизом раз в 2-3 месяца. С утрясанием своего кода с кодом соседей по цеху. У Мэйсона на это ресурсы так или иначе найдутся. А вот у Шишкина - врядли. А получать порцию проблем на свои головы в майнлайне не любят. Конечно тех кто завалил майнтенанс могут выпереть и из майнлайна, по ходу пьесы, но обычно предпочитают работать с упреждением: если понятно что с майнтенансом не справятся, т.к. сложившейся команды нет - отфутболят еще на подлете. Никому не надо порцию головняка. А попадание в майнлайн - привилегия а не право.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	229. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 25-Дек-14, 15:49
	> А вот у Шишкина - врядли. А получать порцию проблем на > свои головы в майнлайне не любят.... > порцию головняка. А попадание в майнлайн - привилегия а не право. Скажу тебе по секрету: btrfs - самая большая проблема, которую "кернел-боги" поимели за всю свою историю, и теперь не знают, что им делать с огромной оравой юзеров и "разработчиков", обманутых двумя евреями Мейсоном и Бэсиком.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	230. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Led (ok) on 25-Дек-14, 22:11
	> Скажу тебе по секрету Разве у дятлов бывают секреты?
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	231. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
	Сообщение от Аноним (??) on 26-Дек-14, 17:22
	>> Скажу тебе по секрету > Разве у дятлов бывают секреты? Ну, у кернел-разработчиков есть инфа "для публики", и есть "не для публики".
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	235. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 26-Дек-14, 18:22
	> Ну, у кернел-разработчиков есть инфа "для публики", и есть "не для публики". У них есть LKML, он и для публики и не для публики. Сугубо вопрос интересов того или иного представителя публики. Бывают мыллисты проектов/подсистем. Для них верно то же самое. А сказки про вселенские заговоры в LKML оставьте для бабушек на скамейке.
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	234. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 26-Дек-14, 18:18
	> Скажу тебе по секрету: btrfs - самая большая проблема, которую "кернел-боги" поимели > за всю свою историю, Нет никакого смысла мне врать. Reason: я читаю списки рассылки касающиеся линуксного ядра и его подсистем. Поэтому единственное что вы можете достичь таким манером - выставить себя гнусным лжецом. И да, я видел и некоторые нарекания. И похвальбы. А в целом - нормальный рабочий процесс. Не хуже и не лучше остальных подсистем. > двумя евреями Мейсоном и Бэсиком. Во первых, если уж на то пошло, евреи как правило умные (по поводу чего и оставляют всяких простофиль в дypaках, за что простофили их предскауемо не любят). А в таких вопросах, определенно, мощный мозг, а лучше несколько - самое оно. Во вторых, а вон те япы из фуджика и китайцы из оракла в курсе что они оказывается тоже евреи? :)
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	106. "Проект CoreOS рассматривает возможность ухода от использован..."	+2 +/–
	Сообщение от Xasd (ok) on 21-Дек-14, 10:18
	> btrfs - ужасная файловая система. Ее присутствие в ядре вообще загадка... BTRFS в ядре, так как если бы её там не было бы -- то ни кто бы BTRFS (в серьез) не использовал бы. только такие дурачки как "пользователи ZFS на Linux" -- позволяли бы себе заиспользовать бы BTRFS (если бы BTRFS ядре не было бы). разгадка проста: в Linux-системах -- не удобно (и не надёжно) использовать те файловые системы которые требуют для своей работы кустарный патчинг ядра. вот именно поэтому -- BTRFS присутствует в ядре (как модуль). и всегда готово к выполнению своей сложной работы!
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	151. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-14, 20:57
	Тебе надо "заиспользовать" матчасть про проблему "курицы и яйца"
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	175. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
	Сообщение от Xasd (ok) on 22-Дек-14, 08:09
	это ты намекаешь про initramfs или что?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

176. "Проект CoreOS рассматривает возможность ухода от использован..."	–1 +/–
Сообщение от Аноним (??) on 22-Дек-14, 08:10
Зачем они хотят это сделать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	178. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от ананим on 22-Дек-14, 08:16
	им нужна контейнерная изоляция. желательно с расходованием как можно меньше ресурсов цпу на это. так что вполне логично.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	179. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Аноним (??) on 22-Дек-14, 09:00
	https://coreos.com/about/ "Наша команда состоит из системы экспертов и выпускников из следующих организаций: SUSE и ещё 7 штук." http://www.opennet.me/opennews/art.shtml?num=40947 "В тестовом выпуске ядра Linux 3.18-rc2 появилась поддержка файловой системы OverlayFS, разработанной компанией SUSE в качестве более прогрессивной замены UnionFS и AUFS." Недостающий элемент найден.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

194. "Проект CoreOS рассматривает возможность ухода от использован..."	–2 +/–
Сообщение от клоун СтаканчикЪ on 22-Дек-14, 13:54
Клоун говорит: "от г-вна г-вна не ищут."
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	209. "Проект CoreOS рассматривает возможность ухода от использован..."	+1 +/–
	Сообщение от Аноним (??) on 22-Дек-14, 17:07
	> Клоун говорит: "от г-вна г-вна не ищут." У клоуна сегодня приступы самокритики.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	210. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Crazy Alex (ok) on 22-Дек-14, 17:09
	Он самокритичен
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	217. "Проект CoreOS рассматривает возможность ухода от использован..."	+/–
	Сообщение от Led (ok) on 22-Дек-14, 22:15
	> Клоун говорит: "от г-вна г-вна не ищут." Это ты так просишь, чтобы тебя не банили?
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

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

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