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

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

"Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Linux"	+/–
Сообщение от opennews (??) on 18-Авг-12, 10:27
Доступен (https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...) новый экспериментальный выпуск  модуля для ядра Linux с поддержкой ZFS - zfsonlinux 0.6.0-rc10 (http://zfsonlinux.org/). Несмотря на официальный статус экспериментальной разработки, пакет ZFSonLinux уже достаточно стабилен для использования энтузиастами. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo и Sabayon Linux, а версия пула и FS в ZFS совместима с FreeBSD 9.0 и 8.3. В процессе подготовки новой версии продолжено портирование компонентов ZFS из проекта Illumos, в рамках которого создано полностью свободное и развиваемое независимым сообществом ответвление от кодовой базы OpenSolaris. Например, добавлена поддержка свойств "clones", "written" и "written@...", добавлена команда "zpool reguid". Кроме того, добавлена поддержка ядра Linux 3.5 и обеспечена возможность автоматизации сборки модулей для ядра Linux при помощи системы DKMS. URL: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups... Новость: http://www.opennet.me/opennews/art.shtml?num=34603
Ответить | Правка | Cообщить модератору

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

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

1. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
Сообщение от Аноним (??) on 18-Авг-12, 10:27
Неужели никому zfs не нужна что её полтора энтузиаста пилят?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+3 +/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 10:44
	В целом так оно и есть. Слишком нишевая FS.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 10:53
	ликбеза ради, расскажите или скиньте урл, где её основное применение и почему?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	8. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+5 +/–
	Сообщение от iCat (ok) on 18-Авг-12, 11:42
	Лично я использую ZFS на корпоративном сетевом хранилище на базе дистрибутива NexentaStor Для меня "киллер-фичи": - очень удобные снапшоты - дедупликация - высокая надёжность ZFSonLinux использую для работы с ZFS-дисками на рабочей станции. Например - если нужно вытянуть данные с прошлогоднего диска.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	59. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–3 +/–
	Сообщение от pavlinux (ok) on 20-Авг-12, 02:58
	> - высокая надёжность Если у тебя ещё ничего не сломалось, это не значит, что это работает. Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	65. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от deadless (ok) on 20-Авг-12, 09:35
	павлин, вставь пальцы в розетку, если один раз не поможет, можешь повторить раз 20... посмотрим насколько ты у нас надежный, или просто п......л
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	74. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Авг-12, 21:14
	> павлин, вставь пальцы в розетку, если один раз не поможет, можешь повторить > раз 20... посмотрим насколько ты у нас надежный, или просто п......л Да ладно тебе, нормальный стресстест на глючность и выживаемость. У хороших конструкций - пятикратный запас прочности :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	101. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 20:41
	>> - высокая надёжность > Если у тебя ещё ничего не сломалось, это не значит, что это > работает. > Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим. ты не поверишь - живет, и живет еще и не при таких чудесах (raidz, 3-и диска): глючил контроллер, причем начал это делать, в момент, когда 1Т диски в массиве стал заменять на 3Т диски, высыпались то один, то другой, а то и третий диски из системы, вечные таймауты от дисков, не возможность записать/прочитать с рандомного диска, висла система, саморебуталась, и так в течении месяца, в конце еще вставили в новый контроллер два из трех дисков и один из этих двух дисков уже как дня три был не в массиве из-за очередной порции таймаутов, в итоге зфс выжил, все данные переехали на 3Т диски и расширилось хранилище. За все это время (пока думал, что причиной диски и менял на другие, затем корзинки со шнурками и только потом уже контроллер), из 11млн существующих инодов было потеряно два файла.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	221. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:07
	>> - высокая надёжность > Если у тебя ещё ничего не сломалось, это не значит, что это > работает. Это вы про EXT4 ? > Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим. UFS2 S+J ради эксперимента уже наверно 40 ребутов ...
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	13. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 12:45
	> ликбеза ради, расскажите или скиньте урл, где её основное применение и почему? Виртуализация, VCS, некоторые файлопомойки. Усё. Погуглите на тему CoW - поймёте, почему оно плохо в других условиях.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	26. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+3 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:55
	> Виртуализация, У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. Может не обязательно так эпично ламерить? > VCS, Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожее по смыслу делает еще и ФС, получается двойная работа, вам так не кажется? > некоторые файлопомойки. В случае ZFS только некритичные к скорости и малоактивные - дефрагера нету. > Усё. Погуглите на тему CoW - поймёте, почему оно плохо в других условиях. Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо и почему. Навскидку - базам данных это может быть не подарок без пересмотра журнальной логики оных. Ну и все вроде как.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	29. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 15:00
	> У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. Обычно - это где, поконкретнее. Да еще и с CoW. Расскажите-ка. >> VCS, > Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожее Вы под VCS подразумеваете только то, что можно в сети скачать? > Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо Практически для любых - гиперфрагментация. В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	75. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Авг-12, 21:25
	> Обычно - это где, поконкретнее. Да еще и с CoW. Расскажите-ка. Практически у всех виртуализаторов умеющих снапшоты это сделано как тот или иной вид технологии основанной на CoW. Например: qcow/qcow2 в qemu/kvm. Как бы название формата прозрачно намекает. Ну и легион других. А по другому логика множественного снапшотирования не очень то и получается в нормальном виде. >>> VCS, >> Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожее > Вы под VCS подразумеваете только то, что можно в сети скачать? Я под VCS понимаю системы контроля версий. >> Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо > Практически для любых - гиперфрагментация. Во первых, если записи мало + есть дефрагер, это проблемой не будет. Во вторых, это tradeoff. Взамен ФС позволяет писать новые метаданные и данные только 1 раз, а не 2 - избавившись от отдельной фазы журналирования. Ну и на набирающих популярность SSD этот фактор менее критичен. > В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет. При интенсивной записи - с лихвой окупится: в лучшем случае будет скорость записи как у нежурналируемой ФС + надежность полностью журналируемой, чего журналирующим в общем случае не светит из-за двойной записи. Правда у именно ZFS дизайн с биением на блоки без крупных экстентов - тормознутый, да. Но в btrfs это учли. У них и garbage collector с дефрагером совместили, что логично. И экстенты поюзали по полной программе. По поводу чего оно и делает ZFS в куче бенчей. А сам ZFS штука на любителя. Ну вон iZEN живет с 6мб/сек с диска. Потому что забил тома в хламину и CoW совсем зашился :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	80. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 20-Авг-12, 22:44
	> Практически у всех виртуализаторов умеющих снапшоты это сделано как тот или иной > вид технологии основанной на CoW. Это сделано обычно, как навесной механизм. Единственная более-менее известная среда, умеющая действительно CoW FS - это Parallels Virtuozzo. > Я под VCS понимаю системы контроля версий. У меня есть система контроля версий конфигов оборудования, построенная - сюрпрайз - на обычных файлах. В качестве бэкбона используется GIT. Как только допилят BTRFS - начну использовать BTRFS, ибо зачем городить огород. > Во первых, если записи мало + есть дефрагер, это проблемой не будет. У ZFS есть дефрагер? (shocked!) > Во вторых, это tradeoff. О чём и речь. И этот трейдоф на большинстве требовательных к диску ворклоадов приведет к граблям. Исключение - места, где действительно светит (shines) дедупликация. Или ворклоады, нетребовательные к диску. >> В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет. > При интенсивной записи - с лихвой окупится Геммороем при чтении. А плюсы будут разве что если регулярно писать и удалять тысячи файлов объёмом в кластер (чтобы хоть как-то заметить разницу в скорости записи от метаданных).
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	98. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 21-Авг-12, 15:59
	>> Во первых, если записи мало + есть дефрагер, это проблемой не будет. > У ZFS есть дефрагер? (shocked!) "Онлайновый-при-записи", если только. Про фоновую "дефрагментацию" на ZFS лично мне неизвестно. В ZFS ведётся учёт и работа только с занятым пространством, а незанятое пространство как чистый лист для неё — логически "неотформатировано". При записи новых данных используется алгоритм оптимизации размещения данных с подбором размера блока (по умолчанию размер блока 128k). При чтении часто запрашиваемые данные всё равно помещаются в ARC-кэш в оперативной памяти, поэтому с ZFS можно жить и работать с трафиком 5МБ/с между RAM и HDD. Это весьма нетребовательная к пропускной способности носителей файловая система, задержки возникают только при первом обращении к запрашиваемым данным. Отсюда и требование к объёму ОЗУ.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	104. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 21:30
	А если не мучать бабушку, и вместо ARC использовать системный кеш - эффективность тоже вырастет. Но архитектура ZFS не позволит.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	127. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 17:01
	> "Онлайновый-при-записи", если только. Тебе в маркетологи надо идти. Так изящно вильнуть попой в процессе рассказа про что дефрагера нет может не каждый :D > Про фоновую "дефрагментацию" на ZFS лично мне неизвестно. Потому что ее там нет. А ты так и будешь наслаждаться 6мб/сек с диска. Даже если расчистишь засёр и станет больше свободного места, скорость не улучшится особо.   > В ZFS ведётся учёт и работа только с занятым пространством, а незанятое > пространство как чистый лист для неё — логически "неотформатировано". Неандерталец рассказывает принцип действия микроволновки - "нажимаешь на кнопку, она жужжит и зажигается лампочка, потом она пищит и вот уже у вас готовая еда". :D > При записи новых данных используется алгоритм оптимизации размещения данных > с подбором размера блока (по умолчанию размер блока 128k). А в нормальных ФС уж сто лет как используют полноценные экстенты. Позволяющие одной записью в метаданные заадресовать весь регион нужного размера или по крайней мере весьма существенную его часть. Что явно быстрее в ряде случаев. > При чтении часто запрашиваемые данные всё > равно помещаются в ARC-кэш в оперативной памяти, Да, да, поскольку у него тормозной блочный аллокатор, надо дофига оперативки чтобы хоть как-то скомпенсировать унылое тормозилово которое может получиться в ряде ворклоадов :) > поэтому с ZFS можно жить и работать с трафиком 5МБ/с между RAM и HDD. Кэп намекает что 5Мб/сек - это вообще феерическая тормознутость для жесткого диска. Даже ноутбучного. > Это весьма нетребовательная к пропускной способности носителей файловая система, А если жесткий диск совсем выбросить и все на рамдиске хранить - вот это будет скорость! Правда ZFS там вообще лишним получается, а рамдиск более чем на несколько гигз - дорого :-) > задержки возникают только при первом обращении к запрашиваемым данным. > Отсюда и требование к объёму ОЗУ. Ну так и запишем: тормозную работу ФС пытаюстя вытянуть нее...ческого размера кешом.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	107. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Авг-12, 13:04
	> Это сделано обычно, как навесной механизм. Надо же, до вас стало доползать. Вот именно поэтому и логично если эта механика будет в ФС. Там она может работать лучше. "Дома и стены помогают". > Единственная более-менее известная среда, умеющая > действительно CoW FS - это Parallels Virtuozzo. В виртуализаторах оно обычно делается на блочном уровне - уровне виртуального диска. Так универсальнее в том плане что виртуализатор вообще не знает какая там ФС у гуеста - ему наплевать. По поводу чего снапшоты в почти всех форматах виртуальных дисков - CoW. > на обычных файлах. В качестве бэкбона используется GIT. Как только допилят > BTRFS - начну использовать BTRFS, ибо зачем городить огород. В принципе звучит разумно, но кто там лучше будет работать - это еще вопрос. Git исходно оптимизился под версионирование кучи текстовой мелочи в основном. А файловая система общего назначения должна приемлимо работать и так и сяк, поэтому критерии оптимизации более другие чем у git (мало психов будут хранить 50Гб файлы в git, а в файловой системе - запросто). >> Во первых, если записи мало + есть дефрагер, это проблемой не будет. > У ZFS есть дефрагер? (shocked!) У btrfs есть. У zfs - нету. По поводу чего iZEN и будет теперь так и будет топырить пальцы с своими 6Мб/сек пока пул не разберет и пересоберет, ха-ха :) >> Во вторых, это tradeoff. > О чём и речь. И этот трейдоф на большинстве требовательных к диску > ворклоадов приведет к граблям. А вы что, статистику собирали по тому у кого какие ворклоады и кто и как на них себя ведет? Или как получено "большинство"? А то в целом - btrfs весьма прилично себя ведет на большинстве бенчей. Нет, у него есть слабые места, например скулайт: видимо двойная работа у тамошнего журнала совместно с CoW получается. Но на большинстве ворклоадов он не сильно проигрывает ext4 при не в пример более крутой фичности, полном журналировании, снапшотах и прочая. > Исключение - места, где действительно светит (shines) > дедупликация. Или ворклоады, нетребовательные к диску. Как бы на уровне дизайна btrfs совершенно не обязан тормозить. В отличие от упырей из сана эти по крайней мере осилили экстентное распределение. По поводу чего оно обставляет ZFS примерно как ext4 обставляет ext3, по тем же самым причинам. >> При интенсивной записи - с лихвой окупится > Геммороем при чтении. Зависит от того как и что читается и что и как писалось, ssd или hdd, etc. По поводу чего столь безаппеляционные заявки выглядят странно. У btrfs также есть дефрагер. В ZFS - ну да, дефрагера нету. Приветы изену :) > А плюсы будут разве что если регулярно писать и удалять тысячи файлов объёмом > в кластер (чтобы хоть как-то заметить разницу в скорости записи от метаданных). С чего бы ради? По идее удобным случаем является длинная непрерывная запись, например. Если честно журналить все - на этой операции все просядет немеряно. А если честно не журналить - так при крахе данные в отличие от метаданных могут оказаться в промежуточном состоянии. Вот редактировал я допустим PNG, а на середине записи все фигакнулось. По поводу чего в обычной ФС если не журналить данные, можно получить полфайла новых и полфайла старых. И оно потом на середине обломается прочесть остальное.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	222. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:10
	> Практически для любых - гиперфрагментация. Алекс вы опять все перепутали гиперфрагментация это на EXT4 а на ZFS при условии L2ARC она не оказывает влияния, проверено оператором сотовой связи, было в рассылке ...
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	60. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–4 +/–
	Сообщение от pavlinux (ok) on 20-Авг-12, 03:01
	>> Виртуализация, > У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. > Может не обязательно так эпично ламерить? Ламерок, а чёго от анонима-то пишем? Очкуешь лошара? kvm -drive .... -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]        [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]        [,cache=writethrough|writeback|none|unsafe][,format=f]        [,serial=s][,addr=A][,id=name][,aio=threads|native]        [,readonly=on|off]
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	76. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Авг-12, 21:27
	>> У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. >> Может не обязательно так эпично ламерить? > Ламерок, а чёго от анонима-то пишем? Очкуешь лошара? Ну если уж ты о KVM, там есть такие дисковые форматы - qcow и qcow2. Для виртуалок со снапшотами они и юзаются. По их названию несложно догадаться что внутрях там местечковый CoW хранит дельту относительно снапшота :)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	79. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от anonymousX on 20-Авг-12, 22:03
	>У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. Может не обязательно так эпично ламерить? У них с производительность, того, мягко говоря...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	117. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 21:49
	> У них с производительность, того, мягко говоря... Что - того? Производительность как производительность. Правда не при всех ворклоадах она хорошая. И вообще у "полных" виртуализаторов даже в тепличных условиях I/O в пару раз относительно железа проседать вполне себе умеет. Ну так я как-то и не знаю психов гоняющих нагруженные файлсервера в виртуалках. Каждому инструменту свое применение. Да, микроскопом неудобно вбивать гвозди. Но это не является его недостатком.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	18. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от filosofem (ok) on 18-Авг-12, 14:02
	>ликбеза ради, расскажите или скиньте урл, где её основное применение и почему? Файлопомойки и хранилища бэкапов с 64ГБ RAM и больше. Или как ФС общего назначения на BSD и Соярах, при условии не класть на нее базы данных и образы виртуалок и не жалко памяти.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	67. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от PnD (??) on 20-Авг-12, 11:36
	В стораджах для сохранения ооочень больших блобов с медленно меняющимся содержимым. Вот например: zp2   dedupratio     9.10x   А там - сотни гигабайт снапшотов с почтовых серверов (сотни миллионов файликов от imap), девятикратное сжатие получено для случая хранения снимков за 12 последних недель.   Таким макаром на терабайтный раздел непринужденно упихиваются 2-3 ТБ данных и еще больше половины свободно.   Понятно что, как любому архиватору, дедупликатору нужно немерено ОЗУ (порядка 5 ГБ на ТБ), что следует учитывать на этапе проектирования такого стораджа.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	4. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 10:54
	>Слишком нишевая FS. Ну ничего себе. Можно подумать контрольные суммы всего, снимки, изменения размера (точнее по сути отсутствие размера) не могут пригодится абсолютно везде кроме разве что дохленьких встраиваемых систем
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	10. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 18-Авг-12, 11:59
	>контрольные суммы всего киллер-фича. на десктопах точно. а остальное "снимки, изменения размер" и остальные умеют и даже на дохленьких встраиваемых систем
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	23. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+6 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:48
	> а остальное "снимки, изменения размер" и остальные умеют Да ежи тоже летать умеют. Просто низко. И пинать надо часто. Обычно всем лень. Поэтому ежи как правило и не летают. Но в принципе они летать умеют. Если пнуть посильнее.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	32. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–5 +/–
	Сообщение от ананим on 18-Авг-12, 15:31
	у зоофилов по идее свой ресурс должен быть. или вас оттуда попёрли. за разврат.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	77. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Авг-12, 21:34
	> у зоофилов по идее свой ресурс должен быть. > или вас оттуда попёрли. за разврат. Это был намек на то что к классике снапшоты конечно можно привинтить, но работать это будет примерно так же хорошо как ежи летают. Не, если переть на принцип - не вопрос, ежи летают, конечно. Только нафиг нужно такие "полеты".
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	33. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 16:38
	изменение размера в ext4 не так хорошо работает как хотелось бы. Уменьшение 1 раз привело к ошибкам (но вроде ничего не пропало) Отдельная радость доставляет связка lvm + ext4 которой проще все покоцать чем уменьшить размер
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	56. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от ананим on 19-Авг-12, 12:20
	возможно (у меня без проблем прошло). Но речь то не об этом - речь о том, что скорость, стабильность, не требовательность к ресурсам, которые нужны каждый день, каждый миг работы(!!!) всегда предпочтительней одноразовых операций. Как часто вы меняете размер раздела? Раз в день? Месяц? Год? Вообще не меняете?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	223. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:15
	>>контрольные суммы всего > киллер-фича. на десктопах точно. > а остальное "снимки, изменения размер" и остальные умеют и даже на дохленьких > встраиваемых систем Это вы про LVM снапшеты ? С их падением производительности раз так в 5 ? :))
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 12:44
	> Ну ничего себе. Можно подумать контрольные суммы всего, снимки, изменения размера (точнее > по сути отсутствие размера) не могут пригодится абсолютно везде кроме разве > что дохленьких встраиваемых систем Слишком высока цена за данный набор фич. Вообще CoW на дисках - это действительно очень нишевая фича, которая нужна разве что для VCS и виртуализации. В остальном стоимость CoW превышает пользу от оной.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	22. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:47
	>  остальном стоимость CoW превышает пользу от оной. А какая у него стоимость?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	30. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 15:01
	>>  остальном стоимость CoW превышает пользу от оной. > А какая у него стоимость? Много памяти, много перемещений голов. Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. Да и то не всегда, опять же - зависит от паттерна доступа.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	61. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от kshetragia (ok) on 20-Авг-12, 05:29
	Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже чем переписать весь файл? Даже при условии хорошего кэша в раме? Где-то есть поподробнее об этом?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	69. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 20-Авг-12, 11:52
	> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже > чем переписать весь файл? Даже при условии хорошего кэша в раме? > Где-то есть поподробнее об этом? Если хоть чуть-чуть включать голову - можно понять, что "кусочек" запишется далеко от остального контента файла. И при каждом чтении будет вызывать дрыганье голов. Когда содержимое файла меняется часто (типичный workload - база данных) - будет бардак.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	92. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от kshetragia (ok) on 21-Авг-12, 06:40
	Ну тогда у вас и цифры есть. Не поделитесь?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	96. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 07:15
	> Ну тогда у вас и цифры есть. Не поделитесь? КЭП подсказывает: создайте раздел на ZFS и проделайте указанную мной операцию. Потом посмотрите содержимое диска. И включите, наконец, мозг - какие тут цифры?
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	97. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от kshetragia (ok) on 21-Авг-12, 11:12
	Иногда вещи не то чем они кажутся. Цифрам я доверяю больше чем Кэпу. Тем более Кэпу от Линукса.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	100. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 16:32
	> Иногда вещи не то чем они кажутся. Цифрам я доверяю больше чем > Кэпу. Тем более Кэпу от Линукса. Возьмите, сделайте тесты у себя на платформе - будут вам цифры.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	118. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 21:53
	> Когда содержимое файла меняется часто (типичный workload - база данных) - будет бардак. Ну и какая разница где именно будет запись БД на диске? Ах, последовательное чтение просядет? Так это проблема только для овощей которые своей тупизной просаживают базу штуками типа SELECT * и прочими фокусами требующими лопатить всю огромную базу от забора и до обеда. А в нормальной ситуации - база всяко за парой записей куда-то seek-ать будет. Куда именно - не столь уж принципиально. По поводу чего не факт что оно вообще просядет.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	120. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Авг-12, 23:03
	> последовательное чтение просядет? Так это проблема только для овощей которые своей > тупизной просаживают базу штуками типа SELECT * и прочими фокусами требующими Индексы читаются достаточно большими блоками. И перезаписываются не просто часто, а очень часто. Индекс, ровным слоем размазанный по всему диску - страшнейший сон DBA.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	128. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 17:04
	> Индексы читаются достаточно большими блоками. И перезаписываются не просто часто, а очень > часто. Индекс, ровным слоем размазанный по всему диску - страшнейший сон DBA. И тем не менее, btrfs в частности нужен и ораклу. Под их базу. А если DBA не хватает квалификации подружить ФС и базу при том что рукоятки все дадены, что отключение CoW, что дефрагер онлайновый - кто ж виноват?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	136. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 18:57
	> И тем не менее, btrfs в частности нужен и ораклу. Под их > базу. А если DBA не хватает квалификации подружить ФС и базу > при том что рукоятки все дадены, что отключение CoW, что дефрагер > онлайновый - кто ж виноват? Вы сначала полистайте алгоритмы работы современных БД, потом уже делайте выводы. BTR ораклу нужна вряд ли под базу. Скорее - под виртуализацию. Либо просто под ОС.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	152. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:26
	> Вы сначала полистайте алгоритмы работы современных БД, потом уже делайте выводы. > BTR ораклу нужна вряд ли под базу. Скорее - под виртуализацию. Либо просто под ОС. У raw разделов есть проблема - их админить неудобно. Поэтому им нужна тонкая прослойка-ФС которую можно удобно подогнать под логику базы. Btrfs вполне сможет быть таковой.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	160. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 09:50
	> У raw разделов есть проблема - их админить неудобно. А ZVOL удобно админить. В них любую ФС можно отформатировать (кроме ZFS, собственно), а можно использовать как RAW. И при этом сохраняются все свойства ZFS для них (которые можно отключить или настроить), прикинь! > Поэтому им нужна > тонкая прослойка-ФС которую можно удобно подогнать под логику базы. Btrfs вполне > сможет быть таковой. Ну раз нужна ФС, то вперёд.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	166. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:18
	> А ZVOL удобно админить. В них любую ФС можно отформатировать (кроме ZFS, > собственно), а можно использовать как RAW. И при этом сохраняются все > свойства ZFS По получению лапши на диске. Причем в данном конкретном случае - аж с особым цинизмом, вплоть до лапшевания метаданных FS, которая записана на ZVOL. Это не RAW, это редкостное извращение над самой сутью использования RAW-разделов.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	199. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 21:32
	> собственно), а можно использовать как RAW. И при этом сохраняются все > свойства ZFS для них (которые можно отключить или настроить), прикинь! Все? А это включая упомянутую неподалеку фрагментацию от CoW? :) > Ну раз нужна ФС, то вперёд. Угумс, оракл и шлепает вперед. Вон уже поддержку btrfs у себя предлагают.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	224. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:18
	>> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже >> чем переписать весь файл? Даже при условии хорошего кэша в раме? >> Где-то есть поподробнее об этом? > Если хоть чуть-чуть включать голову - можно понять, что "кусочек" запишется далеко > от остального контента файла. И при каждом чтении будет вызывать дрыганье > голов. Когда содержимое файла меняется часто (типичный workload - база данных) > - будет бардак. А что EXT4 уже таки пишет файлы по надцать гигабайт непрерывным куском ? :)) Если хоть чуть-чуть включать голову то окажется что максимум 128М ?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	109. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 00:38
	> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже > чем переписать весь файл? Вообще-то, обычные ФС не перезаписывают "весь файл". А только измененный кусок. Просто старая часть файла во многих необратимо перетирается, тогда как CoW явно складывает только в сторонку.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	225. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:19
	>> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже >> чем переписать весь файл? > Вообще-то, обычные ФС не перезаписывают "весь файл". А только измененный кусок. Просто > старая часть файла во многих необратимо перетирается, тогда как CoW явно > складывает только в сторонку. Это касется исключительно того случая когда записываемый кусок равен куску на диске, если нужно вписать или стереть кусок в середине файла то придется перезаписывать весь хвост. А ниче если этот хвост несколько терабайт ?
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	227. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 04-Фев-13, 21:15
	> Это касется исключительно того случая когда записываемый кусок равен куску на диске, > если нужно вписать или стереть кусок в середине файла Тьфу-тьфу, такое извращение актуально только для коротеньких текстовых файлов.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	232. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:14
	>> Это касется исключительно того случая когда записываемый кусок равен куску на диске, >> если нужно вписать или стереть кусок в середине файла > Тьфу-тьфу, такое извращение актуально только для коротеньких текстовых файлов. Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое пространство заранее потому что фс неумели дописывать в серидину файла ... :)))
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	245. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 07:18
	> Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое > пространство заранее потому что фс неумели дописывать в серидину файла ... > :))) ну, если у тебя на ZFS приходится заранее место выделять - я тебе сочувствую. а так sparse-файлы никто не отменял
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	250. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 19:35
	>> Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое >> пространство заранее потому что фс неумели дописывать в серидину файла ... >> :))) > ну, если у тебя на ZFS приходится заранее место выделять - я > тебе сочувствую. а так sparse-файлы никто не отменял Алекс EXT4, ERT4 у вас что еще и склероз ?
	Ответить | Правка | ^ к родителю #245 | Наверх | Cообщить модератору

	78. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 20-Авг-12, 21:54
	>> А какая у него стоимость? > Много памяти, Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок и без немеряного дискового кеша тормозит - ну да. Так ext3 тоже слоупок на фоне ext4, если что. В btrfs это учли. Вообще, ничто не обязывает CoW сам по себе требовать много памяти или тормозить. > много перемещений голов. Сильно зависит от - там запись однократная: пишется только то что изменено. Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, а потом коммит того что в журнале на диск. Мало того что это в 2 раза дольше, так еще и журнал обычно в отдельной области от данных и головы полетят туда через весь диск. Тогда как btrfs например вообще может раскладывать данные как угодно. > Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. Не скажите. Один из основных козырей - технология имеет потенциал делать запись на диск со скоростью нежурналинуемой ФС при сохранении всех свойств полностью журналирующей. Что довольно здорово само по себе. А как бонус - снапшоты условно нахаляву получаются. > Да и то не всегда, опять же - зависит от паттерна доступа. А вот тут согласен на все 100%. И тем не менее в большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду не юзает в режиме полного журналирования.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	81. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 20-Авг-12, 22:51
	> Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт гиперфрагментации. А у ZFS еще одна проблема есть на этой ниве - ARC никак не взаимодействует с системным кешем, в итоге имеем двойное кеширование, отсутствие CoW в памяти / memory mapping из ARC - т.е. прямое копирование из ARC в кеш и назад, и в наихудших случаях - cache thrashing. Это при том, что линухи с традиционных ФС по возможности читают и отдают приложению данные вообще в zero-copy режиме, тупым маппингом страниц. И пишут в кеш в ряде случаев так же. >> много перемещений голов. > Сильно зависит от - там запись однократная: пишется только то что изменено. Ничего не зависит. Взяли файл размером в гиг. Переписали метр в середину (БД, к примеру). На традиционных FS блок встанет ровно туда, куда надо. А на CoW - вылететь может и в другую половину диска, и при последовательном чтении файла потом всегда будет весело. > Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, > а потом коммит того что в журнале на диск. Данные в традиционных FS обычно не журналируются - незачем. Если вдруг, и журнал начинает напрягать - его выносят на отдельный мелкий носитель (SSD). >> Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. > Не скажите. Один из основных козырей - технология имеет потенциал делать запись > на диск со скоростью нежурналинуемой ФС И потом иметь грабли при чтении размазанного ровным слоем по диску файла. А если исключить перезапись - т.е. писать файлы, и не менять - имеем как раз read-mostly паттерн. --- Вся эта идея CoW FS не нова. Я подобные алгоритмы видел еще в веарлевелерах на самсунговских флешах, допустим, в SGH-X100, лет шесть-семь тому назад. Их чуть-чуть проапгрейдить, и получится CoW FS. Для флеша - да, круто, там как раз то самое размазывание и интересно. Для механических дисков - грабельки.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	102. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 21-Авг-12, 21:14
	>> Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок > Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт > гиперфрагментации. > А у ZFS еще одна проблема есть на этой ниве - ARC > никак не взаимодействует с системным кешем, в итоге имеем двойное кеширование, > отсутствие CoW в памяти / memory mapping из ARC - т.е. > прямое копирование из ARC в кеш и назад, и в наихудших > случаях - cache thrashing. Правда что ли? Тогда зачем нужен динамический ARC и даже подключаемый при желании L2ARC на внешних носителях? Ведь они "никак не взаимодействуют с системным кэшем". :))
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	103. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 21:28
	> Правда что ли? Тогда зачем нужен динамический ARC и даже подключаемый при > желании L2ARC на внешних носителях? Ведь они "никак не взаимодействуют с > системным кэшем". :)) А теперь требуется перечитать еще раз, и понять. Проблема не в том, что ARC "не нужен". Проблема в том - что он независимая от системного кеша сущность. L2ARC вообще в данном кейсе оффтопичен.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	105. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 22-Авг-12, 00:09
	ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь, её специально не оптимизировали для конкретной операционной системы (Solaris, в частности), чтобы она была переносима на другие ОС и ядра? Или же разработчики ZFS всё-таки оставили несколько степеней свободы для адаптации её под другие системы для сращивания с так называемым системным кэшем (кэшем VFS?)?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	106. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от AlexAT (ok) on 22-Авг-12, 07:32
	> ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь, > её специально не оптимизировали для конкретной операционной системы (Solaris, в частности), > чтобы она была переносима на другие ОС и ядра? Или же > разработчики ZFS всё-таки оставили несколько степеней свободы для адаптации её под > другие системы для сращивания с так называемым системным кэшем (кэшем VFS?)? ARC - это не "несистемная хрень, присущая только ZFS", а механика работы кеша (Adaptive Replacement Cache). Если что. В ZFS - только одна из реализаций. Сделана потому, что LRU в солярке оказался слегка неприменим, а допиливать что-то в центре системы в проприетарщине тяжеловато. В итоге наплодили сущностей. Про zero-copy, естественно, никто не подумал. А когда начали - было уже поздно. В итоге zero-copy оно до сих пор не поддерживает. А отсутствие zero-copy механизма при активной работе с диском - это *дец процессорным кешам, помимо всего прочего. Про том, что жрать оно будет в 2 раза больше памяти, чем традиционная FS - тоже никто не заморачивался - при стоимости проприетари под солярку (санок) можно было память задом есть. Но вот беда - объемы данных подросли, да и санки сдохли, как экономически неэффективные. А выкидыш под названием ZFS - остался.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	122. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Авг-12, 16:20
	> Про zero-copy, естественно, никто не подумал. А когда начали - было уже > поздно. В итоге zero-copy оно до сих пор не поддерживает. А > отсутствие zero-copy механизма при активной работе с диском - это *дец > процессорным кешам, помимо всего прочего. Теоретики они такие теоретики, дай только порассуждать. :)) Почему в Btrfs нету поддержки RAID-5 и RAID-6?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	124. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 16:29
	> Теоретики они такие теоретики, дай только порассуждать. :)) Именно. А сделать - не получается. Потому что руки коротки. Поэтому zero-copy и нет. > Почему в Btrfs нету поддержки RAID-5 и RAID-6? Потому, что не особо в мейнстриме (т.е. энтузиасты-админы локалхостов не в счёт) интересны костыли над аппаратными решениями или md. RAID5/6 - это задача для специализированных контроллеров, а не CPU. md умеет, но практика показывает, что лучше не городить.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	129. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 17:06
	> Теоретики они такие теоретики, дай только порассуждать. :)) Практик из тебя тоже неважнецкий. С твоими 5Мб/сек на шпиндель ты как-то не вызываешь восхищения и желание повторить этот смертельный номер :P
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	119. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 21:54
	> ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь, > её специально не оптимизировали для конкретной операционной системы Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM?
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	121. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Авг-12, 23:07
	> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки > TRIM? Ораклу почти без надобности - так что видимо never.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	123. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 24-Авг-12, 16:27
	> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM? А тебе зачем? ;)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	125. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 16:30
	>> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM? > А тебе зачем? ;) Вестимо затем, чтобы понять, полное оно гуано, или всё-таки на SSD имеет право на жизнь с максимально обрезанным кешем.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	130. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 17:07
	> А тебе зачем? ;) Хочу отделить мух от котлет, а маркетинговый буллшит саней - от суровых реалий реального мира.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	230. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 00:47
	>> А тебе зачем? ;) > Хочу отделить мух от котлет, а маркетинговый буллшит саней - от суровых > реалий реального мира. Учитывая возраст катлет и опарышей в них в вашей криокамере этот вопрос уровня Дзен :))
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	153. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:28
	> А тебе зачем? ;) Да было интересно бы послушать. А то сани там не так давно втирали тонну маркетингового булшита про то что у них все супер-пупер оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что они без порток, но в шляпе :D
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	161. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:09
	> Да было интересно бы послушать. А то сани там не так давно > втирали тонну маркетингового булшита про то что у них все супер-пупер > оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что > они без порток, но в шляпе :D Да. У них всё "оптимизировано" "под SSD". Там знатоки рекомендуют при юзе ZFS сразу ставить 2Тб Flash Array за 160K$+флеш под любую инсталляцию, для L2ARC. И потом удивляются, почему её называют неюзабельной.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	165. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:14
	>> А тебе зачем? ;) > Да было интересно бы послушать. А то сани там не так давно > втирали тонну маркетингового булшита про то что у них все супер-пупер > оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что > они без порток, но в шляпе :D Операция TRIM нужна там, где используются блоки ФС гораздо меньшие по размеру блоков SSD. Например, в традиционных файловых системах собственные блоки имеют размеры 4, 8, 16 или 32 кбайт. В этом случае SSD нуждается в регулярных очистках пространства от "грязных" страниц, так как операция непосредственной записи на флэш выполняется блоком страниц 512 кбайт. Размер блока на ZFS может быть настроен равным размеру блока страниц SSD (512 кбайт вместо 128 кбайт), нужда в операции TRIM исчезает — запись новых данных происходит последовательно за одно обращение к накопителю: с очищением всех страниц блока SSD и записью в этот блок блока данных ФС без накладных расходов на отдельные операции очищения и перезаписи из-за несовпадения блоков данных, как если бы это происходило в традиционных ФС и ФС с экстентами.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	168. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:20
	Операция TRIM нужна еще и для оптимизации wear leveling на SSD. Она говорит SSD, что блок освобождён, и его можно использовать произвольным образом. Без TRIM, при удалении, допустим, файла с FS, SSD никак не узнает, что место освобождено.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	171. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:29
	И тут мы плавно подходим еще к одному веселому и вкусному моменту CoW FS на SSD без TRIM. CoW FS потихоньку использует весь диск, так как старается не занимать уже используемые блоки. Итого без TRIM утилизация пользовательского набора SSD при "fair use" быстро достигнет 100% (SSD никогда не узнает о том, что FS освободила блоки), приводя к падению скорости записи, и хреновой эффективности wear leveling'а (резервный набор на флешах не такой уж и большой). Таким образом под ZFS SSD проживет при "среднестатистической" утилизации на запись рекордно короткие, по сравнению с традиционными FS, сроки, и это факт. Традиционные FS даже без TRIM оставляют шансы на перезапись блока, CoW же FS на SSD без TRIM - редкостное извращение.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	175. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:43
	> И тут мы плавно подходим еще к одному веселому и вкусному моменту > CoW FS на SSD без TRIM. > CoW FS потихоньку использует весь диск, так как старается не занимать уже > используемые блоки. > Итого без TRIM утилизация пользовательского набора SSD при "fair use" быстро достигнет > 100% (SSD никогда не узнает о том, что FS освободила блоки), > приводя к падению скорости записи, и хреновой эффективности wear leveling'а (резервный > набор на флешах не такой уж и большой). Падение скорости записи будет только у ФС, у которых блок гораздо меньше размера блока страниц SSD. Я это уже объяснил ранее. В случае совпадающих размеров блока ФС и блока страниц SSD перезапись информации в использованных блоках будет происходить за одно обращение к накопителю! > Таким образом под ZFS SSD проживет при "среднестатистической" утилизации на запись рекордно > короткие, по сравнению с традиционными FS, сроки, и это факт. Традиционные > FS даже без TRIM оставляют шансы на перезапись блока, CoW же > FS на SSD без TRIM - редкостное извращение. TRIM изнашивает флэш тем, что перезаписывает очищает помеченные страницы ФИЗИЧЕСКИ. ZFS не использует TRIM и таким образом не перезаписывает лишний раз страницы флэш-памяти.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	178. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 11:16
	> Падение скорости записи будет только у ФС, у которых блок гораздо меньше > размера блока страниц SSD. Я это уже объяснил ранее. Падение скорости при больших объемах записи будет при любом размере блока - просто за счёт недостаточности резервного набора - чтобы что-то записать, надо что-то стереть, а стирание - операция долгая. В случае с TRIM в рабочий набор войдут уже стёртые после TRIM блоки. > TRIM изнашивает флэш тем, что перезаписывает очищает помеченные страницы ФИЗИЧЕСКИ. TRIM только помечает страницы, и помещает их в резервный набор. Который дальше используется для левелинга. Стирает их garbage collector, периодически.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	190. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 17:03
	>> Падение скорости записи будет только у ФС, у которых блок гораздо меньше >> размера блока страниц SSD. Я это уже объяснил ранее. > Падение скорости при больших объемах записи будет при любом размере блока - > просто за счёт недостаточности резервного набора - чтобы что-то записать, надо > что-то стереть, а стирание - операция долгая. В случае с TRIM > в рабочий набор войдут уже стёртые после TRIM блоки. С чего бы они войдут? TRIM выполняется с целым блоком — не с группой блоков, а с целой группой страниц по 4k каждая. Если в блоке есть страницы, которые не помечены как неиспользуемые, то операция TRIM просто их перезаписывает "как есть", так как из блока SSD (512k) их не выкинешь, а помеченные как неиспользуемые страницы — обнуляет. >> TRIM изнашивает флэш тем, что перезаписывает очищает помеченные страницы ФИЗИЧЕСКИ. > TRIM только помечает страницы, и помещает их в резервный набор. Который дальше используется для левелинга. Стирает их garbage collector, периодически. Это неважно, кто стирает. TRIM, как ATA-команда, призвана очистить помеченные неиспользованными страницы, но по сути работает с целым блоком страниц (сектором накопителя). "В SSD накопителях операция записи может быть проделана только для страниц, однако из-за аппаратных ограничений команда удаления всегда выполняется на весь блок. В результате, запись на SSD-носитель выполняется очень быстро до тех пор, пока существуют чистые страницы, но значительно замедляется, если необходимо очищать предварительно записанные страницы. Так как очистка ячеек в странице необходима перед тем, как в них можно будет записывать снова, но только целый блок может быть очищен, процесс перезаписи инициирует цикл чтение-очистка-модификация-запись:[5][8] содержимое целого блока должно быть сохранено в кеше перед тем, как оно может быть удалено с накопителя, перезаписываемые данные модифицируются в кеше и только после этого целый блок (с обновленной страницей) записывается на накопитель. Это явление известно как усиление записи (англ.).[9][10]": http://ru.wikipedia.org/wiki/TRIM_%28%D0%BA&#... Вот такое "усиление записи" производится в традиционных ФС с поддержкой TRIM. Как думаешь, долго ли протянет SSD в таком режиме? Скорость записи полезной информации высокая, спору нет, но износ... Ведь по сути сектор SSD перезаписывается с "усилием" тех страниц, которые не помечены как неиспользуемые. Такая перезапись для них никак не связана с полезной записью данных ФС — это как аналог регенерации динамической памяти на ёмкостных элементах.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	194. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 17:46
	> С чего бы они войдут? TRIM выполняется с целым блоком — не > с группой блоков, а с целой группой страниц по 4k каждая. Тупой пример для совсем уж непонимающих: удалили файл объёмом 20 гиг. С TRIM SSD узнает, что эти 20 гиг (за вычетом "неполных" блоков) можно юзать под рабочий набор. Без TRIM - нет. > Это неважно, кто стирает. TRIM, как ATA-команда, призвана очистить помеченные неиспользованными страницы, но по сути работает с целым блоком страниц (сектором накопителя). TRIM только маркирует страницы в служебных данных контроллера. Не более, и не менее. Иногда - запускает GC. Всё остальное было просто не понято Вами при прочтении. Как раз таки TRIM позволяет однозначно отметить полностью свободные блоки флеша, и не пытаться сохранять в них какие-либо данные при записи одного субблока. Ну и использовать эти блоки для leveling'а. TRIM'нутый блок флеша стирается, и используется под левелинг. А не TRIM'нутый но свободный - лежит, и ждёт, пока перезапишут именно его. В то время, когда маленький рабочий набор пытается вытянуть на себе перезаписи всего остального флеша.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	200. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 22:15
	> Операция TRIM нужна там, Операция TRIM нужна чтобы контроллер SSD мог разгребать мусор осмысленно и заранее. А не судорожно надрываться в ситуации когда уже приперло - записать надо, а чистых регионов нет. Потому что фиг бы его знает: используется вон тот блок файловой системой или нет. SSD этого не знает. Поэтому вынужден хранить все вплоть до момента пока кто-то не возжелает явно перезаписать этот блок. По поводу чего GC в SSD сваливается в очень неоптимальный режим - что-то типа твоего пула забитого до отказа получается, но в рамках одного накопителя. В случае TRIM - файловая система явно хинтит что "а вот этот кусок мы более не используем". По поводу чего SSD может заранее его разгрести. После чего и запись быстрее, и wear leveling куда меньше надрывается когда приспичило что-то записать. > записи на флэш выполняется блоком страниц 512 кбайт. Вообще-то она выполняется страницами, они порядка 1-4 кб, но это получается не всегда - в зависимости от того что было записано ранее. Если не получается оформить как запись чистых страниц - тогда стирается весь блок. Операция стирания достаточно длительная. Пока она происходит, писать данные невозможно. И данные курят бамбук, ожидая пока будет подготовлен регион. В случае с TRIM SSD это может сделать заранее. Без него - опаньки. Т.е. если повезло, запись проходит как page write(s) -> готово. > Размер блока на ZFS может быть настроен равным размеру блока страниц SSD ...но это не отменит того факта что SSD не будет знать используется ли некий блок. И не сможет очистить незанятые заранее.Поэтому при попытке записи сие будет выглядеть как: Read -> GC -> erase -> page write(s). Как-то больно дофига супротив первого варианта, не находишь? Не говоря о том что ssd сильно ограничен в возможности оптимизировать сбор мусора и оптимизировать циклы стирания и вообще wear leveling. Да, выделение блоков по размеру erase block может несколько скостить неоптимальность. Но тут есть одно большое но. Чтобы это случилось, блок должен попасть точно по границе сектора флеша. А поскольку геометрию флеша не видно, эта задача превращается в mindfuck. То-есть ты должен железно знать как ФС блоки раскидывает и подобрать смещение чтобы они попадали по границам секторов флеша. Кстати а блоки переменного размера отключить можно? А то они в этом случае все попортят - стоит воткнуть блок менее 512Кб как границы остальных блоков на ним перестанут совпадать с секторами флеша. И чтобы записать 1 блок придется тереть 2 сектора (просто потому что на пересечение оных попали). В 2 раза больше wear'а на ровном месте. У экстентных схем с этим несколько проще: даже если экстент и не попадает в границы блоков, возможность одним махом сделать экстент на 100500 мегабайтов обеспечит относительно небольшую (в процентах) неоптимальность, т.к. все блоки кроме крайних заведомо пишутся по 1 разу. > (512 кбайт вместо 128 кбайт), нужда в операции TRIM исчезает — Мечтать не вредно.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	231. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 00:49
	>> А тебе зачем? ;) > Да было интересно бы послушать. А то сани там не так давно > втирали тонну маркетингового булшита про то что у них все супер-пупер > оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что > они без порток, но в шляпе :D Это панталоны сер, вы их не туда натягиваете ... :)))
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	220. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 17:24
	>[оверквотинг удален] >> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт >> гиперфрагментации. >> А у ZFS еще одна проблема есть на этой ниве - ARC >> никак не взаимодействует с системным кешем, в итоге имеем двойное кеширование, >> отсутствие CoW в памяти / memory mapping из ARC - т.е. >> прямое копирование из ARC в кеш и назад, и в наихудших >> случаях - cache thrashing. > Правда что ли? Тогда зачем нужен динамический ARC и даже подключаемый при > желании L2ARC на внешних носителях? Ведь они "никак не взаимодействуют с > системным кэшем". :)) Гляди чего нарыл http://www.nekolove.jp/wp/archives/2012/01/20120124160239.php :))
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	110. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 02:52
	> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт гиперфрагментации. Хочу послушать научное обоснование столь громкого заявления. Ну насчет слоупока для любого дизайна CoW. Вообще, имхо наихучший режим будет если много мелких дозаписей. И кстати это плохо и для CoW и для обычных ФС - обе сгородят дикое количество фрагментов. Я так XFS положил до состояния когда файл в несколько Гб стирался на механическом диске секунд 30. Просто потому что дурно дозаписывался: сильно фрагментировался + метаданных вымахало много. Но это постараться надо еще, реально на такое наткнуться можно разве что качая огромный торрент без преаллокации. > А у ZFS еще одна проблема есть на этой ниве - ARC > никак не взаимодействует с системным кешем, Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания. В том плане "а нафига они это делали вот так?". Временами возникает ощущение что ответ - "я его слепила из того что было". Btrfs в этом плане более любопытен: автор дизайна смотрел на другие ФС и их сильные и слабые места + довольно удачно вылез перец предложивший модификацию b-деревьев. > в итоге имеем двойное кеширование, Учтя что оно и так в силу блочного аллокатора слоупок - ну да, весело. > ФС по возможности читают и отдают приложению данные вообще в zero-copy > режиме, тупым маппингом страниц. И пишут в кеш в ряде случаев так же. Справедливости ради, обычно файловая система в диск упирается все-таки. Копирование страниц - ничто по сравнению с двиганием голов накопителя. Хотя на скоростных SSD это уже станет актуальнее. Зато там иной mindf..k в плане тормознутой записи и невозможностью настоящего рандомного доступа мелкими блоками на запись, очень желательности делать trim и прочая. >> Сильно зависит от - там запись однократная: пишется только то что изменено. > Ничего не зависит. Взяли файл размером в гиг. Переписали метр в середину > (БД, к примеру). На традиционных FS блок встанет ровно туда, куда надо. Вот только: 1) Старое состояние - угробится. Совсем. Вернуть будет нельзя. Как раз именно поэтому. А в CoW файловой системе   2) Все это подразумевает что файл не растет, что как-то неверно. Плюс БД куда-то журнальную логику должна реализовать. Как раз потому что не может надеяться на то что произвольная ФС честно отжурналит. Ну и прочая. И если дефрагер еще может это разгрести то вот при его отсутствии фрагментация будет расти. В CoW при некоторых ворклоадах быстрее, да. 3) Вообще, для вот такого вот файла в btrfs cow можно взять и ... отключить. При том можно выборочно разуть на это только его. А все остальное пусть нормально будет, например. Ну в общем вполне нормальные рукоятки дадены для тех у кого мозг есть и кто желает получить больше чем по дефолту вышло. > А на CoW - вылететь может и в другую половину > диска, и при последовательном чтении файла потом всегда будет весело. Вот только странный какой-то ворклоад получается, когда запись мелкими кусочками а чтение огромным блоком. Ну то-есть, теоретически - ничему не противоречит. Практически - можно какую угодно ФС сильно просадить, если специально озаботиться. Но зачем? >> Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, >> а потом коммит того что в журнале на диск. > Данные в традиционных FS обычно не журналируются - незачем. Ага, а если на середине записи вдруг случится факап, у нас получится наполовину старый и наполовину новый файл. Проблема только в том что хотя сама ФС на уровне метаданных логически корректна - метаданные описывают какой-то файл, внутренняя структура этого файла окажется повреждена и будет содержать некорректные данные. Просто потому что не было данных ни чтобы довести запись до конца, ни чтобы откатить в вид как было. Поэтому - будет то что получилось. Не обязательно юзабельное вообще. СУБД такое лечат делая свою отдельную журнальную подсистему, раз уж ФС убогая и так не может, там данные для доведения транзакции до финиша или отката прихраниваются в журнал БД. Что опять же тормозит нещадно из-за двукратной записи. Хотя БД-версионники тоже бывают. Как раз чтобы два раза не писать. По сути, СУБД дореализовывает за недоношенными ФС кучу того что по уму должно было бы быть их обязанностью. Все-равно 90% этой механики в ФС уже есть, мля. > Если вдруг, и журнал начинает напрягать - его выносят на отдельный мелкий носитель (SSD). ...и меняют их штабелями. При интенсивной записи мелкими блоками с синхронизацией, столь характерной для журнала БД - особенно, т.к. SSD вообще не умеет на запись мелкими блоками работать (типичный erase block NAND нынче 512Кбайт). Особенно если TRIM нет, так что контроллер wear leveling'а постепенно сваливается в режим "т.к. неизвестно занят ли блок, будем решать проблемы по мере их возникновения" (в терминах CoW ФС это как если бы GC ждал момента когда том забьется до отказа и только потом начинал бы чистить, успокаиваясь как только немного разгребли). >> Не скажите. Один из основных козырей - технология имеет потенциал делать запись >> на диск со скоростью нежурналинуемой ФС > И потом иметь грабли при чтении размазанного ровным слоем по диску файла. А вот это зависит от того как именно запись делалась. При ряде ворклоадов будет лучше, при ряде - хуже. Разным дизайнам - разные свойства. Это нормально. Кстати если уж на то пошло, честное журналирование данных+метаданных (эквивалентное тому что делает CoW) в классике вообще тормозное как трындец. По поводу чего им никто и не пользуется почти. А если не журналить честно - так вон в btrfs тоже CoW можно выключить, например. Смысл этого деяния оставим на совести того кто его производит. Но можно же! Как раз примерно то же самое по смыслу и получим. Как раз фрагментация от CoW и отпадет. Ну, как тормоза от журналирования в классике. Улавливаете некую симметрию? Нежурналирующую ФС надо сравнивать с нежурналирующей. Или уж журналирующую с журналирующей. Чудес не бывает ;) > А если исключить перезапись - т.е. писать файлы, и не менять > - имеем как раз read-mostly паттерн. А если исключить полный журналинг данных - имеем ФС не способную честно откатить транзакцию или докатить ее до финиша, по поводу чего она хоть и будет логически корректна (не надо запускать fsck, который будет неделю жевать большой том) но файл на котором оборвалась запись вполне может быть порушен. Т.е. собственно честного журналинга по приинципу "все или ничего" и не обеспечивается как раз. Есть компромисс. В CoW - никаких компромиссов, все можно вернуть в вид как было до факапа в любой момент. Фрагмент или успевает дописаться и мы получаем новое состояние, или не успевает и остается старое. А так чтобы полфайла старое а полфайла новое - не будет. На классике это возможно только при полном журналинге данных. Тормознутом чтопипец из-за двойной записи данных в журнал и на диск. Неизбежном, т.к. иначе нельзя гарантровать транзакционность вида "все или ничего". > Вся эта идея CoW FS не нова. Я подобные алгоритмы видел еще в веарлевелерах > на самсунговских флешах, допустим, в SGH-X100, лет шесть-семь тому назад. Верно подмечено: wear leveling по сути чем-то таким и является. > Их чуть-чуть проапгрейдить, и получится CoW FS. Для флеша - > да, круто, там как раз то самое размазывание и интересно. Ну да. Правда без trim этой логике постепенно становится душно. По поводу чего trim в современных флешах и придумали, как я понимаю. И кстати на такой накопитель CoW ФС опять же лучше наложится чем полный журналинг: потенциально в 2 раза меньше записи на накопитель при полном журналировании, так что внутренней логике придется в 2 раза меньше записей разгребать. > Для механических дисков - грабельки. Так честный журнал в классике тоже грабельки, знаете ли. А нечестный как-то с CoW и сравнивать не больно честно. Ну вон отрубите в btrfs cow - получите нечто наподобие. Если уж сравнивать нежурналы и недожурналы - так пусть и у бтрфс будет не полный журналинг, чтоли. А то как-то нечестно когда некто полностью журналит, а его ставят в один ряд с нежурналирующими или недожурналирующими.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	115. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 23-Авг-12, 09:22
	>> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт гиперфрагментации. > Хочу послушать научное обоснование столь громкого заявления. Ну насчет слоупока для любого дизайна CoW. Вообще, имхо наихучший режим будет если много мелких дозаписей. Наихудший режим - это много мелких перезаписей, а не дозаписей. Типовой workload базы данных. Ну и CoW всё-таки гораздо более интенсивно расходует дисковое пространство, так, что в итоге диск превращается в "решето", куда новый достаточно большой файл уже можно дозаписать только с фрагментацией. Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в традиционных FS - только по мере заполнения диска) параметры системы сильно ухудшаются. А по мере заполнения диска на CoW FS вообще наступает ступор. > Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания. +1 > Справедливости ради, обычно файловая система в диск упирается все-таки. Копирование страниц Во что бы она не упиралась, отсутствие zero copy - лишняя бесполезная нагрузка на проц. > Вот только: > 1) Старое состояние - угробится. Совсем. Вернуть будет нельзя. Как раз именно В случае БД не актуально - она сама ведет журналы. > 2) Все это подразумевает что файл не растет, что как-то неверно. Файлы БД на самом деле обычно преаллоцируются, и растут, ну, достаточно редко, по сравнению с перезаписью. > БД куда-то журнальную логику должна реализовать. > Как раз потому что не может надеяться на то что произвольная ФС честно отжурналит. Не совсем. Журналы БД нужны еще для поддержания транзакционности. Как бы там FS не журналила, транзакция в БД != транзакция на FS. > 3) Вообще, для вот такого вот файла в btrfs cow можно взять > и ... отключить. При том можно выборочно разуть на это только А вот это очень здорово, в этом плане BTRFS будет очень удобной FS. Статические данные на CoW, БД без CoW. > Вот только странный какой-то ворклоад получается, когда запись мелкими кусочками а чтение огромным блоком. Типовой ворклоад БД. Пишется как попало, а при поисках читается сравнительно большими блоками. > Ага, а если на середине записи вдруг случится факап, у нас получится > наполовину старый и наполовину новый файл. БД пишут данные страницами, и имеют собственную структуру. Наполовину старый-новый файл нормально разгребается при recovery благодаря меткам. > Особенно если TRIM нет Ну это уже прошлый век. > А вот это зависит от того как именно запись делалась. При ряде > ворклоадов будет лучше, при ряде - хуже. Разным дизайнам - разные Лучше традиционок не будет в любом случае - даже тех же самых метаданных больше участвует в процессе. Т.е. с традиционками - правда ваша, сравнивать бессмысленно. В остальном согласен.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	132. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 18:16
	> Наихудший режим - это много мелких перезаписей, а не дозаписей. Для кого? Для CoW? Возможно. Для классики - не факт. Если файл остается contiguous - вполне сносно. Только сравнивать два напрочь разных дизайна в допущении что у них одинаковые свойства - странно. > Типовой workload базы данных. Может, именно потому в btrfs и предусмотрели отключку СoW в случае когда это надо. Да, не все ворклоады на CoW хорошо ложатся. Как впрочем и на любой иной дизайн ФС. > достаточно большой файл уже можно дозаписать только с фрагментацией. ...так поэтому в btrfs и сделали дефрагер. В отличие от саней они предпочитают решать технические проблемы а не затыкать их маркетингом. > Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в > традиционных FS - только по мере заполнения диска) Уточним: у CoW ФС где почему-то не совместили garbage collection с дефрагингом. В моем понимании в btrfs сделали это казалось бы очевидное улучшение, но до них почему-то никто не допер так делать. > параметры системы сильно ухудшаются. А по мере заполнения диска на CoW FS > вообще наступает ступор. Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера. > Во что бы она не упиралась, отсутствие zero copy - лишняя бесполезная > нагрузка на проц. Если уж на то пошло, могу себе представить асинхронный аналог memcpy на основе DMA, который вообще не грузит проц. В ядре наверное даже реально такое сделать. > В случае БД не актуально - она сама ведет журналы. ...потому что недожурналирующие и нежурналирующие ФС не могут это обеспечить :) > Файлы БД на самом деле обычно преаллоцируются, и растут, ну, достаточно редко, > по сравнению с перезаписью. Я согласен что у любого дизайна есть сильные и слабые стороны. Несомненно, можно найти ворклоад и требования неудобные для CoW. Как впрочем и для классики всех сортов. > Не совсем. Журналы БД нyжны еще для поддержания транзакционности. Так вообще-то по задумке, журнал файловой системе тоже нужен для транзакционности. А то что это в классике адски тормозит и начали лепить всякую читерскую упрощенку - так не от хорошей жизни. > Как бы там FS не журналила, транзакция в БД != транзакция на FS. Мотивацией к появлению журналирующих ФС было именно желание иметь семантику в духе транзакций. И сисколы типа (f)sync из той же области. Поскольку не все ФС умеют честно делать транзакции - да, всем приходится по 100500 раз перереализовывать ту же самую логику на уровне апликух. Иногда это оправдано, а иногда - нет. В целом программам и пользователям было бы удобнее если бы ФС сама реализовывала принцип "все или ничего". На данный момент в программах приходится дико костылировать там где нyжна надежная запись. Я считаю что реализация такой логики ближе к системной епархии чем к апликушной кроме ряда спецслучаев (типа БД где это может дать какие-то плюшки типа более хорошей оптимизации). > Статические данные на CoW, БД без CoW. Ну да, хорошо же когда можно подогнать по условиям. > Типовой ворклоад БД. Пишется как попало, а при поисках читается сравнительно большими > блоками. Это при SELECT * и прочих которые всю базу по чем зря лопатят? Так это вопрос к тем кто такой код пишет :P. > БД пишут данные страницами, и имеют собственную структуру. Наполовину старый-новый файл > нормально разгребaется при recovery благодаря меткам. Да, по сути БД реализует бОльшую часть логики ФС еще раз. В принципе можно считать ФС частным случаем БД вообще - больно много похожих кусков логики. > Ну это уже прошлый век. Так в сабже его вроде нет? :) > Лучше традиционок не будет в любом случае Будет. Как минимум при интенсивной записи с требованием полного журналирования. Читерство где только метаданные журналятся а что будет с данными всем наплевать вообще рассматривать малоинтенресно. Ну разве что для совсем уж не ценных данных. Собственно такой сценарий и является EPIC WIN-ом файловых систем на основе CoW. И это вполне себе один из типовых сценариев. > - даже тех же самых метаданных больше участвует в процессе. А при честном журналировании в классике данные вообще пишутся на диск дважды. И в общем случае данных больше чем метаданных. По поводу чего классика настолько тупит в режиме полного журналинга что этот режим вообще не реализуют в части таких ФС. В ext4 его реализовали, но вот скоростью работы он не блещет. > Т.е. с традиционками - правда ваша, сравнивать бессмысленно. У них просто разные сильные и слабые стороны. CoW - это улучшение полной журнальной логики на другой манер, с избавлением от многих недостатков оригинала. Но чудес не бывает и поэтому появляется и ряд специфичных для нового дизайна проблем. Совсем иных. Другому дизайну - другие свойства.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	137. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 19:04
	>> Наихудший режим - это много мелких перезаписей, а не дозаписей. > Для кого? Для CoW? Да, я про CoW. Классика - вполне себе отлично справится, не размазав файл по диску :) >> Типовой workload базы данных. > Может, именно потому в btrfs и предусмотрели отключку СoW в случае когда > это надо. Так оно и есть. Народ понимает, что CoW - не вселенское бобро, и применимо не везде. > ...так поэтому в btrfs и сделали дефрагер. В отличие от саней они > предпочитают решать технические проблемы а не затыкать их маркетингом. +1 >> Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в >> традиционных FS - только по мере заполнения диска) > Уточним: у CoW ФС где почему-то не совместили garbage collection с дефрагингом. Потому что нагрузка в реальном времени при этом убьёт все плюсы полностью. Честно говоря - удобнее всего оффлайн дефрагер. Онлайн - это для десктопов, где полклика мышкой в час, и нет тяжелых фоновых задач. > Если уж на то пошло, могу себе представить асинхронный аналог memcpy на > основе DMA, который вообще не грузит проц. Оно-то так оно и есть. Вот только данные надо и в кеш записать, и пользователю отдать. Два раза гонять DMA - слегка накладно по сравнению с mapping'ом страниц :) > Мотивацией к появлению журналирующих ФС было именно желание иметь семантику в духе > транзакций. Только семантику в духе. В БД есть еще такое понятие, как изоляция транзакций. И никакая логика транзакционности ФС её не повторит без усложнения ФС до уровня БД :) Но нафига оно тогда - проще сразу вкрутить DBE на RAW, и хранить всё в блобах. >> Статические данные на CoW, БД без CoW. > Ну да, хорошо же когда можно подогнать по условиям. Именно. > Да, по сути БД реализует бОльшую часть логики ФС еще раз. Нихт. В БД логика совершенно иная. Можно, конечно, БД в виде FS соорудить, но это давно уже пройденный и похеренный этап (dbf+ntx).
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	139. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 25-Авг-12, 02:09
	> Да, я про CoW. Классика - вполне себе отлично справится, не размазав > файл по диску :) До некоторой степени все-таки размажется, хоть и меньше чем с CoW. Особенно если преаллоцировать целиком. С другой, в CoW всяко есть GC и он до кучи может быть дефрагером. Так что он может и аннулировать этот недостаток до некоторой степени. >> Может, именно потому в btrfs и предусмотрели отключку СoW в случае когда это надо. > Так оно и есть. Народ понимает, что CoW - не вселенское бобро, и применимо не везде. Это просто хорошая и удачная технология. Но серебряной пулей она не является и имеет свои особенности и лимиты. Как впрочем и любая иная технология. >> предпочитают решать технические проблемы а не затыкать их маркетингом. > +1 Ну вот поэтом я и думаю что оно будет рулить. Линуксоидные ядерщики всегда ориентировались на практический результат и никогда не стеснялись дорабатывать и доводить до ума. Даже если для этого нужно порушить местами стройные концепции. А иногда и поломать совместимость с старьем, как минимум в 1 сторону. Ну как апгрейд ext4, когда у него экстенты появились. >> Уточним: у CoW ФС где почему-то не совместили garbage collection с дефрагингом. > Потому что нагрузка в реальном времени при этом убьёт все плюсы полностью. Актуально только для сильно некоторых ворклоадов. Плюс опять же, можно гонять дефраг в часы наименьшей загрузки, например. В общем то главное что пространство для маневра - есть. А не как у изена - сиди теперь с 6мб/сек пока пул не пересоберешь. Вот что-что а кантовать многодисковые пулы лишний раз мне почему-то совсем не хочется :P. > Честно говоря - удобнее всего оффлайн дефрагер. Онлайн - это для > десктопов, где полклика мышкой в час, и нет тяжелых фоновых задач. Если меня не глючит - в btrfs нынче можно и вручную дефрагер пнуть и на автомате. Кстати не вижу проблем сделать из онлайнового дефрага оффлайновый - если перестать юзать диск то дефраг сразу станет "почти оффлайновый". То что прекращение активности должно делаться средствами ФС - ниоткуда не следует. ИМХО напротив куда гибче если можно дефрагать онлайн. Снять нагрузку с тома при этом можно и отдельным приседанием. А вот если нечто умеет только оффлайн дефраг, улучшить скорость под нагрузкой вообще не вариант. А остановка может и не быть приемлимой - зависит от. И кстати если уж о автостарте дефрага: имхо, в общем случае лучше если ФС при нехватке места потупит - "ой, места нет, но ща наковыряем по быстрому" и выполнит запрос, наковыряв немного места GCом. Чем просто "ой, места нет а ковырять влом - идите нафиг! Error: no space left, blahblahblah". >> основе DMA, который вообще не грузит проц. > Оно-то так оно и есть. Вот только данные надо и в кеш записать, и пользователю > отдать. Два раза гонять DMA - слегка накладно по сравнению с mapping'ом страниц :) DMA имхо пофигу, он железный. Да и современные многоядерные процы не так уж и расстраиваются если полядра данные гоняет. На однопроцессорных машинах... но сейчас даже смарты с 4 ядрами бывают. Вон на форониксе Exynos 4 показательно порвал Tegra 3, особенно по способностям I/O с внешним миром :) >> Мотивацией к появлению журналирующих ФС было именно желание иметь семантику в духе >> транзакций. > Только семантику в духе. В БД есть еще такое понятие, как изоляция транзакций. Вообще-то, совсем не лишне так же и в ФС. Когда я записываю допустим офисный документ в сжатом зипушнике - меня совершенно не устроит если полфайла будет новое а полфайла старое, потому как inflate словит где-то в середине сжатых данных былинный отказ и я обломаюсь. При этом оно вообще перестанет читаться или будет читаться с лютыми глюками. Поэтому или уж мои изменения пишутся целиком или уж я как fallback хотя-бы старый вариант файла в предсказуемом виде получаю. А вот перспектива того что записываемый файл вообще заср@ться до неюзабельного состояния может если сбой будет в неудачный момент меня что-то не очень радует. > И никакая логика транзакционности ФС её не повторит без усложнения ФС до уровня БД :) Во первых, современные ФС не такие уж и простые. Во вторых не все БД такие уж сложные. Иная ФС посложнее иной БД, пожалуй. А логика журналирования в общем виде более-менее одинаковая для всех. Отличие разве что в терминах которыми оперируют БД и ФС, но это детали реализации. А честный журналинг как раз предполагает что ФС будет в состоянии реализовывать семантику транзакций. Просто потому что журнальная логика по изначальной задумке предполагает именно это самое. Если оттранслировать подход с частичным журналированием на БД: ой, а ну его нафиг эти ваши транзакции! Они тормозят! Особенно если 100500 миллионов записей по мегабайту каждая вдувать! А давайте лучше мы загарантируем вам то что база не будет биться при крахе, так что вам не надо будет перестраивать 100Гб базу полдня утилитами проверки и фиксинга, мы гарантируем что структура базы не испортится! Но вот гарантировать состояние ячеек мы вам нифига не будем! Зато скорость записи в 2 раза выше! Даже на бомж-железе, где никто не может позволить себе понты типа отдельного носителя для журнала и один тормозной винч надрывается на все и вся! > Но нафига оно тогда - проще сразу вкрутить DBE на RAW, и хранить всё в блобах. Возможность вкорячить некоторые БД на RAW раздел прозрачно намекает на то что БД реализует ту же самую логику в плане журналирования и совместно с журналящей ФС - по сути только двойную работу делает ;). RAW самый удобный и оптимальный режим работы для движка по идее, т.к. оверхед от ФС равен нулю. С точки зрения движка. И самый неудобный - с точки зрения админов. Поэтому в целом пришли к идее что ФС все-таки пусть лучше будет но - с минимальным оверхедом. >> Да, по сути БД реализует бОльшую часть логики ФС еще раз. > Нихт. В БД логика совершенно иная. Однако ж общий смысл действий логики журналинга БД как правило достаточно похож на то что делают ФС. > Можно, конечно, БД в виде FS соорудить, но это давно уже пройденный > и похеренный этап (dbf+ntx). Я бы скорее обозвал ФС специфичными базами данных, чтоли. Этакий частный случай с оптимизацией на некоторые допущения и договоренности.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	141. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 13:04
	User294, почему ты пишешь под другим именем? Пароль потерял от учётной записи?
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	234. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:23
	> User294, почему ты пишешь под другим именем? Пароль потерял от учётной записи? Не льстите ему, помнить два пароля явно за пределами его возможностей :))
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	150. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 19:22
	> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера. Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности? (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	154. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:40
	> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, > тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности? Звучит примерно как "а ты тоже выстрели себе в пятку и мы посмотрим кто из нас громче орать будет" :) Да, в btrfs может и будет жо, но ее можно будет устранить дефрагером и без пересборки многодисковой конструкции с пересозданием ФС с нуля. > (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.) Скорее к тому что это - перманентное состоения пула, которое не особо пролечится при освобождении места. Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	167. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:18
	>> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, >> тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности? > Звучит примерно как "а ты тоже выстрели себе в пятку и мы > посмотрим кто из нас громче орать будет" :) О, для тебя простое тестирование выливается в прострел пятки? O_o Скажи, тебе жить вообще не страшно? > Да, в btrfs может и будет жо, но ее можно будет устранить > дефрагером и без пересборки многодисковой конструкции с пересозданием ФС с нуля. Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим, что он тебе надефрагментирует. ;) >> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.) > Скорее к тому что это - перманентное состоения пула, которое не особо > пролечится при освобождении места. Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место терять зря на скорость, если и так всё устраивает? > Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти. Это про Btrfs?
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	169. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:24
	> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место > терять зря на скорость, если и так всё устраивает? Бред. То, что уже превратилось в лапшу, из неё путём освобождения 10-15 Гб не вывести. Более того, с высокой долей вероятности эти 10-15 Гб на диске, допустим, в 1.5Тб, будут также представлять лапшу блоками по несколько десятков метров.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	174. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:38
	>> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место >> терять зря на скорость, если и так всё устраивает? > Бред. То, что уже превратилось в лапшу, из неё путём освобождения 10-15 > Гб не вывести. Более того, с высокой долей вероятности эти 10-15 > Гб на диске, допустим, в 1.5Тб, будут также представлять лапшу блоками > по несколько десятков метров. А кто тебе сказал, что на 1.5ТБ пуле хранится лапша? Большая часть данных в таком объёме лично у меня редко перезаписывается. Это как хранилище медиафайлов. Что там перезаписывать? А торренты пишутся на отдельный небольшой пул без избыточности, который не страшно потерять и/или срыть и пересоздать заново.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	177. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 11:13
	> А кто тебе сказал, что на 1.5ТБ пуле хранится лапша? Большая часть > данных в таком объёме лично у меня редко перезаписывается. Это как > хранилище медиафайлов. Что там перезаписывать? Простите, а нахрена вообще CoW, если там ничего не перезаписывается? :)
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	201. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 22:29
	> О, для тебя простое тестирование выливается в прострел пятки? O_o Если в процессе тестирования предлагается взять пистолет, зарядить и направить его себе на пятку - и так понятно что результатом будет простреленная пятка. Более того, констатация того факта что у допустим железного робота она в принципе потом не заживет, а у человека может зажить - вовсе не требует простреливать себе пятку для доказательства этого тезиса. Это и так достаточно очевидно. Просто разница в дизайне. В одном рекавери из ситуации предусмотрен, а во втором - нет. > Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим, > что он тебе надефрагментирует. ;) Дык можно очистить часть места. Чтобы ему легче было. А если дефрагера нет - он ни при какой занятости ничего не надефрагментирует. По определению просто :P. > Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. А фрагментация куда девается если дефрагера нет? Опять магический маркетинговый буллшит? :) > Но зачем место терять зря на скорость, если и так всё устраивает? Да, собери raid из флопиков :). Слоупочить - так без компромиссов! >> Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти. > Это про Btrfs? Вот у btrfs как раз дадены средства выхода из штопора. А в zfs - предлагается маркетинговый буллшит, общая суть которого сводится к "докупите оперативы".
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	207. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 27-Авг-12, 00:17
	>> О, для тебя простое тестирование выливается в прострел пятки? O_o > Если в процессе тестирования предлагается взять пистолет, зарядить и направить его себе > на пятку - и так понятно что результатом будет простреленная пятка. Я вот не боюсь приводить тесты (чтения) скорости с ФС, а ты со своей Btrfs зассал? Нету у тебя никакой Btrfs. Ты её не используешь, а порассуждать любишь. >> Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим, >> что он тебе надефрагментирует. ;) > Дык можно очистить часть места. Чтобы ему легче было. А если дефрагера > нет - он ни при какой занятости ничего не надефрагментирует. По > определению просто :P. Так покажи результаты теста, что мешает? (Пятка чать не оторвётся. Или не знаешь ещё?) >> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. > А фрагментация куда девается если дефрагера нет? Опять магический маркетинговый буллшит? Откуда взяться фрагментации на данных, которые записаны раз и больше не трогаются. Это нужно весь пул перезаписывать рандомно каждый файл, чтобы ощутить всю прелесть фрагментации. Уверен, на это уйдёт гораздо больше времени, чем у традиционных ФС с 4k-, 8k-, 16k- и 32k-блоками — размеры блоков у ZFS гораздо больше (блоки переменного размера, кстати, но не меньше дефолтного 128k) и таких блоков по определению меньше требуется на один файл. А значит фрагментация минимальна в любом случае (блок ZFS не разделяется на части по всему диску). >>> Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти. >> Это про Btrfs? > Вот у btrfs как раз дадены средства выхода из штопора. Какие, например? Пока что мы слушаем твои теоретические измышления. > А в zfs - предлагается маркетинговый буллшит, общая суть которого сводится к "докупите оперативы". По крайней мере этот "булшит" работает как заявлено.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	162. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:10
	>> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера. > Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда > и будем сравнивать "+" и "-". Как насчёт 100% заполненности? > (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.) А ты удали с пула хлам хотя бы на 20%... И посмотри - улучшится ситуация на конкретных файлах или нет. Я-то точно знаю, что нет, как в лапшу легли, так лапшой и останутся, дефрагментации нет. Можешь проверить.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	170. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:25
	>>> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера. >> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда >> и будем сравнивать "+" и "-". Как насчёт 100% заполненности? >> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.) > А ты удали с пула хлам хотя бы на 20%... И посмотри > - улучшится ситуация на конкретных файлах или нет. Я-то точно знаю, > что нет, как в лапшу легли, так лапшой и останутся, дефрагментации > нет. Можешь проверить. И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью".
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	173. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:33
	> И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью". Пруф можно? Как удаление 3% хлама повлияло на чтение файла, который читался со скоростью 5МБ/с?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	176. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:46
	>> И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью". > Пруф можно? Как удаление 3% хлама повлияло на чтение файла, который читался со скоростью 5МБ/с? Пруфа не будет — тот файл, который читался со скоростью 5 МБ/с, был удалён. :)) Место освободилось == скорость записи снова выросла.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	202. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 22:30
	> что нет, как в лапшу легли, так лапшой и останутся, дефрагментации нет. А забавно изен шлангом прикидывается :D
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	179. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 11:28
	> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда > и будем сравнивать "+" и "-". Как насчёт 100% заполненности? BTRFS под рукой нету, зато есть ext4 c 97% заполнением. # uname -a Linux storage.net13.info 2.6.32-220.2.1.el6.x86_64 #1 SMP Fri Dec 23 02:21:33 CST 2011 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cpuinfo cpu family      : 16 model           : 10 model name      : AMD Phenom(tm) II X6 1090T Processor # cat /proc/meminfo MemTotal:         760500 kB # cat /etc/fstab LABEL=Anime     /data/Anime             ext4    defaults,user_xattr     0 0 # df -h Файловая система      Разм  Исп  Дост  Исп% смонтирована на /dev/mapper/Anime-Anime                       1,3T  1,2T   42G  97% /data/Anime # ls /data/Anime/Viewed/The\ Sky\ Crawlers/ -l -rwxr-xr-x 1 Alex Alex 8519873087 Фев  7  2010 The_Sky_Crawlers_(2008)_[1080p,BluRay,x264,DTS-ES]_-_gg-THORA.mkv # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 13,5986 c, 79,0 MB/c # dd if=/dev/zero of=/data/Anime/test.tst bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 33,4006 c, 32,1 MB/c # dd if=/data/Anime/test.tst of=/dev/null bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 13,8861 c, 77,3 MB/c --- CentOS 6.2 / 2 vCores / 768Mb vRAM @ VMWare ESXi 5U1 / 7 VMs @ AMD 1090T / 16Gb RAM / 3x1.5Tb RAID-5 @ LSI 9260-8i (Intel RS2BL080) Результаты могли слегка смазываться работающими в параллели виртуалками. Более того - контроллер работает в режиме кеширования WriteThru, потому что никак BBU для него купить не могу :)
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	180. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 14:52
	% df -h Filesystem                   Size    Used   Avail Capacity  Mounted on selena/downloads0             61G     59G    1.7G    97%    /downloads0 % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 790+1 records in 790+1 records out 828631040 bytes transferred in 30.008953 secs (27612794 bytes/sec) % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 790+1 records in 790+1 records out 828631040 bytes transferred in 0.427684 secs (1937484000 bytes/sec) % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 790+1 records in 790+1 records out 828631040 bytes transferred in 0.477275 secs (1736171437 bytes/sec) % zpool status selena   pool: selena state: ONLINE   scan: scrub repaired 0 in 6h41m with 0 errors on Mon May 21 01:10:34 2012 config:     NAME        STATE     READ WRITE CKSUM     selena      ONLINE       0     0     0       ada3p3    ONLINE       0     0     0 errors: No known data errors % smartctl -a /dev/ada3 smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.1-PRERELEASE amd64] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family:     Western Digital Caviar Blue Serial ATA Device Model:     WDC WD6400AAKS-65A7B2 Serial Number:    WD-WCASY8631846 LU WWN Device Id: 5 0014ee 1acc38eb5 Firmware Version: 01.03B01 User Capacity:    640 135 028 736 bytes [640 GB] Sector Size:      512 bytes logical/physical Device is:        In smartctl database [for details use: -P show] ATA Version is:   8 ATA Standard is:  Exact ATA specification draft version not indicated Local Time is:    Sun Aug 26 14:51:55 2012 VOLT SMART support is: Available - device has SMART capability. SMART support is: Enabled Учись, студент. :)
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	182. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 15:53
	> % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ > Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 > 828631040 bytes transferred in 30.008953 secs (27612794 bytes/sec) > % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ > Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 > 828631040 bytes transferred in 0.427684 secs (1937484000 bytes/sec) > % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ > Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 > 828631040 bytes transferred in 0.477275 secs (1736171437 bytes/sec) Бугага. Чему учиться-то? Скорость дискового кеша мерить на файле размером менее объема памяти? Единственное что - вполне адекватен первый тест - 27 Мб/сек, пока файл в кеш не попал. На нем видна реальная производительность дисковой системы. --- Да и вообще хиловато что-то, даже с кешем, наверное либо ядрышко, либо отсутствие zero-copy подводит. Вот так надо (всё та же платформа, что и выше - виртуалка, оверхед на работу с диском весьма приличный, count=512 потому, что у меня памяти на площадке всего 768M): # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=512 512+0 записей считано 512+0 записей написано скопировано 536870912 байт (537 MB), 4,1958 c, 128 MB/c # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=512 512+0 записей считано 512+0 записей написано скопировано 536870912 байт (537 MB), 0,217764 c, 2,5 GB/c # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=512 512+0 записей считано 512+0 записей написано скопировано 536870912 байт (537 MB), 0,200509 c, 2,7 GB/c --- О. С count=1024 со 2 попытки тоже осилил, видимо, контроллер диска тоже в свой кеш в 512Mb напихал остатки. # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 0,800595 c, 1,3 GB/c # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 0,392766 c, 2,7 GB/c # dd if=/data/Anime/Viewed/The\ Sky\ Crawlers/The_Sky_Crawlers_\(2008\)_\[1080p\,BluRay\,x264\,DTS-ES\]_-_gg-THORA.mkv of=/dev/null bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 0,38366 c, 2,8 GB/c
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	181. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 15:02
	Ещё: % df -h Filesystem                   Size    Used   Avail Capacity  Mounted on roxymedia/downloads          570G    570G    286M   100%    /downloads % dd if=/downloads/Пекло\ \(2007\).mkv of=/dev/null bs=1048576 count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 36.846162 secs (29141212 bytes/sec) % dd if=/downloads/Пекло\ \(2007\).mkv of=/dev/null bs=1048576 count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 0.605385 secs (1773650997 bytes/sec) Прочитаем, что читали несколько минут назад: % dd if=/downloads0/Уральские\ пельмени/25.\ Уральские\ пельмени.\ \ Зе\ BAD\ –\ Худшее\!\ \(2012.04.01\).avi of=/dev/null bs=1048576 count=1024 790+1 records in 790+1 records out 828631040 bytes transferred in 0.426347 secs (1943560073 bytes/sec) Проверим скорость чтения данных в кэше: % dd if=/downloads/Пекло\ \(2007\).mkv of=/dev/null bs=1048576 count=1024       1024+0 records in 1024+0 records out 1073741824 bytes transferred in 0.582971 secs (1841844768 bytes/sec) % zpool status roxymedia   pool: roxymedia state: ONLINE   scan: scrub repaired 0 in 34h15m with 0 errors on Thu Apr 12 21:50:51 2012 config:     NAME        STATE     READ WRITE CKSUM     roxymedia   ONLINE       0     0     0       ada0p3    ONLINE       0     0     0 errors: No known data errors % smartctl -a /dev/ada0 smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.1-PRERELEASE amd64] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family:     SAMSUNG SpinPoint M7E (AFT) Device Model:     SAMSUNG HM641JI Serial Number:    S23TJ9AZB04208 LU WWN Device Id: 5 0024e9 203cd8643 Firmware Version: 2AJ10001 User Capacity:    640 135 028 736 bytes [640 GB] Sector Size:      512 bytes logical/physical Device is:        In smartctl database [for details use: -P show] ATA Version is:   8 ATA Standard is:  ATA-8-ACS revision 6 Local Time is:    Sun Aug 26 15:00:07 2012 VOLT SMART support is: Available - device has SMART capability. SMART support is: Enabled
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	183. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 15:58
	cat /proc/cpuinfo cat /proc/meminfo хотелось бы видно, что 27-29 Мб/сек - предел чтения с диска до кеширования. лапша - она и есть лапша
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	187. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 16:33
	> cat /proc/cpuinfo > cat /proc/meminfo > хотелось бы % cat /proc/cpuinfo cat: /proc/cpuinfo: No such file or directory % cat /proc/meminfo cat: /proc/meminfo: No such file or directory — нету этого во FreeBSD. Потенциально небезопасных вещей не держим-с. Лучше так: % zfs-stats -a ------------------------------------------------------------------------ ZFS Subsystem Report                Sun Aug 26 16:29:21 2012 ------------------------------------------------------------------------ System Information:     Kernel Version:                901500 (osreldate)     Hardware Platform:            amd64     Processor Architecture:            amd64     ZFS Storage pool Version:        28     ZFS Filesystem Version:            5 FreeBSD 9.1-PRERELEASE #0: Thu Aug 23 14:45:34 VOLT 2012 root 16:29  up 22 mins, 1 user, load averages: 0,22 0,31 0,27 ------------------------------------------------------------------------ System Memory:     4.82%    356.87    MiB Active,    1.50%    111.22    MiB Inact     21.87%    1.58    GiB Wired,    0.13%    9.29    MiB Cache     71.67%    5.19    GiB Free,    0.02%    1.22    MiB Gap     Real Installed:                8.00    GiB     Real Available:            93.47%    7.48    GiB     Real Managed:            96.76%    7.24    GiB     Logical Total:                8.00    GiB     Logical Used:            33.71%    2.70    GiB     Logical Free:            66.29%    5.30    GiB Kernel Memory:                    1.05    GiB     Data:                98.01%    1.02    GiB     Text:                1.99%    21.24    MiB Kernel Memory Map:                7.23    GiB     Size:                10.58%    783.32    MiB     Free:                89.42%    6.46    GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY)     Memory Throttle Count:            0 ARC Misc:     Deleted:                43     Recycle Misses:                0     Mutex Misses:                0     Evict Skips:                2.05k ARC Size:                16.45%    1.03    GiB     Target Size: (Adaptive)        100.00%    6.24    GiB     Min Size (Hard Limit):        12.50%    798.12    MiB     Max Size (High Water):        8:1    6.24    GiB ARC Size Breakdown:     Recently Used Cache Size:    49.98%    3.12    GiB     Frequently Used Cache Size:    50.02%    3.12    GiB ARC Hash Breakdown:     Elements Max:                85.95k     Elements Current:        100.00%    85.95k     Collisions:                29.07k     Chain Max:                6     Chains:                    18.41k ------------------------------------------------------------------------ ARC Efficiency:                    1.14m     Cache Hit Ratio:        93.07%    1.06m     Cache Miss Ratio:        6.93%    79.28k     Actual Hit Ratio:        90.24%    1.03m     Data Demand Efficiency:        95.25%    555.03k     Data Prefetch Efficiency:    8.39%    1.47k     CACHE HITS BY CACHE LIST:       Anonymously Used:        3.03%    32.25k       Most Recently Used:        26.15%    278.39k       Most Frequently Used:        70.81%    753.77k       Most Recently Used Ghost:    0.00%    15       Most Frequently Used Ghost:    0.01%    94     CACHE HITS BY DATA TYPE:       Demand Data:            49.66%    528.67k       Prefetch Data:        0.01%    123       Demand Metadata:        47.29%    503.46k       Prefetch Metadata:        3.03%    32.26k     CACHE MISSES BY DATA TYPE:       Demand Data:            33.25%    26.36k       Prefetch Data:        1.69%    1.34k       Demand Metadata:        49.90%    39.56k       Prefetch Metadata:        15.16%    12.02k ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency:                    6.70m     Hit Ratio:            69.43%    4.65m     Miss Ratio:            30.57%    2.05m     Colinear:                2.05m       Hit Ratio:            0.01%    144       Miss Ratio:            99.99%    2.05m     Stride:                    4.64m       Hit Ratio:            100.00%    4.64m       Miss Ratio:            0.00%    7 DMU Misc:     Reclaim:                2.05m       Successes:            0.11%    2.16k       Failures:            99.89%    2.05m     Streams:                13.09k       +Resets:            0.08%    10       -Resets:            99.92%    13.08k       Bogus:                0 ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl):     kern.maxusers                           384     vm.kmem_size                            7768879104     vm.kmem_size_scale                      1     vm.kmem_size_min                        0     vm.kmem_size_max                        329853485875     vfs.zfs.arc_max                         6695137280     vfs.zfs.arc_min                         836892160     vfs.zfs.arc_meta_used                   571903256     vfs.zfs.arc_meta_limit                  1673784320     vfs.zfs.l2arc_write_max                 8388608     vfs.zfs.l2arc_write_boost               8388608     vfs.zfs.l2arc_headroom                  2     vfs.zfs.l2arc_feed_secs                 1     vfs.zfs.l2arc_feed_min_ms               200     vfs.zfs.l2arc_noprefetch                1     vfs.zfs.l2arc_feed_again                1     vfs.zfs.l2arc_norw                      1     vfs.zfs.anon_size                       388608     vfs.zfs.anon_metadata_lsize             0     vfs.zfs.anon_data_lsize                 0     vfs.zfs.mru_size                        423030784     vfs.zfs.mru_metadata_lsize              64367616     vfs.zfs.mru_data_lsize                  259607552     vfs.zfs.mru_ghost_size                  48273920     vfs.zfs.mru_ghost_metadata_lsize        427008     vfs.zfs.mru_ghost_data_lsize            47846912     vfs.zfs.mfu_size                        378490368     vfs.zfs.mfu_metadata_lsize              24965632     vfs.zfs.mfu_data_lsize                  270126080     vfs.zfs.mfu_ghost_size                  46437376     vfs.zfs.mfu_ghost_metadata_lsize        757760     vfs.zfs.mfu_ghost_data_lsize            45679616     vfs.zfs.l2c_only_size                   0     vfs.zfs.dedup.prefetch                  1     vfs.zfs.mdcomp_disable                  0     vfs.zfs.no_write_throttle               0     vfs.zfs.write_limit_shift               3     vfs.zfs.write_limit_min                 33554432     vfs.zfs.write_limit_max                 1003658752     vfs.zfs.write_limit_inflated            24087810048     vfs.zfs.write_limit_override            0     vfs.zfs.prefetch_disable                0     vfs.zfs.zfetch.max_streams              8     vfs.zfs.zfetch.min_sec_reap             2     vfs.zfs.zfetch.block_cap                256     vfs.zfs.zfetch.array_rd_sz              1048576     vfs.zfs.mg_alloc_failures               8     vfs.zfs.check_hostid                    1     vfs.zfs.recover                         0     vfs.zfs.txg.synctime_ms                 1000     vfs.zfs.txg.timeout                     5     vfs.zfs.vdev.cache.max                  16384     vfs.zfs.vdev.cache.size                 0     vfs.zfs.vdev.cache.bshift               16     vfs.zfs.vdev.max_pending                4     vfs.zfs.vdev.min_pending                2     vfs.zfs.vdev.time_shift                 6     vfs.zfs.vdev.ramp_rate                  2     vfs.zfs.vdev.aggregation_limit          131072     vfs.zfs.vdev.read_gap_limit             32768     vfs.zfs.vdev.write_gap_limit            4096     vfs.zfs.vdev.bio_flush_disable          0     vfs.zfs.zil_replay_disable              0     vfs.zfs.cache_flush_disable             0     vfs.zfs.zio.use_uma                     0     vfs.zfs.snapshot_list_prefetch          0     vfs.zfs.super_owner                     0     vfs.zfs.debug                           0     vfs.zfs.version.acl                     1     vfs.zfs.version.spa                     28     vfs.zfs.version.zpl                     5 ------------------------------------------------------------------------ > видно, что 27-29 Мб/сек - предел чтения с диска до кеширования. лапша > - она и есть лапша Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка: если специально её не тюнить и не подстраивать свойства) — скорость примерно в два раза ниже максимально возможной в RAW-режиме, зато по всей поверхности диска примерно одни и те же показатели.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	189. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от filosofem (ok) on 26-Авг-12, 16:51
	>Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка: если специально её не тюнить и не подстраивать свойства) — скорость примерно в два раза ниже максимально возможной в RAW-режиме, зато по всей поверхности диска примерно одни и те же показатели. Хиловато. Но на самом деле больше похоже на в 3 раза ниже средней скорости RAW девайса. Не затруднит привести скорость чтения в начале и в конце SAMSUNG HM641JI. Сдается мне, что она ~100MB/c в обоих случаях.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	191. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 17:12
	>>Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка: если специально её не тюнить и не подстраивать свойства) — скорость примерно в два раза ниже максимально возможной в RAW-режиме, зато по всей поверхности диска примерно одни и те же показатели. > Хиловато. Но на самом деле больше похоже на в 3 раза ниже > средней скорости RAW девайса. > Не затруднит привести скорость чтения в начале и в конце SAMSUNG HM641JI. > Сдается мне, что она ~100MB/c в обоих случаях. Только среднюю по трём одинаковым шпинделям: % dmesg | grep SAMSUNG ad12: 610480MB <SAMSUNG HM641JI 2AJ10001> at ata6-master UDMA100 SATA 3Gb/s ad16: 610480MB <SAMSUNG HM641JI 2AJ10001> at ata8-master UDMA100 SATA 3Gb/s ad20: 610480MB <SAMSUNG HM641JI 2AJ10001> at ata10-master UDMA100 SATA 3Gb/s % dd if=/dev/zero of=/dev/ad12 bs=200M dd: /dev/ad12: short write on character device dd: /dev/ad12: end of device 3053+0 records in 3052+1 records out 640135028736 bytes transferred in 8943.763290 secs (71573342 bytes/sec) % dd if=/dev/zero of=/dev/ad16 bs=200M dd: /dev/ad16: short write on character device dd: /dev/ad16: end of device 3053+0 records in 3052+1 records out 640135028736 bytes transferred in 8998.987157 secs (71134120 bytes/sec) % date вторник, 26 октября 2010 г. 20:45:14 (VOLST) % dd if=/dev/zero of=/dev/ad20 bs=200M dd: /dev/ad20: short write on character device dd: /dev/ad20: end of device 3053+0 records in 3052+1 records out 640135028736 bytes transferred in 8845.343762 secs (72369717 bytes/sec) С тех пор наименования изменились. Сейчас это (добавлен ещё один шпиндель): % dmesg | grep SAMSUNG ada0: <SAMSUNG HM641JI 2AJ10001> ATA-8 SATA 2.x device ada1: <SAMSUNG HM641JI 2AJ10001> ATA-8 SATA 2.x device ada2: <SAMSUNG HM641JI 2AJ10001> ATA-8 SATA 2.x device ada4: <SAMSUNG HM641JI 2AJ10001> ATA-8 SATA 2.x device
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	192. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от filosofem (ok) on 26-Авг-12, 17:35
	Что то вроде dd if=/dev/ada0 of=/dev/null bs=1G count=1 dd if=/dev/ada0 of=/dev/null bs=1G count=1 skip=600 Хотя нашел на томсхардваре, максимум ~90, минимум ~50. В среднем те же 70 с хреном. То есть ZFS в 3 раза медленне максимальной и в 2.5 медленнее средней.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	193. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 17:43
	> Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка: > если специально её не тюнить и не подстраивать свойства) — скорость > примерно в два раза ниже максимально возможной в RAW-режиме, зато по > всей поверхности диска примерно одни и те же показатели. Два вопроса: это как, и зачем она такая красивая нужна?
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	203. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 22:34
	> видно, что 27-29 Мб/сек - предел чтения с диска до кеширования. лапша > - она и есть лапша Дык :). И я как-то сомневаюсь что iZEN денно и нощно хранит в оперативке в кеше свои уральские пельмени. Поэтому в большинстве случаев скорость вон та, а не те красивые гиг/сек из кеша. Если уж скорость RAM мерять для файловых операций - можно рамдиск сделать :D.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	184. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 16:04
	для достоверности почитаем разные файлы: # dd of=/dev/null bs=1048576 count=1024 if=/data/Anime/Viewed/Eden\ Of\ The\ East/OVA1\ The\ King\ of\ Eden/\[Coalgirls\]_Eden_of_the_East_Movie_I_\(1920x1080_Blu-Ray_FLAC\)_\[68AB2703\].mkv 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 15,3123 c, 70,1 MB/c # dd of=/dev/null bs=1048576 count=1024 if=/data/Anime/Viewed/Xamd\ Lost\ Memories/Xam\'d_Lost_Memories_Ep11_Assault_The_Zanbani_\[1080p\,BluRay\,x264\,DTS\]_-_THORA.mkv 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 13,7931 c, 77,8 MB/c # dd of=/dev/null bs=1048576 count=1024 if=/data/Anime/Viewed/Love\ Hina/OVA1\ DVD\ Love\ Hina\ Xmas/VIDEO_TS/VTS_01_2.VOB 1023+1 записей считано 1023+1 записей написано скопировано 1073588224 байта (1,1 GB), 8,53469 c, 126 MB/c Как видим, производительность достаточно конзистентна, и 70 Мб/сек - это более-менее минимум. Потому что файлы не разбиты в лапшу. К слову говоря, Xam'd писался совсем недавно.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	151. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 00:46
	Oracle на ZFS: Учимся готовить кошек, часть I: http://yvoinov.blogspot.com/2011/01/oracle-zfs-i.html Oracle Database Single Instance на ZFS: учимся готовить: https://blogs.oracle.com/pomah/entry/oracle_database_single_...
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	155. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:44
	> Oracle Database Single Instance на ZFS: учимся готовить: > https://blogs.oracle.com/pomah/entry/oracle_database_single_... Да, да, и опять там про фрагментацию изящно повиляно попой. Проблему так изящненько замаскировали под пенька :)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	159. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 09:49
	Я встречал неоднократно людей, способных на базе в 20 мегабайт добиться "выдающихся скоростных результатов" ("невыдающиеся" были обусловлены кривыми руками). Автор не описывает ни структуру, ни объем базы, ни число записей. Да. Точно. Наткнулся на "тест" автора. Автор делает линейную (*, без WHERE) выборку из таблицы размером в 11 небольших строк, и надеется, что на его выборку как-то повлияет FS. Ровно то, что и требовалось доказать. Т.е. автор в виде результатов получил шум океанов Марса, и на их основании пытается делать какие-то выводы. --- А по второй ссылке - там вообще страхи: >>> Sun Storage F5100 Flash Array позволяет держать в кэше до 2TB данных Всего-то $160000, плюс флеши >>> Для увеличения скорости записи так же желательно использовать Sun Flash Accelerator F20 PCIe Card Еще $2000 Итого 162000$ + еще порядка 20000 на флеш только чтобы компенсировать "потребности" ZFS. К слову говоря, с кешем такого объёма FS чаще всего уже непринципиальна. Т.е. недостатки FS с расходом памяти заткнули SSD с огромным размером кешируемого рабочего набора. Так можно поступать, только когда немеряно денег, и их некуда деть.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	233. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:18
	> Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания. Похоже не только этого пепелаца но и половины данного ресурса :))
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	226. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 04-Фев-13, 20:27
	>>> А какая у него стоимость? >> Много памяти, >То что ZFS за счет своего блочного аллокатора слоупок > и без немеряного дискового кеша тормозит - ну да. Так ext3 > тоже слоупок на фоне ext4, если что. В btrfs это учли. > Вообще, ничто не обязывает CoW сам по себе требовать много памяти > или тормозить. В btrfs с его чуйдо аллокатором по прежнему нельзя отключить кеширование для отдельно взятого раздела ? > диск. Тогда как btrfs например вообще может раскладывать данные как угодно. Достаточно 1 раз попать на бедблок и потом ниче не найдешь ? > А вот тут согласен на все 100%. И тем не менее в > большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в > плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду > не юзает в режиме полного журналирования. Привидите результаты хотябы одного теста на засраных поюзанных разделах, а то сферические кони в вакуме всегда быстро летают ...
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	17. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–4 +/–
	Сообщение от pro100master (ok) on 18-Авг-12, 13:32
	она такой же тормоз, как и btrfs. На десктоп не поставите, например.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	25. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:51
	> она такой же тормоз, как и btrfs. Она куда больший тормоз чем btrfs. Смотрим бенчмарки. Ну а btrfs тормоз лишь при сильно некоторых нагрузках.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	31. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от pro100master (ok) on 18-Авг-12, 15:25
	При любых. И это печально :(
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	84. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:05
	> При любых. Бенчмарки с вами не согласны. И да, предвосхищая возмущенные вопли, они тоже вид ворклоада.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	94. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 07:10
	>> При любых. > Бенчмарки с вами не согласны. И да, предвосхищая возмущенные вопли, они тоже > вид ворклоада. Фороникс негодуе?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	133. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 18:20
	> Фороникс негодуе? Кэп информирует что у фороникса пока нет монополии на бенчмарки :)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	235. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:28
	>> Фороникс негодуе? > Кэп информирует что у фороникса пока нет монополии на бенчмарки :) Я заметил анонимусы не представляют никаких результатов тестов кроме фороникса :)) наверно из-за "неудовлетворительных"  с их точки зрения результатов, ну так давайте сравним с этим http://www.nekolove.jp/wp/archives/2012/01/20120124160239.php
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	41. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от кевин on 18-Авг-12, 19:55
	ещё предлагали использовать эффективное сжатие и агрессивную дедупликацию для экономии места на всяких нетбуках.. но экономически оказалось дешевле воткнуть в нетбуки диски большего объёма.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	44. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 20:53
	И вдруг объявились SSD, на которых внезапно экономить место опять стало целесообразным. Рано или поздно на пике расцвета SSD объявится еще какая-нибудь технология, забивающая их по всем параметрам кроме стоимости за гигабайт. Жаль все-таки, что "экономическая целесообразность" преследует слишком коротую выгоду.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 21:23
	> И вдруг объявились SSD, на которых внезапно экономить место опять стало целесообразным. На SSD надо не экономить место, а не держать всякий хлам. SSD - это не долгосрочная файлопомойка, а, скорее, оперативный кэш. Причём для read-mostly нагрузок. В итоге либо цена SSD упадёт до цены HDD, либо они так и останутся в двух применениях: под собственно ОС (десктоп) либо БД (сервер), и в качестве кеш-драйва для дисковой системы (большинство аппаратных рейдов уже умеют). К слову, применение SSD под кеш, в целом, наиболее оправдано.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	85. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:06
	> - это не долгосрочная файлопомойка, а, скорее, оперативный кэш. Причём для > read-mostly нагрузок. Вот только в ноуте обычно 1 гнездо для диска. Так что или так, или эдак.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	95. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 21-Авг-12, 07:12
	> Вот только в ноуте обычно 1 гнездо для диска. Так что или > так, или эдак. Гибридные диски уже выпускаются. Если честно - я не вижу вообще смысла в SSD для ноута. Для планшета - смысл есть, например, возможность его ронять - ЦА такова, что и утопить может, не то, что уронить. А для ноута... ну, можно притянуть за уши несколько резонных вещей, но в общем и целом смысла нет.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	111. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 09:07
	> Гибридные диски уже выпускаются. А это вообще ни рыба, ни мясо. Вымрут имхо. > Если честно - я не вижу вообще смысла в SSD для ноута. Зато я вижу: машина ждет юзера а не юзер - машину. Хорошо когда либрофисы всякие взлетают за полсекунды :). К тому же крутить не надо - меньше жрет при чтении, прочнее, не надо ждать пока раскрутится, etc. > А для ноута... ну, можно притянуть за уши несколько резонных вещей, но в общем и целом смысла нет. Кому как. Ноутбучные винчи - тормозные до неприличия. А ждать постоянно тупящую машину - не очень то приятно. А ожидание может быть весьма ощутимо, т.к. винч стопорится для экономии батареи.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	142. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Авг-12, 13:23
	> Кому как. Ноутбучные винчи - тормозные до неприличия. А ждать постоянно тупящую > машину - не очень то приятно. А ожидание может быть весьма > ощутимо, т.к. винч стопорится для экономии батареи. Ноутбучная память настолько дешёвая, что поставить 8Гб - 0 проблем 0 копеек. И результат от объёма кеша превзойдёт все ваши лучшие ожидания от SSD :)
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	156. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:55
	> Ноутбучная память настолько дешёвая, что поставить 8Гб - 0 проблем 0 копеек. > И результат от объёма кеша превзойдёт все ваши лучшие ожидания от SSD :) Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт системы с HDD никогда не будет сравним в SSD. А выключать иногда приходится - батарейка не резиновая. Ну и все остальное так же будет. А SSD можно с некоторой условностью считать одним большим кешом.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	163. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:11
	> Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт > системы с HDD никогда не будет сравним в SSD. А выключать > иногда приходится - батарейка не резиновая. Ну и все остальное так > же будет. А SSD можно с некоторой условностью считать одним большим > кешом. 1. Hibernate отменили? 2. Prefetch настроен?
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	204. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 22:46
	> 1. Hibernate отменили? Да, потому что взлет и особенно шатдаун без него - заметно быстрее. > 2. Prefetch настроен? А как же. Только все-равно, данные то надо прочитать. А seek time у ноутбучных винчей не фонтан. SSD в этом плане намного лучше.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	205. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 22:48
	>> 1. Hibernate отменили? > Да, потому что взлет и особенно шатдаун без него - заметно быстрее. Раз рабочий взлёт-шатдаун с rotational drive у вас быстрее хибернейта - SSD вам не поможет, дело не в диске. >> 2. Prefetch настроен? См.1.
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	236. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:31
	>> Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт >> системы с HDD никогда не будет сравним в SSD. А выключать >> иногда приходится - батарейка не резиновая. Ну и все остальное так >> же будет. А SSD можно с некоторой условностью считать одним большим >> кешом. > 1. Hibernate отменили? Сон быстрее. > 2. Prefetch настроен? Выключи и забудь.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	246. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 07:19
	>> 1. Hibernate отменили? > Сон быстрее. Отличный совет. Если не считать того, что "сон" требует наличия э/п на памяти.
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	251. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 19:36
	>>> 1. Hibernate отменили? >> Сон быстрее. > Отличный совет. Если не считать того, что "сон" требует наличия э/п на > памяти. В вашем ноуте сдох акумулятор ?
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	253. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 20:00
	> В вашем ноуте сдох акумулятор ? Прикинь, мну ломает тратить аккумулятор ноута на поддержание памяти часами. Особенно в поездке. Особенно в деловой. Особенно когда минуты работы на счету.
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	255. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 20:27
	>> В вашем ноуте сдох акумулятор ? > Прикинь, мну ломает тратить аккумулятор ноута на поддержание памяти часами. Особенно в > поездке. Особенно в деловой. Особенно когда минуты работы на счету. Такой хреновый акумулятор ?
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	256. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 20:27
	> Такой хреновый акумулятор ? Да нет, такой суровый ноут. 4-корка с 8Гб и пять рабочих виртуалок на ней.
	Ответить | Правка | ^ к родителю #255 | Наверх | Cообщить модератору

	9. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 11:56
	А мужики-то и не знали... Использую ZFS в практически домашних условиях, дико удобная вещь.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	40. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+3 +/–
	Сообщение от ананим on 18-Авг-12, 18:00
	У меня сосед по даче трактор купил. Да-а-а-воле-е-ен! как слон. Как то с семью на нём на дачу привёз - говорит, нахрен 2-а раза то ездить. Ну, логично то в общем. И не возразишь.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	35. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 16:42
	Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	38. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 18-Авг-12, 17:36
	> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения. lol'd ну изен с 5 MBps с диска тут уже был
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	48. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 19-Авг-12, 00:07
	>> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения. > lol'd > ну изен с 5 MBps с диска тут уже был Вы забыли добавить: "с заполненными на 99% пулами". Как ведут себя в подобных случаях альтернативные ФС, говорить будем или скромно умолчим?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	51. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ragus (ok) on 19-Авг-12, 05:22
	Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного места - беда всех CoW файловых систем. Так что ext4/xfs вполне нормально живут при почти полной занятости дисков. Т.е. ZFS не годится как фс для сервера бэкапов(точнее, требует держать на сторадже меньше данных, чем его размер).
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	53. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 19-Авг-12, 09:56
	>Так что ext4/xfs вполне нормально живут при почти полной занятости дисков. Если бы только не фрагментация и баги
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	55. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 19-Авг-12, 12:15
	да бросьте уже ерунду писать. xfs и тем более ext4 гораздо стабильнее и zfs, и btrfs.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	62. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от kshetragia (ok) on 20-Авг-12, 05:34
	Че-то похоже на сравнение теплого с зеленым. Либо уж сравнивайте ZFS <> BTRFS/EXT4+LVM(с натяжкой) либо EXT4/XFS <> UFS/FFS.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	112. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Аноним (??) on 23-Авг-12, 09:11
	> EXT4/XFS <> UFS/FFS. А чего сравнивать то? Вторые - ископаемые как@шки мамонта. По поводу на большинстве бенчей и вообще ворклоадов первые сделают со вторыми то же что Тузик с грелкой. Ибо extent-based файловые системы в общем случае делают block-based. По поводу чего античные блочные методы выделения места остались в ходу только у махровых некрофилов.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	86. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:10
	> Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного > места - беда всех CoW файловых систем. Так что ext4/xfs вполне > нормально живут при почти полной занятости дисков. Не, ну их тоже можно положить при желании. Удаление файла по 30 секунд на XFS? А я такое видел. Как сделать? Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то что и должны были :) > Т.е. ZFS не годится как фс для сервера бэкапов(точнее, требует держать на > сторадже меньше данных, чем его размер). Оно вообще "первый блин комом". У btrfs'ников лучше вышло.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	126. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 16:32
	Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то что получим на CoW FS даже с преаллокацией...
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	134. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 18:26
	> Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то > что получим на CoW FS даже с преаллокацией... Ну если уж на то пошло, у меня в таком виде XFS просто стирал 5-гиговый файл секунд по 30. Кстати том вообще забитым не был. Просто сдуру качнул торентов без преаллокации и подивился тому как все уныло работает :)
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	138. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 24-Авг-12, 19:06
	Я проморгал про удаление, и писал про то, что на CoW мы получим лапшу по всему диску хоть с преаллокацией, хоть без оной.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	143. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 13:26
	> Я проморгал про удаление, и писал про то, что на CoW мы > получим лапшу по всему диску хоть с преаллокацией, хоть без оной. А на обычных не-CoW ФС с преаллокацией не будет "лапши"? Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС, так как ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы. Разработчику преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора) и временем ответной реакции на начало скачивания торрент-контента. То есть грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового мусора, чтобы ФС точно выделила (10ГБ) желательно в соседних секторах диска этот самый объём пространства, которое со временем будет перезаписано настоящими байтами контента. Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют только LBA адресацией). И грамотный преаллокатор поэтому написать невозможно, как, кстати, и грамотный дефрагментатор с учётом расположения секторов на диске. Возможно лишь "балансировка" (оптимизация) метаданных для как можно скорейшего доступа к блокам с данными на диске. Условно скорость доступа к данным повышается, если их располагать как можно ближе к логическому началу диска. С этим знанием ведут работу всякого рода дефрагментаторы и оптимизируют свою работу ФС при записи данных, а также учитывают другие критерии расположения: как можно более монотонная последовательность адресации блоков одного файла, как часто используется файл и, ещё может быть, размер файла (бывают дефрагментаторы, которые нарочно двигают большие файлы в конец или в начало диска). Всё это по сути ускоряет доступ к набору данных, но не делает этот доступ идеально быстрым — LBA скрывает механические перемещения головок винчестера. Работа с метаданными намного более продуктивна (быстра) и позволяет сделать время доступа к данным одинаковым на всей поверхности диска, обеспечить достаточную скорость чтения и записи (примерно в два раза меньше максимально доступной для данного винчестера) по ВСЕЙ поверхности диска.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	144. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Авг-12, 13:33
	>> Я проморгал про удаление, и писал про то, что на CoW мы >> получим лапшу по всему диску хоть с преаллокацией, хоть без оной. > А на обычных не-CoW ФС с преаллокацией не будет "лапши"? Прикинь - нет, не будет. Файл аллоцируется по возможности линейно, и перезапись идёт без изменения местоположения данных. > Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС Фееричненько. > ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить > выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы. БГГГ. Прошу прощения, но у меня сейчас уши в трубочку завернутся от того, что вы тут пишете. КАКОЕ ОТНОШЕНИЕ группы одинаковых байтов имеют к преаллокации занимаемого файлом дискового пространства? Задача преаллокатора - выделить максимально линейные блоки для файла, а какие ГРУППЫ БАЙТОВ туда будут записаны - его не волнует. Равно как и диск xD > преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью > преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора) It's epic, bro xD > грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового > мусора И снова эпичное непонимание принципов работы FS. Суть в том, что всё "скидывание потока байтового мусора" сводится к ftruncate(file_handle, file_size). Нормальная FS при этом ничего, кроме метаданных, указывающих, где будет лежать файл, на диск не запишет. > Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют > только LBA адресацией). Последовательное чтение секторов на любых современных типах диска быстрее произвольного. Тчк. Всё остальное - лирика.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	146. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 13:51
	При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее. Используется так называемая "ленивая" преаллокация, когда ФС преаллокатору говорит, что пространство выделено, размер уменьшен на затребованную величину дискового пространства, а на самом деле сделана пометка в метаданных на "диапазон" (структуру) блоков который будет занят, а фактически же ещё нет. В это же время на ФС можно писать другие данные, никак не связанных с преаллокаченными. И эти данные могут расположиться физически в тех местах диска, которые могло бы заняться данным, место для которых оно заранее выделено в "диапазоне". По мере того, когда данные заполняют зарезервированный за ними "диапазон" блоков обновляется структура метаданных, его описывающая. ФС соотносит собственные занимаемые блоки с доступными LBA-адресами секторов на диске. Бывают ситуации, когда торрент-клиент выделил место на диске, что называется, впритык доступного пространства, ФС отрапортовала ему, что всё зарезервировано — можно качать, начинается скачка. Но после этого из какой-то программы записывается на диск файл чуть большего размера, чем оставшееся свободное место на диске — торрент-клиент уже не может докачать свой файл, так как место закончилось. Это случай из практики использования ZFS, преаллокация в Transmission включена.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	147. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Авг-12, 13:53
	> При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее. Чего? При преаллокации файла место распределяется ПОЛНОСТЬЮ. Иначе это не преаллокация. Только распределяется, а не перезаписывается. > Используется так называемая "ленивая" преаллокация Вы путаете преаллокацию со sparse-аллокацией. Более того, для sparse-аллокации вовсе не обязательно уменьшать счётчик свободного места. > Это случай из практики использования ZFS, преаллокация в Transmission включена. Что и логично. На ZFS преаллокация НЕВОЗМОЖНА в принципе, потому что это CoW. И любой записанный блок данных пишется не на жестко заданное место хранения, а куда попало.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	148. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 13:56
	>> При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее. > Чего? При преаллокации файла место распределяется ПОЛНОСТЬЮ. Иначе это не преаллокация. > Только распределяется, а не перезаписывается. Значит вот так оно распределяется, что не может обосновать свою предельность в небесконечном пространстве адресации винчестера. >> Используется так называемая "ленивая" преаллокация > Вы путаете преаллокацию со sparse-аллокацией. Более того, для sparse-аллокации вовсе не > обязательно уменьшать счётчик свободного места. Значит в ZFS используется sparse-аллокация. Счётчик свободного места при преаллокации из Transmission не уменьшается. >> Это случай из практики использования ZFS, преаллокация в Transmission включена. > Что и логично. На ZFS преаллокация НЕВОЗМОЖНА в принципе, потому что это > CoW. И любой записанный блок данных пишется не на жестко заданное > место хранения, а куда попало. Всё ясно.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	149. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Авг-12, 14:00
	> Значит вот так оно распределяется, что не может обосновать свою предельность в > небесконечном пространстве адресации винчестера. Это называется sparse allocation / sparse file, и к преаллокации не имеет никакого отношения. > Значит в ZFS используется sparse-аллокация. Верно. Механика работы аллокатора в CoW FS при записи очень сходна с механикой работы sparse-аллокаторов в традиционных FS. Фокус в том, что на ZFS невозможна статическая преаллокация. В итоге любой достаточно большой и записываемый произвольно файл превращается в лапшу.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	185. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 16:09
	> Прикинь - нет, не будет. Файл аллоцируется по возможности линейно, и перезапись > идёт без изменения местоположения данных. Ну это же изен. Он там крЮтыми концепциями оперирует. Поэтому представить себе как блоки в файле рапсполагаются и как это описывается - у него кишка тонка. > Фееричненько. А забавно он странный аллокатор ZFS отмазывает :) >> выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы. > БГГГ. Прошу прощения, но у меня сейчас уши в трубочку завернутся от ...обилия маркетингового буллшита :). Называя вещи своими именами. > максимально линейные блоки для файла, а какие ГРУППЫ БАЙТОВ туда будут > записаны - его не волнует. Равно как и диск xD Он не в состоянии осознать этот тривиальный факт, зато маркетинговый буллшит из него так и прет. > It's epic, bro xD По-моему, мы у него вызвали деление на ноль :) > Последовательное чтение секторов на любых современных типах диска быстрее произвольного. > Тчк. Всё остальное - лирика. Кроме SSD, у которых эта разница куда меньше. Как минимум при чтении.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	145. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 25-Авг-12, 13:37
	Кстати раз уж заговорили о преаллокаторах. На CoW преаллокация бессмысленна в принципе :)
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	157. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 01:57
	> получим лапшу по всему диску хоть с преаллокацией, хоть без оной. Ну мы ее слегка получим и на обычной ФС - совсем не факт что там есть непрерывный блок на 100500Гб :)
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	164. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 26-Авг-12, 10:12
	> Ну мы ее слегка получим и на обычной ФС - совсем не > факт что там есть непрерывный блок на 100500Гб :) Ну то слегка, будут выделены максимально линейные фрагменты. А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	186. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 16:26
	> Ну то слегка, будут выделены максимально линейные фрагменты. Вообще, если том на 99% забить, как этот чудик, с этим будет небогато. И даже классика начнет валиться в такой же по смыслу штопор. Менее сурово, но начнет. Я такое даже видел, хоть это и постараться надо. > А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб > (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность. Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в состоянии десяток seek в секунду сделать и будет читать на практически максимальной скорости. Но в торрентах бывает и блок 64К, вот тут с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут даже классика с экстентами начнет задыхаться от прорвы метаданных. Кстати чисто теоретически, CoW при преаллокации мог бы рассмотреть это как хинт: ага, они собираются писать в этот файл так и сяк. А давайте фрагменты стараться раскладывать друг за другом, в соответствии с их смещением в файле?! Ну то-есть даже CoW вполне мог бы резервировать непрерывный "виртуальный прообраз" файла (который заказали преаллокацией) и по нему раскладывать "паззл" из фрагментов по мере их поступления. Вполне себе CoW логикой. Благо, CoW логике все-равно куда именно фрагмент класть. Можно класть не абы как а чуть более удобно. Почему нет? Другое дело что не все возможные оптимизации аллокации реализованы вот сей момент.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	188. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 16:45
	>> А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб >> (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность. > Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в > состоянии десяток seek в секунду сделать и будет читать на практически > максимальной скорости. Но в торрентах бывает и блок 64К, вот тут > с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут > даже классика с экстентами начнет задыхаться от прорвы метаданных. Из личных наблюдений на ZFS торренты по-разному качаются Transmission и Deluge. Transmission мотает нервы очень сильно как на простой закачке/раздаче, так и на проверке. Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор ФС и проверка торрентов заметно быстрее, чем в Transmission. Transmission может буквально заблокировать рабочий десктоп так, что окна приложений перестанут перерисовываться, а скорость закачки упадёт. С Deluge такого не замечал.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	197. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 18:56
	> Из личных наблюдений на ZFS торренты по-разному качаются Transmission и Deluge. Учтя что они основаны на 2 напрочь разных либах и вероятно имеют разные дефолты - это не удивительно даже. > Transmission мотает нервы очень сильно как на простой закачке/раздаче, так и на проверке. А ты пробовал настраивать режимы преаллокации и размеры буферов? В UI такие тонкости не вынесены, т.к. у хомячков от них взорвется мозг. Но они есть и описаны в вике. > Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор > ФС и проверка торрентов заметно быстрее, чем в Transmission. Извини, гражданин, у меня трансмишн сугубо в сеть упирается, при том даже без особого твикинга. Откуда напрашивается вывод что что-то у вас в консерватории не то. > Transmission может буквально заблокировать рабочий десктоп так, > что окна приложений перестанут перерисовываться, Прости, если твоя операционка обделалась при обработке I/O или paging или при шедулинге процессов - это не вина апликух. По логике вещей, многозадачка должна шедулить ресурсы так чтобы всем равномерно доставалось. Вовремя отбирая бразды правления у приложений и передавая их другим. Кстати да, это означает что тебя укусил "линуксный" баг с неотзывчивостью системы при тяжелом I/O на медленном накопителе. Да, тот самый который ты так колоритно обcирал в пингвинах. Посмотрим хватит ли у тебя духу обругать уютную бсдшечку за ровно тот же самый баг с теми же симптомами :D. > а скорость закачки упадёт. С Deluge такого не замечал. Ну так и запишем: изен признался что его долбит тот же баг который он в пингвинах ругал :). Epic!
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	206. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 27-Авг-12, 00:02
	>> Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор >> ФС и проверка торрентов заметно быстрее, чем в Transmission. > Извини, гражданин, у меня трансмишн сугубо в сеть упирается, при том даже > без особого твикинга. > Откуда напрашивается вывод что что-то у вас в > консерватории не то. Оба клиента сеть загружают одинаково. Но когда много торрентов, Transmission начинает нервировать подлагиванием интерфейса, чего нет у Deluge. По-видимому, у разработчиков Transmission что-то не так в консерватории, раз нативный клиент так себя ведёт в отличии от интерпретируемого питоновского. >> Transmission может буквально заблокировать рабочий десктоп так, >> что окна приложений перестанут перерисовываться, > Прости, если твоя операционка обделалась при обработке I/O или paging или при > шедулинге процессов - это не вина апликух. Ну да, аппликухи (ВСЕ) белые и пушистые, одна операционка в их лагах виновата и должна оперативно подстраиваться под их требования. :)) А не жирно будет учитывать индивидуальные особенности кривых аппликух? Вон, в Windows учли "опыт" несовместимости и захардкодили в ядре особенности 16 битных популярных приложений, чтобы они не валились от правильной работы операционной системы. Так поступать так же? > По логике вещей, многозадачка > должна шедулить ресурсы так чтобы всем равномерно доставалось. Вовремя отбирая бразды > правления у приложений и передавая их другим. > Кстати да, это означает что тебя укусил "линуксный" баг с неотзывчивостью системы > при тяжелом I/O на медленном накопителе. Да, тот самый который ты > так колоритно обcирал в пингвинах. Посмотрим хватит ли у тебя духу > обругать уютную бсдшечку за ровно тот же самый баг с теми > же симптомами :D. В FreeBSD, в отличии от GNU/Linux, курсор мыши по крайней мере не застывает на месте. ;) >> а скорость закачки упадёт. С Deluge такого не замечал. > Ну так и запишем: изен признался что его долбит тот же баг > который он в пингвинах ругал :). Epic! Баг совсем другой — курсор не застывает, другие программы работают в отличие от...
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	219. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 09-Сен-12, 18:28
	> Оно вообще "первый блин комом". У btrfs'ников лучше вышло. /--- По ряду причин, я продолжил пользовать эту великолепную ФС на одной рабочей станции c -o compress,nospace_cache. Итак, постепенно фрагментация нарастала, тормоза усиливались. ls в директории с тысячей файлов уже занимал до секунды, открытие лога gajim - около 10 секунд. И наконец вчера btrfs впервые подала симптомы клинической смерти: no space left on device на полупустом разделе. >>> df -h Файловая система          Размер Использовано  Дост Использовано% Cмонтировано в /dev/mapper/rootfs           13G         9,7G  1,5G           87% / /dev/mapper/home2           135G          72G   60G           55% /home >>> sudo btrfs filesystem show Label: 'rootfs'  uuid: e9becd70-04a7-4de3-abfd-525446c1562b     Total devices 1 FS bytes used 9.20GB     devid    1 size 13.00GB used 13.00GB path /dev/dm-2 Label: 'home2'  uuid: 1efa8d6b-a4b9-4c68-abb2-acfd77a86d37     Total devices 1 FS bytes used 70.93GB     devid    1 size 134.98GB used 134.98GB path /dev/dm-1 Btrfs Btrfs v0.19 Удаление пары тысяч файлов не помогло, remount помог лишь ненадолго, а пользоваться файлухой дальше фактически невозможно. Выводы: 1. btrfs умирает за ~2,5 года ежедневного использования. 2. За это время в логах так и не обнаружено ни одной ошибки от драйвера btrfs. 3. Все оставшиеся на ФС файлы можно извлечь пост-мортем. shahid   (07.09.2012 17:45:35) ---/ http://www.linux.org.ru/forum/talks/8203698/page-1 Лучше? O_o
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	258. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 01:07
	> Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного > места - беда всех CoW файловых систем. Так что ext4/xfs вполне > нормально живут при почти полной занятости дисков. Может вам повезло ? На лоре полно людей у которых нормально жило а потом ... > (точнее, требует держать на > сторадже меньше данных, чем его размер). Админов которые не следуют данному правилу нужно гранать за проф непригодность.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	263. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Сержант Скотч on 06-Фев-13, 03:27
	>> (точнее, требует держать на >> сторадже меньше данных, чем его размер). > Админов которые не следуют данному правилу нужно гранать за проф непригодность. ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий старое). под это дело у вас хранилище на 20Тб. зачем в такой ситуации фс с cow?
	Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

	264. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 05:17
	>>> (точнее, требует держать на >>> сторадже меньше данных, чем его размер). >> Админов которые не следуют данному правилу нужно гранать за проф непригодность. > ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что > сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий > старое). под это дело у вас хранилище на 20Тб. зачем в > такой ситуации фс с cow? Если там не будет хотябы 1Tб свободно то скорость записи может так упасть что вся эта хрень подвиснет :)) и дефраг весьма полезен, в ночьное время :)) Интересно было бы увидеть тесты быстродействия фс сего этак через годик эксплуотации.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	265. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 06-Фев-13, 09:35
	>>> (точнее, требует держать на >>> сторадже меньше данных, чем его размер). >> Админов которые не следуют данному правилу нужно гранать за проф непригодность. > ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что > сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий > старое). под это дело у вас хранилище на 20Тб. зачем в > такой ситуации фс с cow? Именно. Абсолютно без пользы. Может быть месье нагулял предложит пользу от CoW в данном конкретном случае? Особенно интересует классический случай с fixed bitrate и преаллокацией по временным отрезкам.
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	267. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 06-Фев-13, 09:39
	> Может вам повезло ? На лоре полно людей у которых нормально жило > а потом ... Ты еще на хабре поищи...
	Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

	237. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:32
	>> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения. > lol'd > ну изен с 5 MBps с диска тут уже был Тут у нас у одного поциента навязчивые идеи ... Хотя до весны еще далеко.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	20. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:45
	> Неужели никому zfs не нужна что её полтора энтузиаста пилят? ...потому что btrfs будет даже лучше :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	42. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от кевин on 18-Авг-12, 19:57
	>> Неужели никому zfs не нужна что её полтора энтузиаста пилят? > ...потому что btrfs будет даже лучше :) бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому да выдавит зфс.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	63. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от kshetragia (ok) on 20-Авг-12, 05:35
	btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	113. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от Аноним (??) on 23-Авг-12, 09:14
	> btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего. Бсдишнеги такие бсдишнеги, всегда выдают желаемое за действительное. Без будущего - это хрень типа zfs, где даже экстентный аллокатор не осилили. По поводу чего оно получилось тормозиловом.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	238. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:33
	> btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего. Все гораздо печальнее, недостаточно оттестированную фс пихают в убунту, уже почти по дефолту ...
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	70. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 20-Авг-12, 12:27
	>>> Неужели никому zfs не нужна что её полтора энтузиаста пилят? >> ...потому что btrfs будет даже лучше :) > бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому > да выдавит зфс. Что вообще можно не осилить в zfs?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	135. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 24-Авг-12, 18:27
	> Что вообще можно не осилить в zfs? Экстентный аллокатор и TRIM например :)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	239. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:35
	>> Что вообще можно не осилить в zfs? > Экстентный аллокатор и TRIM например :) Первое сферический конь в вакуме сомнительной нужности, второе если следовать рекомендациям сана и оставлять 5-10% дискового пространства неразмеченным тоже ... нужно как первое :))
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	247. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 07:20
	> если следовать рекомендациям сана к некрофилам
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	252. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 19:37
	>> если следовать рекомендациям сана > к некрофилам И это пишет человек сидящий под виндовс :))
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

	254. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 20:01
	> И это пишет человек сидящий под виндовс :)) Why not? (c) В отличие от винды санка - 100% RIP.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	87. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:15
	> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому > да выдавит зфс. Для начала, они посмотрели на основные продолбы ZFS, в частности общую тормознутость. И сделали вместо блочного аллокатора экстентный. За что воздалось - по бенчам сразу видно кто слоупок.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	240. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:36
	>> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому >> да выдавит зфс. > Для начала, они посмотрели на основные продолбы ZFS, в частности общую тормознутость. > И сделали вместо блочного аллокатора экстентный. За что воздалось - по > бенчам сразу видно кто слоупок. Бенци в студию, фороникс не предлагать :)) ЗЫ Если екперимент имеет научную основу он повторяем ;)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	259. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 01:09
	> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому > да выдавит зфс. Ага сначал вдавит а потом ... может быть :)) Это фс разных систем. Под linux zfs экзотика, не более ... Под bsd btrfs ? Привет из паралельной вселенной ?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	66. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 20-Авг-12, 11:18
	Вообще ее пилят Lawrence Livermore National Laboratory для своего IBM Sequoia (топовый суперкомпьютер на сегодня), правда они я так понял больше заинтересованы в zpool, чтобы на нее люстру положить. http://www.youtube.com/watch?v=c5ASf53v4lI http://public.dhe.ibm.com/systems/deepcomputing/LLNL_-_Sequo...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+2 +/–
Сообщение от Аноним (??) on 18-Авг-12, 10:59
Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР??
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 11:28
	> Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР?? Толстота!..
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от user (??) on 18-Авг-12, 11:28
	Улыбнуло ))
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Антон (??) on 18-Авг-12, 12:07
	> а где найти ZFS пакет для Виндус ХР Пополните лицевой счет своего мобильного телефона. Отправьте на номер 7490 SMS с произвольной суммой не менее 10УЕ, данная сумма будет зачислена на счет почтальона который принесёт вам ZFS пакет для вашего дистрибутива Виндус (доставка в день заказа).
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	28. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:58
	7490 смс по 10 баксов - это как-то довольно дофига :)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 18-Авг-12, 13:02
	colinux.org
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 14:46
	> Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР?? На сайте ubuntu.com :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	52. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от gnum on 19-Авг-12, 07:26
	Там же, где btrfs. Абзацем выше ссылка. Там попросят регистрацию, но она не обязательная, можно просто нажать "пропустить".
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

19. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
Сообщение от Аноним (??) on 18-Авг-12, 14:33
Для Федоры не сделают никак рпм https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от xxx (??) on 18-Авг-12, 14:49
	> Для Федоры не сделают никак рпм > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991 Там предпочитают собвственный велопарк соденржать.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	43. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от кевин on 18-Авг-12, 19:58
	> Для Федоры не сделают никак рпм > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991 для федоры не нужно. федора ядра бсд в репах не держит.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	88. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:17
	> для федоры не нужно. федора ядра бсд в репах не держит. А оно каким боком, простите?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	108. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Авг-12, 19:34
	>> для федоры не нужно. федора ядра бсд в репах не держит. > А оно каким боком, простите? А оно лишь бы ляпнуть и неважно что.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

27. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–3 +/–
Сообщение от Аноним (??) on 18-Авг-12, 14:57
Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 16:40
	> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще чтение. правда для чтения хватит fuse
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	39. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от ананим on 18-Авг-12, 17:45
	а зачем? даже если вы винты с zfs заполняете данными и складируете в уголке, то можно с ливсд опенсоляры (и клонов) загрузиться. при чём в виртуалке. у меня все сервера переведены по ксен - запустил виртуалку, подсоединил винт и всё. ну, для десктопа сойдёт и виртуалбокс. Зыж кстати, являясь гентушником, пробовал также сабж и однозначно остановился у себя на руте ноута на бтр. с ноября 2011 живу с бтр и не жалуюсь. По скорости и экономии ресурсов намного лучше zfs и совсем немного хуже ext4. Cварганил даже себе замену тайм-машин. :D И даже лучше - не нужен отдельный винт, любой снэпшот равноправен любому субволому - т.е. В любой момент с него можно перезагрузиться и использовать дальше как рут и намного быстрее создаются. А всё остальное как в маке (снепшоты создаются каждый час за последние сутки, каждые сутки за последнюю неделю, какждую неделю за последние 3-и месяца, каждый месяц за последний год). Так вот, на ноуте гентушника(!!!) - никаких проблем (правда я сам составляю график обновлений ядра и бтрфс-прогс по спискам рассылки. Ну и старые ливсд нельзя использовать)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	241. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:39
	>[оверквотинг удален] > ext4. > Cварганил даже себе замену тайм-машин. :D > И даже лучше - не нужен отдельный винт, любой снэпшот равноправен любому > субволому - т.е. В любой момент с него можно перезагрузиться и > использовать дальше как рут и намного быстрее создаются. > А всё остальное как в маке (снепшоты создаются каждый час за последние > сутки, каждые сутки за последнюю неделю, какждую неделю за последние 3-и > месяца, каждый месяц за последний год). Так вот, на ноуте гентушника(!!!) > - никаких проблем (правда я сам составляю график обновлений ядра и > бтрфс-прогс по спискам рассылки. Ну и старые ливсд нельзя использовать) А я предпочитаю на пляж ходить и с девушками знакомиться ...
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	248. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 05-Фев-13, 07:21
	> А я предпочитаю на пляж ходить и с девушками знакомиться ... Если ты это делаешь так, как здесь пытаешься обсуждать ZFS - я тебе искренне соболезную - ты все руки наверняка уже до мозолей стёр.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	257. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 20:30
	>> А я предпочитаю на пляж ходить и с девушками знакомиться ... > Если ты это делаешь так, как здесь пытаешься обсуждать ZFS - я > тебе искренне соболезную - ты все руки наверняка уже до мозолей > стёр. Друг мой, я нехочу ставить диагноз без фотографии, но ваши ассоциации - то "в темноте под одеялом" то "накатить", теперь вот "руки до мозолей стёр" наводят на некоторые размышления.  :))) Вы берегите себя :)) ...
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	36. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 18-Авг-12, 16:43
	> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще Нет уж спасибо, я выберу ZFS.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 18-Авг-12, 17:29
	Крисс очень опечален этим :/
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	89. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:19
	> Нет уж спасибо, я выберу ZFS. Скатертью дорожка. Правда вот btrfs шустрее и задизайнен лучше. Но выбирать кактус по вкусу - неотъемлимое право каждого индивида.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	47. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 19-Авг-12, 00:01
	> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще А Btrfs ещё пилят?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	54. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–4 +/–
	Сообщение от ананим on 19-Авг-12, 12:10
	а ты подпишись на списки рассылки и сам всё увидишь. http://vger.kernel.org/vger-lists.html http://vger.kernel.org/vger-lists.html#linux-btrfs если кратко - гораздо больше чем в сабже и бсд вместе взятых. а если учесть, что и сабж, и бсд подходят к порогу того что открыто, то вообще будущее zfs в них в тумане.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	64. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от iZEN (ok) on 20-Авг-12, 08:18
	> гораздо больше чем в сабже и бсд вместе взятых. Из свежего: http://www.spinics.net/lists/linux-btrfs/msg18435.html "Date: Wed, 15 Aug 2012 19:28:16 +0200 Hi, I have a strange problem with a btrfs partition : after an error, btrfs was forced readonly. So I try to umount it, to launch btrfsck, but it doesn't work : root! sofia:~# umount /backup/ root! sofia:~# btrfsck /dev/vg-sofia/backup /dev/vg-sofia/backup is currently mounted. Aborting. root! sofia:~# umount /backup/ umount: /backup/: not mounted root! sofia:~# btrfsck /dev/vg-sofia/backup /dev/vg-sofia/backup is currently mounted. Aborting. root! sofia:~#" And I can't remount it : root! sofia:~# mount /backup/ mount: /dev/mapper/vg--sofia-backup already mounted or /backup busy Or access to the content : root! sofia:~# ls /backup/ root! sofia:~# It's on a v3.4.7 kernel, with btrfs-tools version 0.19+20120328-7 (from Debian unstable). What should I do ? Reboot ? Thanks, Olivier" Правда весело?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	71. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 20-Авг-12, 12:42
	> Правда весело? Вообще любую фс можно добить, но с бтрфс оно обычно случается достаточно легко на ровном месте. Я когда с ней игрался, умудрился фс за полчаса довести до состояния когда ничего штатное не помогает. С zfs сложнее и в крайнем случае (баг zfsonlinux) данные достаются соляркой.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	90. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:21
	> Вообще любую фс можно добить, но с бтрфс оно обычно случается достаточно > легко на ровном месте. Ну так у бздунов по первости тоже воплей было мама не горюй. Вплоть до дедлока всей машины на некоторых операциях.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	82. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от anonym on 20-Авг-12, 23:44
	>[оверквотинг удален] > root! sofia:~# mount /backup/ > mount: /dev/mapper/vg--sofia-backup already mounted or /backup busy > Or access to the content : > root! sofia:~# ls /backup/ > root! sofia:~# > It's on a v3.4.7 kernel, with btrfs-tools version 0.19+20120328-7 (from Debian unstable). > What should I do ? Reboot ? > Thanks, > Olivier" > Правда весело? Изя, давай будем честными, в BSD с ZFS на шестой и седьмой ветке тоже проблем было будь здоров.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	93. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от kshetragia (ok) on 21-Авг-12, 06:48
	О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для не работающего толком поделия по сравнению с уже работающим. А при проблемах в "шестой-седьмой ветке" так же дружно кидались какашками "оно не работает"
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	116. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 23-Авг-12, 21:44
	> О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо > большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для > не работающего толком поделия по сравнению с уже работающим. Про это поделие между прочим автор порта zfs считает более совершенным технически и полагает что оно зарулит ZFS со временем. И кстати ваши ZFS вообще не писали. А всего лишь привинтили халяву от саней. Сами вы вообще такого масштаба проект не поятнете нифига. А пингвиноиды вот потянули.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	140. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 25-Авг-12, 12:25
	>> О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо >> большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для >> не работающего толком поделия по сравнению с уже работающим. > Про это поделие между прочим автор порта zfs считает более совершенным технически > и полагает что оно зарулит ZFS со временем. И кстати ваши > ZFS вообще не писали. А всего лишь привинтили халяву от саней. > Сами вы вообще такого масштаба проект не поятнете нифига. А пингвиноиды > вот потянули. Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :)) Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил из Oracle и, скорее всего, проект ему уже малоинтересен.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	158. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 02:01
	> Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :)) Они btrfs надизайнили с нуля. Получше чем. > Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил > из Oracle и, скорее всего, проект ему уже малоинтересен. Прости, а ничего что он свалили в контору которая занимается хранением данных? :) Проектом он как я понимаю по прежнему занимается весьма даже. Кроме того там ща коммитит толпень народа. Так что твоя трогательная забота о процветании проекта просто умиляет :)
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	172. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 10:32
	>> Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :)) > Они btrfs надизайнили с нуля. Получше чем. Не "они", а он. Не "получше", а как захотелось ему. RAID-5 и -6 до сих пор не осилил. +детские непонятки с отмонтированием. Для продакшена Btrfs использовать не рекомендуется. >> Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил >> из Oracle и, скорее всего, проект ему уже малоинтересен. > Прости, а ничего что он свалили в контору которая занимается хранением данных? Контора Стива Возняка, по слухам, занимается мобильными девайсами. Автор Btrfs уже там. > :) Проектом он как я понимаю по прежнему занимается весьма даже. Не, не слышал. > Кроме того там ща коммитит толпень народа. Не, не знаю никого. > Так что твоя трогательная забота о процветании проекта просто умиляет :) Признай уже, что Btrfs загибается от недостатка финансирования и мозгов.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	195. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 17:55
	> Не "они", а он. Насколько я помню, там была "помощь зала" :). В частности модификацию b-деревьев подсказал какой-то другой перец, ну и так далее. > Не "получше", а как захотелось ему. Ему захотелось посмотреть на существующие дизайны и выдернуть лучшее из них, постаравшись не получить явных минусов. Более-менее получилось вроде. > RAID-5 и -6 до сих пор не осилил. Ты так говоришь как будто кодит там один Крис. > +детские непонятки с отмонтированием. Что-то не заметил "непоняток". В чем они состоят? oO > Для продакшена Btrfs использовать не рекомендуется. Тем не менее, его внедряют ынтырпрайзные дистры уже. И даже поддержку декларируют. >> Прости, а ничего что он свалили в контору которая занимается хранением данных? > Контора Стива Возняка, по слухам, занимается мобильными девайсами. Автор Btrfs уже там. Насчет слухов не знаю, т.к. не бабка на лавочке. А в описании конторы явно задекларировано что они занимаются современными сторажами. Логично что Крис туда свалил :) >> :) Проектом он как я понимаю по прежнему занимается весьма даже. > Не, не слышал. Ну я понимаю, ты не в состоянии лог коммитов в кернель посмотреть до того как языком молоть. Поэтому [как обычно] с умным видом втираешь полную чушь :) >> Кроме того там ща коммитит толпень народа. > Не, не знаю никого. Да кто бы сомневался что ты только языком молоть умеешь. А посмотреть лог коммитов в git - это уже слишком сложно для таких как ты. Однако процесс разработки намного удобнее оценивать не по трепанию языком изенов а по логам коммитов. Ну вот например, в готовящемся ядре 3.6 сделали поддержку send/receive. Как раз кто-то из ZFSников лишний раз заткнется :) >> Так что твоя трогательная забота о процветании проекта просто умиляет :) > Признай уже, что Btrfs загибается от недостатка финансирования и мозгов. Признай уже что недостаток мозгов не позволяет тебе посмотреть логи коммитов в эту подсистему линуксного кернеля. Так что долго тебе придется ждать пока он загнется. Если ты не понял, оно надо толпени народа. И по этому поводу загибаться не собирается. Там его такая толпень нынче пилит что многие другие позавидуют.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	196. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 26-Авг-12, 18:22
	> Что-то не заметил "непоняток". В чем они состоят? oO В этом: http://www.opennet.me/openforum/vsluhforumID3/86056.html#64 >>> Так что твоя трогательная забота о процветании проекта просто умиляет :) >> Признай уже, что Btrfs загибается от недостатка финансирования и мозгов. > Признай уже что недостаток мозгов не позволяет тебе посмотреть логи коммитов в > эту подсистему линуксного кернеля. Нет. Мне не хочется тратить время на всякую недоделанную чушь. > Так что долго тебе придется ждать пока > он загнется. Если ты не понял, оно надо толпени народа. Oracle сама Btrfs не нужна == не надо энтерпрайзу с большими базами и клиентам Oracle. Это предельно чётко и ясно. Для мобильных девайсов Btrfs, возможно, будет ещё ничего, может заменит морально отсталую Ext4. Но пока даже в этом подвижек никаких. > И > по этому поводу загибаться не собирается. Там его такая толпень нынче > пилит что многие другие позавидуют. Не пугай меня.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	198. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 26-Авг-12, 19:16
	> В этом: http://www.opennet.me/openforum/vsluhforumID3/86056.html#64 О, по одному случаю да еще на кернеле который на почти 2 версии старее текущего изен делает глобальные выводы. Да чтоб ты бзди так же оценвал, а? :) > Нет. Мне не хочется тратить время на всякую недоделанную чушь. Тогда не понятно зачем засорять форум откровенной дезой. Пользуйся себе своей не-чушью и трать время на чтение файлов со скоростью 6мб/сек, мне не жалко. А для себя я вообще такие скорости приемлимыми в принципе не считаю. > Oracle сама Btrfs не нyжна == не надо энтерпрайзу с большими базами Вообще, нужна. Как тонкая прослойка между их БД и накопителями. Впрочем, участие оракла сводилось к целому Крису. Который никуда не делся и занимается тем же чем и занимался. А клиенты оракля вообще никакого влияния на процесс не оказывают ;) > и клиентам Oracle. Это предельно чётко и ясно. ...и наверное именно поэтому оракель декларирует поддержку btrfs в unbreakable? Как-то твоя красивая теория не стыкуется с наблюдаемыми на деле фактами, что намекает ;) > Для мобильных девайсов Btrfs, возможно, будет ещё ничего, может заменит > морально отсталую Ext4. Но пока даже в этом подвижек никаких. Смотрите, известный эксперт-аналитик по ФС и их развитию выступает с докладом. Будет забавно почитать это через годик-другой :) >> И по этому поводу загибаться не собирается. Там его такая толпень нынче >> пилит что многие другие позавидуют. > Не пугай меня. Да чего тебя пугать, ты сам себе такое пугало что тебя пугать даже и не требуется. Ну вот например ты сам себе спровоцировал эквивалент обcираемого тобой "линуксного" бага с плохой отзывчивостью системы. И сам признался в этом. По логике вещей ты должен обругать fbsd за то что там есть такой паскудный баг, который ты так крыл в линуксах :)
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	260. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 01:16
	> Признай уже, что Btrfs загибается от недостатка финансирования и мозгов. Оракл похерил ... и вероятно присматривает чтоб кто случайно не помог.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	208. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от kshetragia (ok) on 27-Авг-12, 13:07
	Вот когда зарулит тогда и поговорим. Хотя я подозреваю всё будет как обычно. Работать будет но... то лапы мерзнут, то хвост отваливается.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	99. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от iZEN (ok) on 21-Авг-12, 16:30
	> Изя, давай будем честными, в BSD с ZFS на шестой и седьмой > ветке тоже проблем было будь здоров. ("Изя" это кто?) На шестой ветке разве есть поддержка ZFS? Что-то меня гложут сомнения в этом. ZFS на седьмой ветке была чисто экспериментальной, а готовой к промышленному использованию эта ФС объявлена лишь в восьмой версии FreeBSD.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	114. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	–3 +/–
	Сообщение от Аноним (??) on 23-Авг-12, 09:17
	> ("Изя" это кто?) Это ты. //информирует Кэп > эта ФС объявлена лишь в восьмой версии FreeBSD. ...что не мешало ей ловить локапы + не был нормально реализован sendfile(). Такой продакшн.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	242. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:39
	>> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще > А Btrfs ещё пилят? Да, увы ...
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

46. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+1 +/–
Сообщение от Buy (ok) on 18-Авг-12, 22:05
> достаточно стабилен для использования энтузиастами Вот уж эти выражения ))) Так да или нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	83. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от anonym on 20-Авг-12, 23:45
	> Вот уж эти выражения ))) Так да или нет? Да, но >энтузиастами То есть в продакшн не годится пока что.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

49. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
Сообщение от Аноним (??) on 19-Авг-12, 02:51
How to install Fedora on top of ZFS http://rudd-o.com/linux-and-free-software/installing-fedora-...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
Сообщение от Аноним (??) on 19-Авг-12, 02:53
How ZFS continues to be better than btrfs http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+2 +/–
	Сообщение от AlexAT (ok) on 19-Авг-12, 12:22
	> How ZFS continues to be better than btrfs > http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-... Видно, что человек не понимал половину из того, о чём пишет...
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	58. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 19-Авг-12, 15:55
	ага. >btrfs does not allow you to organize subvolumes.  Subvolumes appear where you created them (whether through creation or snapshotting), and you can't move or rename them. That's it. ха! Джаст mv ит, люк. >Rollback to a snapshot >To roll back to a snapshot, you simply need to change its name to the name that ubuntu mounts, using >sudo mv /mnt/@ /mnt/@_badroot >sudo mv /mnt/@_snapshot /mnt/@ >and reboot. что называется сравните с простынёй >Recovering the ZFS Root Pool or Root Pool Snapshots http://docs.oracle.com/cd/E19082-01/817-2271/ghzvz/index.html
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	68. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 20-Авг-12, 11:50
	>[оверквотинг удален] > ха! > Джаст mv ит, люк. >>Rollback to a snapshot >>To roll back to a snapshot, you simply need to change its name to the name that ubuntu mounts, using >>sudo mv /mnt/@ /mnt/@_badroot >>sudo mv /mnt/@_snapshot /mnt/@ >>and reboot. > что называется сравните с простынёй >>Recovering the ZFS Root Pool or Root Pool Snapshots > http://docs.oracle.com/cd/E19082-01/817-2271/ghzvz/index.html Да бросьте вы. Восстановление системы на ZFS из снапшота гораздо проще: zfs rollback -rf poolname/ROOT@fixpoint shutdown -r now И никакой простыни!
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	209. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 28-Авг-12, 20:37
	идиотом прикидываешься? мне надо просто перегрузиться в другой субволум, а тебе провести процесс восстановления(!!!). который ещё не факт что закончится успешно.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	213. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 28-Авг-12, 21:17
	ззыж и да, врёшь уже откровенно (или такой знаток) смотрим доку http://docs.oracle.com/cd/E19082-01/817-2271/ghzvk/index.html How to Roll Back Root Pool Snapshots From a Failsafe Boot # zpool set listsnapshots=on rpool # zfs snapshot -r rpool/ROOT@0311 # zfs list Shutdown the system and boot failsafe mode. ВАУ!!!!!!!!!!! Перезагрузка в failsafe mode!!!! далее: Rollback the individual root pool snapshots. # zfs rollback -rf rpool/ROOT@0311 Reboot back to multiuser mode. # init 6 Т.е., пилят, 2-е(!!!) перезагрузки. Ты этого не знал? или нагло соврал?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	214. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 29-Авг-12, 21:38
	>[оверквотинг удален] > # zfs list > Shutdown the system and boot failsafe mode. > ВАУ!!!!!!!!!!! Перезагрузка в failsafe mode!!!! > далее: > Rollback the individual root pool snapshots. > # zfs rollback -rf rpool/ROOT@0311 > Reboot back to multiuser mode. > # init 6 > Т.е., пилят, 2-е(!!!) перезагрузки. > Ты этого не знал? или нагло соврал? Во FreeBSD достаточно перевести систему в Single User Mode ("shutdown now"), сделать zfs rollback на сохранённые снапшоты системных ФС (у меня это корень и /usr) и перезагрузиться. Делал несколько раз, проблем не испытывал. В Solaris не знаю как, так что не претендую на всеобъемлемость.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	215. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 02-Сен-12, 14:43
	>делал несколько раз, проблем не испытывал дай угадаю - данный сервер работает только для тебя одного (бесусловно-любимого) зыж не, в линухе тоже можно перейти в синглмод, смонтировать рут в ридонли, потом смонтировать в рут другой субволум и перейти в init 3. а можно просто смонтировать в другую точку монтирования и вытащить что нужно. это не отменит того, что ты делаешь rollback данных, а я просто монтирую. при этом случай кернел-паник и не_возможность загрузки тобой вообще не рассматривается. ну грузится с рут, не монтируется вообще. у меня есть старый, проверенный субволум, у тебя нет.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	216. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok) on 03-Сен-12, 16:25
	> при этом случай кернел-паник и не_возможность загрузки тобой вообще не рассматривается. > ну грузится с рут, не монтируется вообще. > у меня есть старый, проверенный субволум, у тебя нет. Так как у меня система сама на ZFS, то kernel panic при невозможности загрузиться с ZFS не возникает (что логично). В этом случае используется загрузочная флешка для восстановления системы — просто загружается система восстановления и выясняется причина невозможности штатной загрузки. Было такое: невозможно загрузиться. Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld) и система недоустановилась; остались снимки предыдущего образа рабочей ОС. Решение проблемы: гружу с флешки систему восстановления, импортирую пул в определнную точку монтирования, разбираюсь с занятым местом, делаю zfs rollback файловым системам старого образа; перезагружаюсь уже в работающую систему.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	217. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 03-Сен-12, 17:48
	> Было такое: невозможно загрузиться. > Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld) Печалька пионерская... Нормальным binary-based дистрибутивам такой ахтунг неведом. Ну да, для таких извращений CoW нужен в принципе, потому что шанс угробить систему любым чихом неиллюзорен.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	262. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 01:22
	>> Было такое: невозможно загрузиться. >> Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld) > Печалька пионерская... Нормальным binary-based дистрибутивам такой ахтунг неведом. > Ну да, для таких извращений CoW нужен в принципе, потому что шанс > угробить систему любым чихом неиллюзорен. Это вы про обновление grub2 после которого система может не подняться ? :)) Помню помню ... :))
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	266. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok) on 06-Фев-13, 09:38
	> Это вы про обновление grub2 после которого система может не подняться ? > :)) Помню помню ... :)) У вас не поднялась? У меня за последние 5 лет ни одной проблемы с GRUB. ЧЯДНТ?
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	218. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 06-Сен-12, 07:06
	> Решение проблемы: гружу с флешки систему восстановления, импортирую пул в определнную точку  монтирования, разбираюсь с занятым местом, делаю zfs rollback файловым системам старого образа; перезагружаюсь уже в работающую систему. вот и я говорю - жесть. я же просто монтирую снепшот. зыж ну глупо же отрицать очевидное - концепция что снэпшот не что иное, как субволум гораздо прогрессивнее, удобнее и безопаснее. ззыж >Так как у меня система сама на ZFS, то kernel panic при невозможности загрузиться с ZFS не возникает (что логично). попахивает "махровым" фанатизмом.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	243. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 05-Фев-13, 01:41
	>[оверквотинг удален] >> Rollback the individual root pool snapshots. >> # zfs rollback -rf rpool/ROOT@0311 >> Reboot back to multiuser mode. >> # init 6 >> Т.е., пилят, 2-е(!!!) перезагрузки. >> Ты этого не знал? или нагло соврал? > Во FreeBSD достаточно перевести систему в Single User Mode ("shutdown now"), сделать > zfs rollback на сохранённые снапшоты системных ФС (у меня это корень > и /usr) и перезагрузиться. Делал несколько раз, проблем не испытывал. В > Solaris не знаю как, так что не претендую на всеобъемлемость. Чесно говоря необходимость заказа KVM не радует, а доверять это одминоДЦ уж тем более ...
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	73. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 20-Авг-12, 16:10
	> ага. >>btrfs does not allow you to organize subvolumes.  Subvolumes appear where you created them (whether through creation or snapshotting), and you can't move or rename them. That's it. ключевое слово subvolumes.. #zpool import home #zfs create home/john #zfs create home/root #zfs set mountpoint=/root #zfs list home/john  /home/john home/root  /root #mount /dev/btrfs-home /home #cd /home #btrfs subvolume create john #btrfs subvolume create root #mv ./root /root индейская национальная изба - фигвам называется! Да, можно отдельно смонтировать subvolume в /root, но как потом всем этим управлять, особенно учитывая что по имени можно монтировать только подразделы в корне, остальное только по subvolumeid. На первый взгляд это мелочь, но так понемногу и набирается до того, что что-то сложнее одной фс уже неуправляемо.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	210. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 28-Авг-12, 20:47
	>Да, можно отдельно смонтировать subvolume в /root, но как потом всем этим управлять легко # btrfs subvolume list / ID 256 top level 5 path ext2_saved ID 630 top level 5 path rootsubvol ID 769 top level 5 path rootsubvol_before_bumblebee_28.08.2012 # btrfs subvolume get-default / ID 630 top level 5 path rootsubvol # mkdir /media/btrfs/111 # btrfs subvolume create /media/btrfs/111/NAME Create subvolume '/media/btrfs/111/NAME' # btrfs subvolume list / ID 256 top level 5 path ext2_saved ID 630 top level 5 path rootsubvol ID 769 top level 5 path rootsubvol_before_bumblebee_28.08.2012 ID 770 top level 5 path 111/NAME >особенно учитывая что по имени можно монтировать только подразделы в корне, остальное только по subvolumeid. враньё # mkdir /111 # mount -t btrfs -o subvol=111/NAME /dev/sda6 /111 # mount /dev/sda6 on /111 type btrfs (rw,subvol=111/NAME) бтр вообще по структуре куда более юниксвейна. а значит вариантов работы с ней гораздо больше и на любой вкус.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	212. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 28-Авг-12, 21:09
	ззыж >индейская национальная изба - фигвам называется! чё за бред? ну создайте два субволума в zfs с одинаковыми именами, удачи. зыж более идиотского примера привести наверное было бы трудно.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	72. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Elhana (ok) on 20-Авг-12, 12:46
	>> How ZFS continues to be better than btrfs >> http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-... > Видно, что человек не понимал половину из того, о чём пишет... Этот товарисч делал zfs-fuse если что...
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	91. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (??) on 21-Авг-12, 02:23
	> Этот товарисч делал zfs-fuse если что... ... и он сказал еще и вот это: (при том последнее он добавил видимо для самоуспокоения) >  btrfs is algorithmically better, btrfs has features that ZFS does not have, btrfs is > going to win over ZFS at some unspecified point in the future.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	211. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от ананим on 28-Авг-12, 21:03
	> Этот товарисч делал zfs-fuse если что... Тогда понятно почему он в бтр такие ляпы делает
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	261. "Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok) on 06-Фев-13, 01:19
	>> How ZFS continues to be better than btrfs >> http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-... > Видно, что человек не понимал половину из того, о чём пишет... Это нужно читать как алекс непонял и половины написанного :))
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

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

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