Доступен (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
Неужели никому zfs не нужна что её полтора энтузиаста пилят?
В целом так оно и есть. Слишком нишевая FS.
ликбеза ради, расскажите или скиньте урл, где её основное применение и почему?
Лично я использую ZFS на корпоративном сетевом хранилище на базе дистрибутива NexentaStor
Для меня "киллер-фичи":
- очень удобные снапшоты
- дедупликация
- высокая надёжностьZFSonLinux использую для работы с ZFS-дисками на рабочей станции. Например - если нужно вытянуть данные с прошлогоднего диска.
> - высокая надёжностьЕсли у тебя ещё ничего не сломалось, это не значит, что это работает.
Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим.
павлин, вставь пальцы в розетку, если один раз не поможет, можешь повторить раз 20... посмотрим насколько ты у нас надежный, или просто п......л
> павлин, вставь пальцы в розетку, если один раз не поможет, можешь повторить
> раз 20... посмотрим насколько ты у нас надежный, или просто п......лДа ладно тебе, нормальный стресстест на глючность и выживаемость. У хороших конструкций - пятикратный запас прочности :)
>> - высокая надёжность
> Если у тебя ещё ничего не сломалось, это не значит, что это
> работает.
> Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим.ты не поверишь - живет, и живет еще и не при таких чудесах (raidz, 3-и диска): глючил контроллер, причем начал это делать, в момент, когда 1Т диски в массиве стал заменять на 3Т диски, высыпались то один, то другой, а то и третий диски из системы, вечные таймауты от дисков, не возможность записать/прочитать с рандомного диска, висла система, саморебуталась, и так в течении месяца, в конце еще вставили в новый контроллер два из трех дисков и один из этих двух дисков уже как дня три был не в массиве из-за очередной порции таймаутов, в итоге зфс выжил, все данные переехали на 3Т диски и расширилось хранилище. За все это время (пока думал, что причиной диски и менял на другие, затем корзинки со шнурками и только потом уже контроллер), из 11млн существующих инодов было потеряно два файла.
>> - высокая надёжность
> Если у тебя ещё ничего не сломалось, это не значит, что это
> работает.Это вы про EXT4 ?
> Повыдергивай своё хранилищо раз 20 из розетки, а там посмотрим.UFS2 S+J ради эксперимента уже наверно 40 ребутов ...
> ликбеза ради, расскажите или скиньте урл, где её основное применение и почему?Виртуализация, VCS, некоторые файлопомойки. Усё. Погуглите на тему CoW - поймёте, почему оно плохо в других условиях.
> Виртуализация,У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. Может не обязательно так эпично ламерить?
> VCS,
Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожее по смыслу делает еще и ФС, получается двойная работа, вам так не кажется?
> некоторые файлопомойки.
В случае ZFS только некритичные к скорости и малоактивные - дефрагера нету.
> Усё. Погуглите на тему CoW - поймёте, почему оно плохо в других условиях.
Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо и почему. Навскидку - базам данных это может быть не подарок без пересмотра журнальной логики оных. Ну и все вроде как.
> У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска.Обычно - это где, поконкретнее. Да еще и с CoW. Расскажите-ка.
>> VCS,
> Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожееВы под VCS подразумеваете только то, что можно в сети скачать?
> Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо
Практически для любых - гиперфрагментация. В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет.
> Обычно - это где, поконкретнее. Да еще и с CoW. Расскажите-ка.Практически у всех виртуализаторов умеющих снапшоты это сделано как тот или иной вид технологии основанной на CoW. Например: qcow/qcow2 в qemu/kvm. Как бы название формата прозрачно намекает. Ну и легион других. А по другому логика множественного снапшотирования не очень то и получается в нормальном виде.
>>> VCS,
>> Они опять же сами реализуют версионирование, ибо должны работать везде. Когда похожее
> Вы под VCS подразумеваете только то, что можно в сети скачать?Я под VCS понимаю системы контроля версий.
>> Нет, лучше здесь расскажите по полочкам. Для каких именно ворклоадов это плохо
> Практически для любых - гиперфрагментация.Во первых, если записи мало + есть дефрагер, это проблемой не будет. Во вторых, это tradeoff. Взамен ФС позволяет писать новые метаданные и данные только 1 раз, а не 2 - избавившись от отдельной фазы журналирования. Ну и на набирающих популярность SSD этот фактор менее критичен.
> В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет.
При интенсивной записи - с лихвой окупится: в лучшем случае будет скорость записи как у нежурналируемой ФС + надежность полностью журналируемой, чего журналирующим в общем случае не светит из-за двойной записи. Правда у именно ZFS дизайн с биением на блоки без крупных экстентов - тормознутый, да. Но в btrfs это учли. У них и garbage collector с дефрагером совместили, что логично. И экстенты поюзали по полной программе. По поводу чего оно и делает ZFS в куче бенчей. А сам ZFS штука на любителя. Ну вон iZEN живет с 6мб/сек с диска. Потому что забил тома в хламину и CoW совсем зашился :)
> Практически у всех виртуализаторов умеющих снапшоты это сделано как тот или иной
> вид технологии основанной на CoW.Это сделано обычно, как навесной механизм. Единственная более-менее известная среда, умеющая действительно CoW FS - это Parallels Virtuozzo.
> Я под VCS понимаю системы контроля версий.У меня есть система контроля версий конфигов оборудования, построенная - сюрпрайз - на обычных файлах. В качестве бэкбона используется GIT. Как только допилят BTRFS - начну использовать BTRFS, ибо зачем городить огород.
> Во первых, если записи мало + есть дефрагер, это проблемой не будет.
У ZFS есть дефрагер? (shocked!)
> Во вторых, это tradeoff.
О чём и речь. И этот трейдоф на большинстве требовательных к диску ворклоадов приведет к граблям. Исключение - места, где действительно светит (shines) дедупликация. Или ворклоады, нетребовательные к диску.
>> В случае механических дисков. Где-то это окупится плюсами от CoW, где-то - нет.
> При интенсивной записи - с лихвой окупитсяГеммороем при чтении. А плюсы будут разве что если регулярно писать и удалять тысячи файлов объёмом в кластер (чтобы хоть как-то заметить разницу в скорости записи от метаданных).
>> Во первых, если записи мало + есть дефрагер, это проблемой не будет.
> У ZFS есть дефрагер? (shocked!)"Онлайновый-при-записи", если только. Про фоновую "дефрагментацию" на ZFS лично мне неизвестно.
В ZFS ведётся учёт и работа только с занятым пространством, а незанятое пространство как чистый лист для неё — логически "неотформатировано". При записи новых данных используется алгоритм оптимизации размещения данных с подбором размера блока (по умолчанию размер блока 128k). При чтении часто запрашиваемые данные всё равно помещаются в ARC-кэш в оперативной памяти, поэтому с ZFS можно жить и работать с трафиком 5МБ/с между RAM и HDD. Это весьма нетребовательная к пропускной способности носителей файловая система, задержки возникают только при первом обращении к запрашиваемым данным. Отсюда и требование к объёму ОЗУ.
А если не мучать бабушку, и вместо ARC использовать системный кеш - эффективность тоже вырастет. Но архитектура ZFS не позволит.
> "Онлайновый-при-записи", если только.Тебе в маркетологи надо идти. Так изящно вильнуть попой в процессе рассказа про что дефрагера нет может не каждый :D
> Про фоновую "дефрагментацию" на ZFS лично мне неизвестно.
Потому что ее там нет. А ты так и будешь наслаждаться 6мб/сек с диска. Даже если расчистишь засёр и станет больше свободного места, скорость не улучшится особо.
> В ZFS ведётся учёт и работа только с занятым пространством, а незанятое
> пространство как чистый лист для неё — логически "неотформатировано".Неандерталец рассказывает принцип действия микроволновки - "нажимаешь на кнопку, она жужжит и зажигается лампочка, потом она пищит и вот уже у вас готовая еда". :D
> При записи новых данных используется алгоритм оптимизации размещения данных
> с подбором размера блока (по умолчанию размер блока 128k).А в нормальных ФС уж сто лет как используют полноценные экстенты. Позволяющие одной записью в метаданные заадресовать весь регион нужного размера или по крайней мере весьма существенную его часть. Что явно быстрее в ряде случаев.
> При чтении часто запрашиваемые данные всё
> равно помещаются в ARC-кэш в оперативной памяти,Да, да, поскольку у него тормозной блочный аллокатор, надо дофига оперативки чтобы хоть как-то скомпенсировать унылое тормозилово которое может получиться в ряде ворклоадов :)
> поэтому с ZFS можно жить и работать с трафиком 5МБ/с между RAM и HDD.
Кэп намекает что 5Мб/сек - это вообще феерическая тормознутость для жесткого диска. Даже ноутбучного.
> Это весьма нетребовательная к пропускной способности носителей файловая система,
А если жесткий диск совсем выбросить и все на рамдиске хранить - вот это будет скорость! Правда ZFS там вообще лишним получается, а рамдиск более чем на несколько гигз - дорого :-)
> задержки возникают только при первом обращении к запрашиваемым данным.
> Отсюда и требование к объёму ОЗУ.Ну так и запишем: тормозную работу ФС пытаюстя вытянуть нее...ческого размера кешом.
> Это сделано обычно, как навесной механизм.Надо же, до вас стало доползать. Вот именно поэтому и логично если эта механика будет в ФС. Там она может работать лучше. "Дома и стены помогают".
> Единственная более-менее известная среда, умеющая
> действительно 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, а на середине записи все фигакнулось. По поводу чего в обычной ФС если не журналить данные, можно получить полфайла новых и полфайла старых. И оно потом на середине обломается прочесть остальное.
> Практически для любых - гиперфрагментация.Алекс вы опять все перепутали гиперфрагментация это на EXT4 а на ZFS при условии L2ARC она не оказывает влияния, проверено оператором сотовой связи, было в рассылке ...
>> Виртуализация,
> У виртуализаторов обычно свой формат дисков. С 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]
>> У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска.
>> Может не обязательно так эпично ламерить?
> Ламерок, а чёго от анонима-то пишем? Очкуешь лошара?Ну если уж ты о KVM, там есть такие дисковые форматы - qcow и qcow2. Для виртуалок со снапшотами они и юзаются. По их названию несложно догадаться что внутрях там местечковый CoW хранит дельту относительно снапшота :)
>У виртуализаторов обычно свой формат дисков. С CoW прямо внутри файла диска. Может не обязательно так эпично ламерить?У них с производительность, того, мягко говоря...
> У них с производительность, того, мягко говоря...Что - того? Производительность как производительность. Правда не при всех ворклоадах она хорошая. И вообще у "полных" виртуализаторов даже в тепличных условиях I/O в пару раз относительно железа проседать вполне себе умеет. Ну так я как-то и не знаю психов гоняющих нагруженные файлсервера в виртуалках. Каждому инструменту свое применение. Да, микроскопом неудобно вбивать гвозди. Но это не является его недостатком.
>ликбеза ради, расскажите или скиньте урл, где её основное применение и почему?Файлопомойки и хранилища бэкапов с 64ГБ RAM и больше.
Или как ФС общего назначения на BSD и Соярах, при условии не класть на нее базы данных и образы виртуалок и не жалко памяти.
В стораджах для сохранения ооочень больших блобов с медленно меняющимся содержимым. Вот например:
zp2 dedupratio 9.10xА там - сотни гигабайт снапшотов с почтовых серверов (сотни миллионов файликов от imap), девятикратное сжатие получено для случая хранения снимков за 12 последних недель.
Таким макаром на терабайтный раздел непринужденно упихиваются 2-3 ТБ данных и еще больше половины свободно.
Понятно что, как любому архиватору, дедупликатору нужно немерено ОЗУ (порядка 5 ГБ на ТБ), что следует учитывать на этапе проектирования такого стораджа.
>Слишком нишевая FS.Ну ничего себе. Можно подумать контрольные суммы всего, снимки, изменения размера (точнее по сути отсутствие размера) не могут пригодится абсолютно везде кроме разве что дохленьких встраиваемых систем
>контрольные суммы всегокиллер-фича. на десктопах точно.
а остальное "снимки, изменения размер" и остальные умеют и даже на дохленьких встраиваемых систем
> а остальное "снимки, изменения размер" и остальные умеютДа ежи тоже летать умеют. Просто низко. И пинать надо часто. Обычно всем лень. Поэтому ежи как правило и не летают. Но в принципе они летать умеют. Если пнуть посильнее.
у зоофилов по идее свой ресурс должен быть.
или вас оттуда попёрли. за разврат.
> у зоофилов по идее свой ресурс должен быть.
> или вас оттуда попёрли. за разврат.Это был намек на то что к классике снапшоты конечно можно привинтить, но работать это будет примерно так же хорошо как ежи летают. Не, если переть на принцип - не вопрос, ежи летают, конечно. Только нафиг нужно такие "полеты".
изменение размера в ext4 не так хорошо работает как хотелось бы. Уменьшение 1 раз привело к ошибкам (но вроде ничего не пропало)
Отдельная радость доставляет связка lvm + ext4 которой проще все покоцать чем уменьшить размер
возможно (у меня без проблем прошло).
Но речь то не об этом - речь о том, что скорость, стабильность, не требовательность к ресурсам, которые нужны каждый день, каждый миг работы(!!!) всегда предпочтительней одноразовых операций.
Как часто вы меняете размер раздела? Раз в день? Месяц? Год? Вообще не меняете?
>>контрольные суммы всего
> киллер-фича. на десктопах точно.
> а остальное "снимки, изменения размер" и остальные умеют и даже на дохленьких
> встраиваемых системЭто вы про LVM снапшеты ? С их падением производительности раз так в 5 ? :))
> Ну ничего себе. Можно подумать контрольные суммы всего, снимки, изменения размера (точнее
> по сути отсутствие размера) не могут пригодится абсолютно везде кроме разве
> что дохленьких встраиваемых системСлишком высока цена за данный набор фич. Вообще CoW на дисках - это действительно очень нишевая фича, которая нужна разве что для VCS и виртуализации. В остальном стоимость CoW превышает пользу от оной.
> остальном стоимость CoW превышает пользу от оной.А какая у него стоимость?
>> остальном стоимость CoW превышает пользу от оной.
> А какая у него стоимость?Много памяти, много перемещений голов.
Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly. Да и то не всегда, опять же - зависит от паттерна доступа.
Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже чем переписать весь файл? Даже при условии хорошего кэша в раме?
Где-то есть поподробнее об этом?
> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже
> чем переписать весь файл? Даже при условии хорошего кэша в раме?
> Где-то есть поподробнее об этом?Если хоть чуть-чуть включать голову - можно понять, что "кусочек" запишется далеко от остального контента файла. И при каждом чтении будет вызывать дрыганье голов. Когда содержимое файла меняется часто (типичный workload - база данных) - будет бардак.
Ну тогда у вас и цифры есть. Не поделитесь?
> Ну тогда у вас и цифры есть. Не поделитесь?КЭП подсказывает: создайте раздел на ZFS и проделайте указанную мной операцию. Потом посмотрите содержимое диска. И включите, наконец, мозг - какие тут цифры?
Иногда вещи не то чем они кажутся. Цифрам я доверяю больше чем Кэпу. Тем более Кэпу от Линукса.
> Иногда вещи не то чем они кажутся. Цифрам я доверяю больше чем
> Кэпу. Тем более Кэпу от Линукса.Возьмите, сделайте тесты у себя на платформе - будут вам цифры.
> Когда содержимое файла меняется часто (типичный workload - база данных) - будет бардак.Ну и какая разница где именно будет запись БД на диске? Ах, последовательное чтение просядет? Так это проблема только для овощей которые своей тупизной просаживают базу штуками типа SELECT * и прочими фокусами требующими лопатить всю огромную базу от забора и до обеда. А в нормальной ситуации - база всяко за парой записей куда-то seek-ать будет. Куда именно - не столь уж принципиально. По поводу чего не факт что оно вообще просядет.
> последовательное чтение просядет? Так это проблема только для овощей которые своей
> тупизной просаживают базу штуками типа SELECT * и прочими фокусами требующимиИндексы читаются достаточно большими блоками. И перезаписываются не просто часто, а очень часто. Индекс, ровным слоем размазанный по всему диску - страшнейший сон DBA.
> Индексы читаются достаточно большими блоками. И перезаписываются не просто часто, а очень
> часто. Индекс, ровным слоем размазанный по всему диску - страшнейший сон DBA.И тем не менее, btrfs в частности нужен и ораклу. Под их базу. А если DBA не хватает квалификации подружить ФС и базу при том что рукоятки все дадены, что отключение CoW, что дефрагер онлайновый - кто ж виноват?
> И тем не менее, btrfs в частности нужен и ораклу. Под их
> базу. А если DBA не хватает квалификации подружить ФС и базу
> при том что рукоятки все дадены, что отключение CoW, что дефрагер
> онлайновый - кто ж виноват?Вы сначала полистайте алгоритмы работы современных БД, потом уже делайте выводы.
BTR ораклу нужна вряд ли под базу. Скорее - под виртуализацию. Либо просто под ОС.
> Вы сначала полистайте алгоритмы работы современных БД, потом уже делайте выводы.
> BTR ораклу нужна вряд ли под базу. Скорее - под виртуализацию. Либо просто под ОС.У raw разделов есть проблема - их админить неудобно. Поэтому им нужна тонкая прослойка-ФС которую можно удобно подогнать под логику базы. Btrfs вполне сможет быть таковой.
> У raw разделов есть проблема - их админить неудобно.А ZVOL удобно админить. В них любую ФС можно отформатировать (кроме ZFS, собственно), а можно использовать как RAW. И при этом сохраняются все свойства ZFS для них (которые можно отключить или настроить), прикинь!
> Поэтому им нужна
> тонкая прослойка-ФС которую можно удобно подогнать под логику базы. Btrfs вполне
> сможет быть таковой.Ну раз нужна ФС, то вперёд.
> А ZVOL удобно админить. В них любую ФС можно отформатировать (кроме ZFS,
> собственно), а можно использовать как RAW. И при этом сохраняются все
> свойства ZFSПо получению лапши на диске. Причем в данном конкретном случае - аж с особым цинизмом, вплоть до лапшевания метаданных FS, которая записана на ZVOL. Это не RAW, это редкостное извращение над самой сутью использования RAW-разделов.
> собственно), а можно использовать как RAW. И при этом сохраняются все
> свойства ZFS для них (которые можно отключить или настроить), прикинь!Все? А это включая упомянутую неподалеку фрагментацию от CoW? :)
> Ну раз нужна ФС, то вперёд.
Угумс, оракл и шлепает вперед. Вон уже поддержку btrfs у себя предлагают.
>> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже
>> чем переписать весь файл? Даже при условии хорошего кэша в раме?
>> Где-то есть поподробнее об этом?
> Если хоть чуть-чуть включать голову - можно понять, что "кусочек" запишется далеко
> от остального контента файла. И при каждом чтении будет вызывать дрыганье
> голов. Когда содержимое файла меняется часто (типичный workload - база данных)
> - будет бардак.А что EXT4 уже таки пишет файлы по надцать гигабайт непрерывным куском ? :)) Если хоть чуть-чуть включать голову то окажется что максимум 128М ?
> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже
> чем переписать весь файл?Вообще-то, обычные ФС не перезаписывают "весь файл". А только измененный кусок. Просто старая часть файла во многих необратимо перетирается, тогда как CoW явно складывает только в сторонку.
>> Т.е вы хотите сказать, что записать кусочек файла при COW выходит дороже
>> чем переписать весь файл?
> Вообще-то, обычные ФС не перезаписывают "весь файл". А только измененный кусок. Просто
> старая часть файла во многих необратимо перетирается, тогда как CoW явно
> складывает только в сторонку.Это касется исключительно того случая когда записываемый кусок равен куску на диске, если нужно вписать или стереть кусок в середине файла то придется перезаписывать весь хвост. А ниче если этот хвост несколько терабайт ?
> Это касется исключительно того случая когда записываемый кусок равен куску на диске,
> если нужно вписать или стереть кусок в середине файлаТьфу-тьфу, такое извращение актуально только для коротеньких текстовых файлов.
>> Это касется исключительно того случая когда записываемый кусок равен куску на диске,
>> если нужно вписать или стереть кусок в середине файла
> Тьфу-тьфу, такое извращение актуально только для коротеньких текстовых файлов.Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое пространство заранее потому что фс неумели дописывать в серидину файла ... :)))
> Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое
> пространство заранее потому что фс неумели дописывать в серидину файла ...
> :)))ну, если у тебя на ZFS приходится заранее место выделять - я тебе сочувствую. а так sparse-файлы никто не отменял
>> Шел 2013 год но авторы БД и торентов по прежнему выделяли дисковое
>> пространство заранее потому что фс неумели дописывать в серидину файла ...
>> :)))
> ну, если у тебя на ZFS приходится заранее место выделять - я
> тебе сочувствую. а так sparse-файлы никто не отменялАлекс EXT4, ERT4 у вас что еще и склероз ?
>> А какая у него стоимость?
> Много памяти,Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок и без немеряного дискового кеша тормозит - ну да. Так ext3 тоже слоупок на фоне ext4, если что. В btrfs это учли. Вообще, ничто не обязывает CoW сам по себе требовать много памяти или тормозить.
> много перемещений голов.
Сильно зависит от - там запись однократная: пишется только то что изменено. Тогда как журналирующая ФС сделает 2 записи - сначала в журнал, а потом коммит того что в журнале на диск. Мало того что это в 2 раза дольше, так еще и журнал обычно в отдельной области от данных и головы полетят туда через весь диск. Тогда как btrfs например вообще может раскладывать данные как угодно.
> Единственные ворклоады, на которых может быть оправдана CoW - это read-mostly.
Не скажите. Один из основных козырей - технология имеет потенциал делать запись на диск со скоростью нежурналинуемой ФС при сохранении всех свойств полностью журналирующей. Что довольно здорово само по себе. А как бонус - снапшоты условно нахаляву получаются.
> Да и то не всегда, опять же - зависит от паттерна доступа.
А вот тут согласен на все 100%. И тем не менее в большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду не юзает в режиме полного журналирования.
> Откуда это вытекает? То что 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. Для флеша - да, круто, там как раз то самое размазывание и интересно. Для механических дисков - грабельки.
>> Откуда это вытекает? То что ZFS за счет своего блочного аллокатора слоупок
> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт
> гиперфрагментации.
> А у ZFS еще одна проблема есть на этой ниве - ARC
> никак не взаимодействует с системным кешем, в итоге имеем двойное кеширование,
> отсутствие CoW в памяти / memory mapping из ARC - т.е.
> прямое копирование из ARC в кеш и назад, и в наихудших
> случаях - cache thrashing.Правда что ли? Тогда зачем нужен динамический ARC и даже подключаемый при желании L2ARC на внешних носителях? Ведь они "никак не взаимодействуют с системным кэшем". :))
> Правда что ли? Тогда зачем нужен динамический ARC и даже подключаемый при
> желании L2ARC на внешних носителях? Ведь они "никак не взаимодействуют с
> системным кэшем". :))А теперь требуется перечитать еще раз, и понять. Проблема не в том, что ARC "не нужен". Проблема в том - что он независимая от системного кеша сущность. L2ARC вообще в данном кейсе оффтопичен.
ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь, её специально не оптимизировали для конкретной операционной системы (Solaris, в частности), чтобы она была переносима на другие ОС и ядра? Или же разработчики ZFS всё-таки оставили несколько степеней свободы для адаптации её под другие системы для сращивания с так называемым системным кэшем (кэшем VFS?)?
> ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь,
> её специально не оптимизировали для конкретной операционной системы (Solaris, в частности),
> чтобы она была переносима на другие ОС и ядра? Или же
> разработчики ZFS всё-таки оставили несколько степеней свободы для адаптации её под
> другие системы для сращивания с так называемым системным кэшем (кэшем VFS?)?ARC - это не "несистемная хрень, присущая только ZFS", а механика работы кеша (Adaptive Replacement Cache). Если что. В ZFS - только одна из реализаций. Сделана потому, что LRU в солярке оказался слегка неприменим, а допиливать что-то в центре системы в проприетарщине тяжеловато. В итоге наплодили сущностей.
Про zero-copy, естественно, никто не подумал. А когда начали - было уже поздно. В итоге zero-copy оно до сих пор не поддерживает. А отсутствие zero-copy механизма при активной работе с диском - это *дец процессорным кешам, помимо всего прочего.
Про том, что жрать оно будет в 2 раза больше памяти, чем традиционная FS - тоже никто не заморачивался - при стоимости проприетари под солярку (санок) можно было память задом есть. Но вот беда - объемы данных подросли, да и санки сдохли, как экономически неэффективные. А выкидыш под названием ZFS - остался.
> Про zero-copy, естественно, никто не подумал. А когда начали - было уже
> поздно. В итоге zero-copy оно до сих пор не поддерживает. А
> отсутствие zero-copy механизма при активной работе с диском - это *дец
> процессорным кешам, помимо всего прочего.Теоретики они такие теоретики, дай только порассуждать. :))
Почему в Btrfs нету поддержки RAID-5 и RAID-6?
> Теоретики они такие теоретики, дай только порассуждать. :))Именно. А сделать - не получается. Потому что руки коротки. Поэтому zero-copy и нет.
> Почему в Btrfs нету поддержки RAID-5 и RAID-6?
Потому, что не особо в мейнстриме (т.е. энтузиасты-админы локалхостов не в счёт) интересны костыли над аппаратными решениями или md. RAID5/6 - это задача для специализированных контроллеров, а не CPU. md умеет, но практика показывает, что лучше не городить.
> Теоретики они такие теоретики, дай только порассуждать. :))Практик из тебя тоже неважнецкий. С твоими 5Мб/сек на шпиндель ты как-то не вызываешь восхищения и желание повторить этот смертельный номер :P
> ARC — это несистемная абстрактная сущность, присущая только ZFS. Как ты думаешь,
> её специально не оптимизировали для конкретной операционной системыКстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM?
> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки
> TRIM?Ораклу почти без надобности - так что видимо never.
> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM?А тебе зачем? ;)
>> Кстати если мы уж о оптимизации, расскажи, как у ZFS насчет поддержки TRIM?
> А тебе зачем? ;)Вестимо затем, чтобы понять, полное оно гуано, или всё-таки на SSD имеет право на жизнь с максимально обрезанным кешем.
> А тебе зачем? ;)Хочу отделить мух от котлет, а маркетинговый буллшит саней - от суровых реалий реального мира.
>> А тебе зачем? ;)
> Хочу отделить мух от котлет, а маркетинговый буллшит саней - от суровых
> реалий реального мира.Учитывая возраст катлет и опарышей в них в вашей криокамере этот вопрос уровня Дзен :))
> А тебе зачем? ;)Да было интересно бы послушать. А то сани там не так давно втирали тонну маркетингового булшита про то что у них все супер-пупер оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что они без порток, но в шляпе :D
> Да было интересно бы послушать. А то сани там не так давно
> втирали тонну маркетингового булшита про то что у них все супер-пупер
> оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что
> они без порток, но в шляпе :DДа. У них всё "оптимизировано" "под SSD". Там знатоки рекомендуют при юзе ZFS сразу ставить 2Тб Flash Array за 160K$+флеш под любую инсталляцию, для L2ARC. И потом удивляются, почему её называют неюзабельной.
>> А тебе зачем? ;)
> Да было интересно бы послушать. А то сани там не так давно
> втирали тонну маркетингового булшита про то что у них все супер-пупер
> оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что
> они без порток, но в шляпе :DОперация TRIM нужна там, где используются блоки ФС гораздо меньшие по размеру блоков SSD. Например, в традиционных файловых системах собственные блоки имеют размеры 4, 8, 16 или 32 кбайт. В этом случае SSD нуждается в регулярных очистках пространства от "грязных" страниц, так как операция непосредственной записи на флэш выполняется блоком страниц 512 кбайт.
Размер блока на ZFS может быть настроен равным размеру блока страниц SSD (512 кбайт вместо 128 кбайт), нужда в операции TRIM исчезает — запись новых данных происходит последовательно за одно обращение к накопителю: с очищением всех страниц блока SSD и записью в этот блок блока данных ФС без накладных расходов на отдельные операции очищения и перезаписи из-за несовпадения блоков данных, как если бы это происходило в традиционных ФС и ФС с экстентами.
Операция TRIM нужна еще и для оптимизации wear leveling на SSD. Она говорит SSD, что блок освобождён, и его можно использовать произвольным образом. Без TRIM, при удалении, допустим, файла с FS, SSD никак не узнает, что место освобождено.
И тут мы плавно подходим еще к одному веселому и вкусному моменту CoW FS на SSD без TRIM.
CoW FS потихоньку использует весь диск, так как старается не занимать уже используемые блоки.Итого без TRIM утилизация пользовательского набора SSD при "fair use" быстро достигнет 100% (SSD никогда не узнает о том, что FS освободила блоки), приводя к падению скорости записи, и хреновой эффективности wear leveling'а (резервный набор на флешах не такой уж и большой).
Таким образом под ZFS SSD проживет при "среднестатистической" утилизации на запись рекордно короткие, по сравнению с традиционными FS, сроки, и это факт. Традиционные FS даже без TRIM оставляют шансы на перезапись блока, CoW же FS на SSD без TRIM - редкостное извращение.
> И тут мы плавно подходим еще к одному веселому и вкусному моменту
> 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 и таким образом не перезаписывает лишний раз страницы флэш-памяти.
> Падение скорости записи будет только у ФС, у которых блок гораздо меньше
> размера блока страниц SSD. Я это уже объяснил ранее.Падение скорости при больших объемах записи будет при любом размере блока - просто за счёт недостаточности резервного набора - чтобы что-то записать, надо что-то стереть, а стирание - операция долгая. В случае с TRIM в рабочий набор войдут уже стёртые после TRIM блоки.
> TRIM изнашивает флэш тем, что перезаписывает очищает помеченные страницы ФИЗИЧЕСКИ.
TRIM только помечает страницы, и помещает их в резервный набор. Который дальше используется для левелинга. Стирает их garbage collector, периодически.
>> Падение скорости записи будет только у ФС, у которых блок гораздо меньше
>> размера блока страниц 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 перезаписывается с "усилием" тех страниц, которые не помечены как неиспользуемые. Такая перезапись для них никак не связана с полезной записью данных ФС — это как аналог регенерации динамической памяти на ёмкостных элементах.
> С чего бы они войдут? TRIM выполняется с целым блоком — не
> с группой блоков, а с целой группой страниц по 4k каждая.Тупой пример для совсем уж непонимающих: удалили файл объёмом 20 гиг. С TRIM SSD узнает, что эти 20 гиг (за вычетом "неполных" блоков) можно юзать под рабочий набор. Без TRIM - нет.
> Это неважно, кто стирает. TRIM, как ATA-команда, призвана очистить помеченные неиспользованными страницы, но по сути работает с целым блоком страниц (сектором накопителя).
TRIM только маркирует страницы в служебных данных контроллера. Не более, и не менее. Иногда - запускает GC.
Всё остальное было просто не понято Вами при прочтении. Как раз таки TRIM позволяет однозначно отметить полностью свободные блоки флеша, и не пытаться сохранять в них какие-либо данные при записи одного субблока. Ну и использовать эти блоки для leveling'а. TRIM'нутый блок флеша стирается, и используется под левелинг. А не TRIM'нутый но свободный - лежит, и ждёт, пока перезапишут именно его. В то время, когда маленький рабочий набор пытается вытянуть на себе перезаписи всего остального флеша.
> Операция 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 исчезает —
Мечтать не вредно.
>> А тебе зачем? ;)
> Да было интересно бы послушать. А то сани там не так давно
> втирали тонну маркетингового булшита про то что у них все супер-пупер
> оптимизировано для ssd. Кивая на l2arc если не ошибаюсь. Получается что
> они без порток, но в шляпе :DЭто панталоны сер, вы их не туда натягиваете ... :)))
>[оверквотинг удален]
>> Любой 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 :))
> Любой 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 - получите нечто наподобие. Если уж сравнивать нежурналы и недожурналы - так пусть и у бтрфс будет не полный журналинг, чтоли. А то как-то нечестно когда некто полностью журналит, а его ставят в один ряд с нежурналирующими или недожурналирующими.
>> Любой 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 нет
Ну это уже прошлый век.
> А вот это зависит от того как именно запись делалась. При ряде
> ворклоадов будет лучше, при ряде - хуже. Разным дизайнам - разныеЛучше традиционок не будет в любом случае - даже тех же самых метаданных больше участвует в процессе. Т.е. с традиционками - правда ваша, сравнивать бессмысленно.
В остальном согласен.
> Наихудший режим - это много мелких перезаписей, а не дозаписей.Для кого? Для 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 - это улучшение полной журнальной логики на другой манер, с избавлением от многих недостатков оригинала. Но чудес не бывает и поэтому появляется и ряд специфичных для нового дизайна проблем. Совсем иных. Другому дизайну - другие свойства.
>> Наихудший режим - это много мелких перезаписей, а не дозаписей.
> Для кого? Для 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).
> Да, я про 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).Я бы скорее обозвал ФС специфичными базами данных, чтоли. Этакий частный случай с оптимизацией на некоторые допущения и договоренности.
User294, почему ты пишешь под другим именем? Пароль потерял от учётной записи?
> User294, почему ты пишешь под другим именем? Пароль потерял от учётной записи?Не льстите ему, помнить два пароля явно за пределами его возможностей :))
> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера.Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности?
(А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)
> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства,
> тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности?Звучит примерно как "а ты тоже выстрели себе в пятку и мы посмотрим кто из нас громче орать будет" :)
Да, в btrfs может и будет жо, но ее можно будет устранить дефрагером и без пересборки многодисковой конструкции с пересозданием ФС с нуля.
> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)
Скорее к тому что это - перманентное состоения пула, которое не особо пролечится при освобождении места.
Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти.
>> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства,
>> тогда и будем сравнивать "+" и "-". Как насчёт 100% заполненности?
> Звучит примерно как "а ты тоже выстрели себе в пятку и мы
> посмотрим кто из нас громче орать будет" :)О, для тебя простое тестирование выливается в прострел пятки? O_o
Скажи, тебе жить вообще не страшно?> Да, в btrfs может и будет жо, но ее можно будет устранить
> дефрагером и без пересборки многодисковой конструкции с пересозданием ФС с нуля.Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим, что он тебе надефрагментирует. ;)
>> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)
> Скорее к тому что это - перманентное состоения пула, которое не особо
> пролечится при освобождении места.Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место терять зря на скорость, если и так всё устраивает?
> Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти.
Это про Btrfs?
> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место
> терять зря на скорость, если и так всё устраивает?Бред. То, что уже превратилось в лапшу, из неё путём освобождения 10-15 Гб не вывести. Более того, с высокой долей вероятности эти 10-15 Гб на диске, допустим, в 1.5Тб, будут также представлять лапшу блоками по несколько десятков метров.
>> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать. Но зачем место
>> терять зря на скорость, если и так всё устраивает?
> Бред. То, что уже превратилось в лапшу, из неё путём освобождения 10-15
> Гб не вывести. Более того, с высокой долей вероятности эти 10-15
> Гб на диске, допустим, в 1.5Тб, будут также представлять лапшу блоками
> по несколько десятков метров.А кто тебе сказал, что на 1.5ТБ пуле хранится лапша? Большая часть данных в таком объёме лично у меня редко перезаписывается. Это как хранилище медиафайлов. Что там перезаписывать?
А торренты пишутся на отдельный небольшой пул без избыточности, который не страшно потерять и/или срыть и пересоздать заново.
> А кто тебе сказал, что на 1.5ТБ пуле хранится лапша? Большая часть
> данных в таком объёме лично у меня редко перезаписывается. Это как
> хранилище медиафайлов. Что там перезаписывать?Простите, а нахрена вообще CoW, если там ничего не перезаписывается? :)
> О, для тебя простое тестирование выливается в прострел пятки? O_oЕсли в процессе тестирования предлагается взять пистолет, зарядить и направить его себе на пятку - и так понятно что результатом будет простреленная пятка. Более того, констатация того факта что у допустим железного робота она в принципе потом не заживет, а у человека может зажить - вовсе не требует простреливать себе пятку для доказательства этого тезиса. Это и так достаточно очевидно. Просто разница в дизайне. В одном рекавери из ситуации предусмотрен, а во втором - нет.
> Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим,
> что он тебе надефрагментирует. ;)Дык можно очистить часть места. Чтобы ему легче было. А если дефрагера нет - он ни при какой занятости ничего не надефрагментирует. По определению просто :P.
> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать.
А фрагментация куда девается если дефрагера нет? Опять магический маркетинговый буллшит? :)
> Но зачем место терять зря на скорость, если и так всё устраивает?
Да, собери raid из флопиков :). Слоупочить - так без компромиссов!
>> Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти.
> Это про Btrfs?Вот у btrfs как раз дадены средства выхода из штопора. А в zfs - предлагается маркетинговый буллшит, общая суть которого сводится к "докупите оперативы".
>> О, для тебя простое тестирование выливается в прострел пятки? O_o
> Если в процессе тестирования предлагается взять пистолет, зарядить и направить его себе
> на пятку - и так понятно что результатом будет простреленная пятка.Я вот не боюсь приводить тесты (чтения) скорости с ФС, а ты со своей Btrfs зассал?
Нету у тебя никакой Btrfs. Ты её не используешь, а порассуждать любишь.
>> Попробуй запустить дефрагментатор на Btrfs при 99% занятости пространства. Посмотрим,
>> что он тебе надефрагментирует. ;)
> Дык можно очистить часть места. Чтобы ему легче было. А если дефрагера
> нет - он ни при какой занятости ничего не надефрагментирует. По
> определению просто :P.Так покажи результаты теста, что мешает? (Пятка чать не оторвётся. Или не знаешь ещё?)
>> Пролечивается. Освобождаешь 10-15 ГБ и всё начинает заново летать.
> А фрагментация куда девается если дефрагера нет? Опять магический маркетинговый буллшит?Откуда взяться фрагментации на данных, которые записаны раз и больше не трогаются. Это нужно весь пул перезаписывать рандомно каждый файл, чтобы ощутить всю прелесть фрагментации. Уверен, на это уйдёт гораздо больше времени, чем у традиционных ФС с 4k-, 8k-, 16k- и 32k-блоками — размеры блоков у ZFS гораздо больше (блоки переменного размера, кстати, но не меньше дефолтного 128k) и таких блоков по определению меньше требуется на один файл. А значит фрагментация минимальна в любом случае (блок ZFS не разделяется на части по всему диску).
>>> Разбивается не тот самолет который впал в штопор, а тот который из него не смог выйти.
>> Это про Btrfs?
> Вот у btrfs как раз дадены средства выхода из штопора.Какие, например? Пока что мы слушаем твои теоретические измышления.
> А в zfs - предлагается маркетинговый буллшит, общая суть которого сводится к "докупите оперативы".
По крайней мере этот "булшит" работает как заявлено.
>> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера.
> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда
> и будем сравнивать "+" и "-". Как насчёт 100% заполненности?
> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)А ты удали с пула хлам хотя бы на 20%... И посмотри - улучшится ситуация на конкретных файлах или нет. Я-то точно знаю, что нет, как в лапшу легли, так лапшой и останутся, дефрагментации нет. Можешь проверить.
>>> Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера.
>> Так доведи своё файлохранилище с Btrfs до заполнения 99% доступного пространства, тогда
>> и будем сравнивать "+" и "-". Как насчёт 100% заполненности?
>> (А то прицепился, понимаешь, к 5 МБ/с и не отпускает.)
> А ты удали с пула хлам хотя бы на 20%... И посмотри
> - улучшится ситуация на конкретных файлах или нет. Я-то точно знаю,
> что нет, как в лапшу легли, так лапшой и останутся, дефрагментации
> нет. Можешь проверить.И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью".
> И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью".Пруф можно? Как удаление 3% хлама повлияло на чтение файла, который читался со скоростью 5МБ/с?
>> И 3% удалённого хлама достаточно, чтобы "вздохнуть полной грудью".
> Пруф можно? Как удаление 3% хлама повлияло на чтение файла, который читался со скоростью 5МБ/с?Пруфа не будет — тот файл, который читался со скоростью 5 МБ/с, был удалён. :)) Место освободилось == скорость записи снова выросла.
> что нет, как в лапшу легли, так лапшой и останутся, дефрагментации нет.А забавно изен шлангом прикидывается :D
> Так доведи своё файлохранилище с 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 для него купить не могу :)
% 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 0errors: 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Учись, студент. :)
> % 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
Ещё:% 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 0errors: 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
cat /proc/cpuinfo
cat /proc/meminfo
хотелось бывидно, что 27-29 Мб/сек - предел чтения с диска до кеширования. лапша - она и есть лапша
> 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: amd64ZFS Storage pool Version: 28
ZFS Filesystem Version: 5FreeBSD 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 GapReal Installed: 8.00 GiB
Real Available: 93.47% 7.48 GiB
Real Managed: 96.76% 7.24 GiBLogical Total: 8.00 GiB
Logical Used: 33.71% 2.70 GiB
Logical Free: 66.29% 5.30 GiBKernel Memory: 1.05 GiB
Data: 98.01% 1.02 GiB
Text: 1.99% 21.24 MiBKernel Memory Map: 7.23 GiB
Size: 10.58% 783.32 MiB
Free: 89.42% 6.46 GiB------------------------------------------------------------------------
ARC Summary: (HEALTHY)
Memory Throttle Count: 0ARC Misc:
Deleted: 43
Recycle Misses: 0
Mutex Misses: 0
Evict Skips: 2.05kARC 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 GiBARC Size Breakdown:
Recently Used Cache Size: 49.98% 3.12 GiB
Frequently Used Cache Size: 50.02% 3.12 GiBARC 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.03mData Demand Efficiency: 95.25% 555.03k
Data Prefetch Efficiency: 8.39% 1.47kCACHE 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% 94CACHE 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.26kCACHE 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.05mColinear: 2.05m
Hit Ratio: 0.01% 144
Miss Ratio: 99.99% 2.05mStride: 4.64m
Hit Ratio: 100.00% 4.64m
Miss Ratio: 0.00% 7DMU Misc:
Reclaim: 2.05m
Successes: 0.11% 2.16k
Failures: 99.89% 2.05mStreams: 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-режиме, зато по всей поверхности диска примерно одни и те же показатели.
>Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка: если специально её не тюнить и не подстраивать свойства) — скорость примерно в два раза ниже максимально возможной в RAW-режиме, зато по всей поверхности диска примерно одни и те же показатели.Хиловато. Но на самом деле больше похоже на в 3 раза ниже средней скорости RAW девайса.
Не затруднит привести скорость чтения в начале и в конце SAMSUNG HM641JI. Сдается мне, что она ~100MB/c в обоих случаях.
>>Вообще же я говорил, что 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
Что то вроде
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 медленнее средней.
> Вообще же я говорил, что ZFS усредняет скорость работы с носителями (поправочка:
> если специально её не тюнить и не подстраивать свойства) — скорость
> примерно в два раза ниже максимально возможной в RAW-режиме, зато по
> всей поверхности диска примерно одни и те же показатели.Два вопроса: это как, и зачем она такая красивая нужна?
> видно, что 27-29 Мб/сек - предел чтения с диска до кеширования. лапша
> - она и есть лапшаДык :). И я как-то сомневаюсь что iZEN денно и нощно хранит в оперативке в кеше свои уральские пельмени. Поэтому в большинстве случаев скорость вон та, а не те красивые гиг/сек из кеша. Если уж скорость RAM мерять для файловых операций - можно рамдиск сделать :D.
для достоверности почитаем разные файлы:# 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 писался совсем недавно.
Oracle на ZFS: Учимся готовить кошек, часть I:
http://yvoinov.blogspot.com/2011/01/oracle-zfs-i.htmlOracle Database Single Instance на ZFS: учимся готовить:
https://blogs.oracle.com/pomah/entry/oracle_database_single_...
> Oracle Database Single Instance на ZFS: учимся готовить:
> https://blogs.oracle.com/pomah/entry/oracle_database_single_...Да, да, и опять там про фрагментацию изящно повиляно попой. Проблему так изящненько замаскировали под пенька :)
Я встречал неоднократно людей, способных на базе в 20 мегабайт добиться "выдающихся скоростных результатов" ("невыдающиеся" были обусловлены кривыми руками). Автор не описывает ни структуру, ни объем базы, ни число записей.Да. Точно. Наткнулся на "тест" автора. Автор делает линейную (*, без WHERE) выборку из таблицы размером в 11 небольших строк, и надеется, что на его выборку как-то повлияет FS.
Ровно то, что и требовалось доказать. Т.е. автор в виде результатов получил шум океанов Марса, и на их основании пытается делать какие-то выводы.
---
А по второй ссылке - там вообще страхи:
>>> Sun Storage F5100 Flash Array позволяет держать в кэше до 2TB данныхВсего-то $160000, плюс флеши
>>> Для увеличения скорости записи так же желательно использовать Sun Flash Accelerator F20 PCIe Card
Еще $2000
Итого 162000$ + еще порядка 20000 на флеш только чтобы компенсировать "потребности" ZFS. К слову говоря, с кешем такого объёма FS чаще всего уже непринципиальна. Т.е. недостатки FS с расходом памяти заткнули SSD с огромным размером кешируемого рабочего набора. Так можно поступать, только когда немеряно денег, и их некуда деть.
> Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания.Похоже не только этого пепелаца но и половины данного ресурса :))
>>> А какая у него стоимость?
>> Много памяти,
>То что ZFS за счет своего блочного аллокатора слоупок
> и без немеряного дискового кеша тормозит - ну да. Так ext3
> тоже слоупок на фоне ext4, если что. В btrfs это учли.
> Вообще, ничто не обязывает CoW сам по себе требовать много памяти
> или тормозить.В btrfs с его чуйдо аллокатором по прежнему нельзя отключить кеширование для отдельно взятого раздела ?
> диск. Тогда как btrfs например вообще может раскладывать данные как угодно.
Достаточно 1 раз попать на бедблок и потом ниче не найдешь ?
> А вот тут согласен на все 100%. И тем не менее в
> большинстве бенчей на не засранном томе btrfs вполне культурно выглядит в
> плане производителности. А хотя-бы на фоне ext4, который вообще никто сроду
> не юзает в режиме полного журналирования.Привидите результаты хотябы одного теста на засраных поюзанных разделах, а то сферические кони в вакуме всегда быстро летают ...
она такой же тормоз, как и btrfs. На десктоп не поставите, например.
> она такой же тормоз, как и btrfs.Она куда больший тормоз чем btrfs. Смотрим бенчмарки. Ну а btrfs тормоз лишь при сильно некоторых нагрузках.
При любых. И это печально :(
> При любых.Бенчмарки с вами не согласны. И да, предвосхищая возмущенные вопли, они тоже вид ворклоада.
>> При любых.
> Бенчмарки с вами не согласны. И да, предвосхищая возмущенные вопли, они тоже
> вид ворклоада.Фороникс негодуе?
> Фороникс негодуе?Кэп информирует что у фороникса пока нет монополии на бенчмарки :)
>> Фороникс негодуе?
> Кэп информирует что у фороникса пока нет монополии на бенчмарки :)Я заметил анонимусы не представляют никаких результатов тестов кроме фороникса :)) наверно из-за "неудовлетворительных" с их точки зрения результатов, ну так давайте сравним с этим
http://www.nekolove.jp/wp/archives/2012/01/20120124160239.php
ещё предлагали использовать эффективное сжатие и агрессивную дедупликацию для экономии места на всяких нетбуках.. но экономически оказалось дешевле воткнуть в нетбуки диски большего объёма.
И вдруг объявились SSD, на которых внезапно экономить место опять стало целесообразным. Рано или поздно на пике расцвета SSD объявится еще какая-нибудь технология, забивающая их по всем параметрам кроме стоимости за гигабайт.Жаль все-таки, что "экономическая целесообразность" преследует слишком коротую выгоду.
> И вдруг объявились SSD, на которых внезапно экономить место опять стало целесообразным.На SSD надо не экономить место, а не держать всякий хлам. SSD - это не долгосрочная файлопомойка, а, скорее, оперативный кэш. Причём для read-mostly нагрузок.
В итоге либо цена SSD упадёт до цены HDD, либо они так и останутся в двух применениях: под собственно ОС (десктоп) либо БД (сервер), и в качестве кеш-драйва для дисковой системы (большинство аппаратных рейдов уже умеют).
К слову, применение SSD под кеш, в целом, наиболее оправдано.
> - это не долгосрочная файлопомойка, а, скорее, оперативный кэш. Причём для
> read-mostly нагрузок.Вот только в ноуте обычно 1 гнездо для диска. Так что или так, или эдак.
> Вот только в ноуте обычно 1 гнездо для диска. Так что или
> так, или эдак.Гибридные диски уже выпускаются. Если честно - я не вижу вообще смысла в SSD для ноута. Для планшета - смысл есть, например, возможность его ронять - ЦА такова, что и утопить может, не то, что уронить. А для ноута... ну, можно притянуть за уши несколько резонных вещей, но в общем и целом смысла нет.
> Гибридные диски уже выпускаются.А это вообще ни рыба, ни мясо. Вымрут имхо.
> Если честно - я не вижу вообще смысла в SSD для ноута.
Зато я вижу: машина ждет юзера а не юзер - машину. Хорошо когда либрофисы всякие взлетают за полсекунды :). К тому же крутить не надо - меньше жрет при чтении, прочнее, не надо ждать пока раскрутится, etc.
> А для ноута... ну, можно притянуть за уши несколько резонных вещей, но в общем и целом смысла нет.
Кому как. Ноутбучные винчи - тормозные до неприличия. А ждать постоянно тупящую машину - не очень то приятно. А ожидание может быть весьма ощутимо, т.к. винч стопорится для экономии батареи.
> Кому как. Ноутбучные винчи - тормозные до неприличия. А ждать постоянно тупящую
> машину - не очень то приятно. А ожидание может быть весьма
> ощутимо, т.к. винч стопорится для экономии батареи.Ноутбучная память настолько дешёвая, что поставить 8Гб - 0 проблем 0 копеек. И результат от объёма кеша превзойдёт все ваши лучшие ожидания от SSD :)
> Ноутбучная память настолько дешёвая, что поставить 8Гб - 0 проблем 0 копеек.
> И результат от объёма кеша превзойдёт все ваши лучшие ожидания от SSD :)Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт системы с HDD никогда не будет сравним в SSD. А выключать иногда приходится - батарейка не резиновая. Ну и все остальное так же будет. А SSD можно с некоторой условностью считать одним большим кешом.
> Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт
> системы с HDD никогда не будет сравним в SSD. А выключать
> иногда приходится - батарейка не резиновая. Ну и все остальное так
> же будет. А SSD можно с некоторой условностью считать одним большим
> кешом.1. Hibernate отменили?
2. Prefetch настроен?
> 1. Hibernate отменили?Да, потому что взлет и особенно шатдаун без него - заметно быстрее.
> 2. Prefetch настроен?
А как же. Только все-равно, данные то надо прочитать. А seek time у ноутбучных винчей не фонтан. SSD в этом плане намного лучше.
>> 1. Hibernate отменили?
> Да, потому что взлет и особенно шатдаун без него - заметно быстрее.Раз рабочий взлёт-шатдаун с rotational drive у вас быстрее хибернейта - SSD вам не поможет, дело не в диске.
>> 2. Prefetch настроен?См.1.
>> Не превзойдет: чтобы кеш сработал, данные должны там быть. Поэтому например старт
>> системы с HDD никогда не будет сравним в SSD. А выключать
>> иногда приходится - батарейка не резиновая. Ну и все остальное так
>> же будет. А SSD можно с некоторой условностью считать одним большим
>> кешом.
> 1. Hibernate отменили?Сон быстрее.
> 2. Prefetch настроен?Выключи и забудь.
>> 1. Hibernate отменили?
> Сон быстрее.Отличный совет. Если не считать того, что "сон" требует наличия э/п на памяти.
>>> 1. Hibernate отменили?
>> Сон быстрее.
> Отличный совет. Если не считать того, что "сон" требует наличия э/п на
> памяти.В вашем ноуте сдох акумулятор ?
> В вашем ноуте сдох акумулятор ?Прикинь, мну ломает тратить аккумулятор ноута на поддержание памяти часами. Особенно в поездке. Особенно в деловой. Особенно когда минуты работы на счету.
>> В вашем ноуте сдох акумулятор ?
> Прикинь, мну ломает тратить аккумулятор ноута на поддержание памяти часами. Особенно в
> поездке. Особенно в деловой. Особенно когда минуты работы на счету.Такой хреновый акумулятор ?
> Такой хреновый акумулятор ?Да нет, такой суровый ноут. 4-корка с 8Гб и пять рабочих виртуалок на ней.
А мужики-то и не знали... Использую ZFS в практически домашних условиях, дико удобная вещь.
У меня сосед по даче трактор купил.
Да-а-а-воле-е-ен! как слон.
Как то с семью на нём на дачу привёз - говорит, нахрен 2-а раза то ездить.
Ну, логично то в общем. И не возразишь.
Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения.
> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения.lol'd
ну изен с 5 MBps с диска тут уже был
>> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения.
> lol'd
> ну изен с 5 MBps с диска тут уже былВы забыли добавить: "с заполненными на 99% пулами". Как ведут себя в подобных случаях альтернативные ФС, говорить будем или скромно умолчим?
Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного места - беда всех CoW файловых систем. Так что ext4/xfs вполне нормально живут при почти полной занятости дисков.Т.е. ZFS не годится как фс для сервера бэкапов(точнее, требует держать на сторадже меньше данных, чем его размер).
>Так что ext4/xfs вполне нормально живут при почти полной занятости дисков.Если бы только не фрагментация и баги
да бросьте уже ерунду писать.
xfs и тем более ext4 гораздо стабильнее и zfs, и btrfs.
Че-то похоже на сравнение теплого с зеленым.
Либо уж сравнивайте ZFS <> BTRFS/EXT4+LVM(с натяжкой) либо EXT4/XFS <> UFS/FFS.
> EXT4/XFS <> UFS/FFS.А чего сравнивать то? Вторые - ископаемые как@шки мамонта. По поводу на большинстве бенчей и вообще ворклоадов первые сделают со вторыми то же что Тузик с грелкой. Ибо extent-based файловые системы в общем случае делают block-based. По поводу чего античные блочные методы выделения места остались в ходу только у махровых некрофилов.
> Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного
> места - беда всех CoW файловых систем. Так что ext4/xfs вполне
> нормально живут при почти полной занятости дисков.Не, ну их тоже можно положить при желании. Удаление файла по 30 секунд на XFS? А я такое видел. Как сделать? Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то что и должны были :)
> Т.е. ZFS не годится как фс для сервера бэкапов(точнее, требует держать на
> сторадже меньше данных, чем его размер).Оно вообще "первый блин комом". У btrfs'ников лучше вышло.
Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то что
получим на CoW FS даже с преаллокацией...
> Качаем на забитый том торрент гигов на 5 без преаллокации. Получаем... то
> что получим на CoW FS даже с преаллокацией...Ну если уж на то пошло, у меня в таком виде XFS просто стирал 5-гиговый файл секунд по 30. Кстати том вообще забитым не был. Просто сдуру качнул торентов без преаллокации и подивился тому как все уныло работает :)
Я проморгал про удаление, и писал про то, что на CoW мы получим лапшу по всему диску хоть с преаллокацией, хоть без оной.
> Я проморгал про удаление, и писал про то, что на CoW мы
> получим лапшу по всему диску хоть с преаллокацией, хоть без оной.А на обычных не-CoW ФС с преаллокацией не будет "лапши"? Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС, так как ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы. Разработчику преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора) и временем ответной реакции на начало скачивания торрент-контента. То есть грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового мусора, чтобы ФС точно выделила (10ГБ) желательно в соседних секторах диска этот самый объём пространства, которое со временем будет перезаписано настоящими байтами контента.
Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют только LBA адресацией). И грамотный преаллокатор поэтому написать невозможно, как, кстати, и грамотный дефрагментатор с учётом расположения секторов на диске. Возможно лишь "балансировка" (оптимизация) метаданных для как можно скорейшего доступа к блокам с данными на диске.
Условно скорость доступа к данным повышается, если их располагать как можно ближе к логическому началу диска. С этим знанием ведут работу всякого рода дефрагментаторы и оптимизируют свою работу ФС при записи данных, а также учитывают другие критерии расположения: как можно более монотонная последовательность адресации блоков одного файла, как часто используется файл и, ещё может быть, размер файла (бывают дефрагментаторы, которые нарочно двигают большие файлы в конец или в начало диска). Всё это по сути ускоряет доступ к набору данных, но не делает этот доступ идеально быстрым — LBA скрывает механические перемещения головок винчестера. Работа с метаданными намного более продуктивна (быстра) и позволяет сделать время доступа к данным одинаковым на всей поверхности диска, обеспечить достаточную скорость чтения и записи (примерно в два раза меньше максимально доступной для данного винчестера) по ВСЕЙ поверхности диска.
>> Я проморгал про удаление, и писал про то, что на CoW мы
>> получим лапшу по всему диску хоть с преаллокацией, хоть без оной.
> А на обычных не-CoW ФС с преаллокацией не будет "лапши"?Прикинь - нет, не будет. Файл аллоцируется по возможности линейно, и перезапись идёт без изменения местоположения данных.
> Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС
Фееричненько.
> ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить
> выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы.БГГГ. Прошу прощения, но у меня сейчас уши в трубочку завернутся от того, что вы тут пишете. КАКОЕ ОТНОШЕНИЕ группы одинаковых байтов имеют к преаллокации занимаемого файлом дискового пространства? Задача преаллокатора - выделить максимально линейные блоки для файла, а какие ГРУППЫ БАЙТОВ туда будут записаны - его не волнует. Равно как и диск xD
> преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью
> преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора)It's epic, bro xD
> грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового
> мусораИ снова эпичное непонимание принципов работы FS. Суть в том, что всё "скидывание потока байтового мусора" сводится к ftruncate(file_handle, file_size). Нормальная FS при этом ничего, кроме метаданных, указывающих, где будет лежать файл, на диск не запишет.
> Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют
> только LBA адресацией).Последовательное чтение секторов на любых современных типах диска быстрее произвольного. Тчк. Всё остальное - лирика.
При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее. Используется так называемая "ленивая" преаллокация, когда ФС преаллокатору говорит, что пространство выделено, размер уменьшен на затребованную величину дискового пространства, а на самом деле сделана пометка в метаданных на "диапазон" (структуру) блоков который будет занят, а фактически же ещё нет. В это же время на ФС можно писать другие данные, никак не связанных с преаллокаченными. И эти данные могут расположиться физически в тех местах диска, которые могло бы заняться данным, место для которых оно заранее выделено в "диапазоне".По мере того, когда данные заполняют зарезервированный за ними "диапазон" блоков обновляется структура метаданных, его описывающая. ФС соотносит собственные занимаемые блоки с доступными LBA-адресами секторов на диске. Бывают ситуации, когда торрент-клиент выделил место на диске, что называется, впритык доступного пространства, ФС отрапортовала ему, что всё зарезервировано — можно качать, начинается скачка. Но после этого из какой-то программы записывается на диск файл чуть большего размера, чем оставшееся свободное место на диске — торрент-клиент уже не может докачать свой файл, так как место закончилось. Это случай из практики использования ZFS, преаллокация в Transmission включена.
> При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее.Чего? При преаллокации файла место распределяется ПОЛНОСТЬЮ. Иначе это не преаллокация. Только распределяется, а не перезаписывается.
> Используется так называемая "ленивая" преаллокация
Вы путаете преаллокацию со sparse-аллокацией. Более того, для sparse-аллокации вовсе не обязательно уменьшать счётчик свободного места.
> Это случай из практики использования ZFS, преаллокация в Transmission включена.
Что и логично. На ZFS преаллокация НЕВОЗМОЖНА в принципе, потому что это CoW. И любой записанный блок данных пишется не на жестко заданное место хранения, а куда попало.
>> При преаллокации средствами самой ФС недостаточно метаданных для описания абсолютно всех занимаемых блоков данных, которые будут записаны в ФС позднее.
> Чего? При преаллокации файла место распределяется ПОЛНОСТЬЮ. Иначе это не преаллокация.
> Только распределяется, а не перезаписывается.Значит вот так оно распределяется, что не может обосновать свою предельность в небесконечном пространстве адресации винчестера.
>> Используется так называемая "ленивая" преаллокация
> Вы путаете преаллокацию со sparse-аллокацией. Более того, для sparse-аллокации вовсе не
> обязательно уменьшать счётчик свободного места.Значит в ZFS используется sparse-аллокация. Счётчик свободного места при преаллокации из Transmission не уменьшается.
>> Это случай из практики использования ZFS, преаллокация в Transmission включена.
> Что и логично. На ZFS преаллокация НЕВОЗМОЖНА в принципе, потому что это
> CoW. И любой записанный блок данных пишется не на жестко заданное
> место хранения, а куда попало.Всё ясно.
> Значит вот так оно распределяется, что не может обосновать свою предельность в
> небесконечном пространстве адресации винчестера.Это называется sparse allocation / sparse file, и к преаллокации не имеет никакого отношения.
> Значит в ZFS используется sparse-аллокация.
Верно. Механика работы аллокатора в CoW FS при записи очень сходна с механикой работы sparse-аллокаторов в традиционных FS.
Фокус в том, что на ZFS невозможна статическая преаллокация. В итоге любой достаточно большой и записываемый произвольно файл превращается в лапшу.
> Прикинь - нет, не будет. Файл аллоцируется по возможности линейно, и перезапись
> идёт без изменения местоположения данных.Ну это же изен. Он там крЮтыми концепциями оперирует. Поэтому представить себе как блоки в файле рапсполагаются и как это описывается - у него кишка тонка.
> Фееричненько.
А забавно он странный аллокатор ZFS отмазывает :)
>> выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы.
> БГГГ. Прошу прощения, но у меня сейчас уши в трубочку завернутся от...обилия маркетингового буллшита :). Называя вещи своими именами.
> максимально линейные блоки для файла, а какие ГРУППЫ БАЙТОВ туда будут
> записаны - его не волнует. Равно как и диск xDОн не в состоянии осознать этот тривиальный факт, зато маркетинговый буллшит из него так и прет.
> It's epic, bro xD
По-моему, мы у него вызвали деление на ноль :)
> Последовательное чтение секторов на любых современных типах диска быстрее произвольного.
> Тчк. Всё остальное - лирика.Кроме SSD, у которых эта разница куда меньше. Как минимум при чтении.
Кстати раз уж заговорили о преаллокаторах. На CoW преаллокация бессмысленна в принципе :)
> получим лапшу по всему диску хоть с преаллокацией, хоть без оной.Ну мы ее слегка получим и на обычной ФС - совсем не факт что там есть непрерывный блок на 100500Гб :)
> Ну мы ее слегка получим и на обычной ФС - совсем не
> факт что там есть непрерывный блок на 100500Гб :)Ну то слегка, будут выделены максимально линейные фрагменты. А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность.
> Ну то слегка, будут выделены максимально линейные фрагменты.Вообще, если том на 99% забить, как этот чудик, с этим будет небогато. И даже классика начнет валиться в такой же по смыслу штопор. Менее сурово, но начнет. Я такое даже видел, хоть это и постараться надо.
> А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб
> (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность.Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в состоянии десяток seek в секунду сделать и будет читать на практически максимальной скорости. Но в торрентах бывает и блок 64К, вот тут с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут даже классика с экстентами начнет задыхаться от прорвы метаданных.
Кстати чисто теоретически, CoW при преаллокации мог бы рассмотреть это как хинт: ага, они собираются писать в этот файл так и сяк. А давайте фрагменты стараться раскладывать друг за другом, в соответствии с их смещением в файле?! Ну то-есть даже CoW вполне мог бы резервировать непрерывный "виртуальный прообраз" файла (который заказали преаллокацией) и по нему раскладывать "паззл" из фрагментов по мере их поступления. Вполне себе CoW логикой. Благо, CoW логике все-равно куда именно фрагмент класть. Можно класть не абы как а чуть более удобно. Почему нет? Другое дело что не все возможные оптимизации аллокации реализованы вот сей момент.
>> А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб
>> (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность.
> Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в
> состоянии десяток seek в секунду сделать и будет читать на практически
> максимальной скорости. Но в торрентах бывает и блок 64К, вот тут
> с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут
> даже классика с экстентами начнет задыхаться от прорвы метаданных.Из личных наблюдений на ZFS торренты по-разному качаются Transmission и Deluge.
Transmission мотает нервы очень сильно как на простой закачке/раздаче, так и на проверке. Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор ФС и проверка торрентов заметно быстрее, чем в Transmission.
Transmission может буквально заблокировать рабочий десктоп так, что окна приложений перестанут перерисовываться, а скорость закачки упадёт. С Deluge такого не замечал.
> Из личных наблюдений на ZFS торренты по-разному качаются Transmission и Deluge.Учтя что они основаны на 2 напрочь разных либах и вероятно имеют разные дефолты - это не удивительно даже.
> Transmission мотает нервы очень сильно как на простой закачке/раздаче, так и на проверке.
А ты пробовал настраивать режимы преаллокации и размеры буферов? В UI такие тонкости не вынесены, т.к. у хомячков от них взорвется мозг. Но они есть и описаны в вике.
> Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор
> ФС и проверка торрентов заметно быстрее, чем в Transmission.Извини, гражданин, у меня трансмишн сугубо в сеть упирается, при том даже без особого твикинга. Откуда напрашивается вывод что что-то у вас в консерватории не то.
> Transmission может буквально заблокировать рабочий десктоп так,
> что окна приложений перестанут перерисовываться,Прости, если твоя операционка обделалась при обработке I/O или paging или при шедулинге процессов - это не вина апликух. По логике вещей, многозадачка должна шедулить ресурсы так чтобы всем равномерно доставалось. Вовремя отбирая бразды правления у приложений и передавая их другим.
Кстати да, это означает что тебя укусил "линуксный" баг с неотзывчивостью системы при тяжелом I/O на медленном накопителе. Да, тот самый который ты так колоритно обcирал в пингвинах. Посмотрим хватит ли у тебя духу обругать уютную бсдшечку за ровно тот же самый баг с теми же симптомами :D.
> а скорость закачки упадёт. С Deluge такого не замечал.
Ну так и запишем: изен признался что его долбит тот же баг который он в пингвинах ругал :). Epic!
>> Deluge ведёт себя шустрее: закачка торрентов не так нагружает нотификатор
>> ФС и проверка торрентов заметно быстрее, чем в Transmission.
> Извини, гражданин, у меня трансмишн сугубо в сеть упирается, при том даже
> без особого твикинга.
> Откуда напрашивается вывод что что-то у вас в
> консерватории не то.Оба клиента сеть загружают одинаково. Но когда много торрентов, Transmission начинает нервировать подлагиванием интерфейса, чего нет у Deluge.
По-видимому, у разработчиков Transmission что-то не так в консерватории, раз нативный клиент так себя ведёт в отличии от интерпретируемого питоновского.>> Transmission может буквально заблокировать рабочий десктоп так,
>> что окна приложений перестанут перерисовываться,
> Прости, если твоя операционка обделалась при обработке I/O или paging или при
> шедулинге процессов - это не вина апликух.Ну да, аппликухи (ВСЕ) белые и пушистые, одна операционка в их лагах виновата и должна оперативно подстраиваться под их требования. :)) А не жирно будет учитывать индивидуальные особенности кривых аппликух? Вон, в Windows учли "опыт" несовместимости и захардкодили в ядре особенности 16 битных популярных приложений, чтобы они не валились от правильной работы операционной системы. Так поступать так же?
> По логике вещей, многозадачка
> должна шедулить ресурсы так чтобы всем равномерно доставалось. Вовремя отбирая бразды
> правления у приложений и передавая их другим.
> Кстати да, это означает что тебя укусил "линуксный" баг с неотзывчивостью системы
> при тяжелом I/O на медленном накопителе. Да, тот самый который ты
> так колоритно обcирал в пингвинах. Посмотрим хватит ли у тебя духу
> обругать уютную бсдшечку за ровно тот же самый баг с теми
> же симптомами :D.В FreeBSD, в отличии от GNU/Linux, курсор мыши по крайней мере не застывает на месте. ;)
>> а скорость закачки упадёт. С Deluge такого не замечал.
> Ну так и запишем: изен признался что его долбит тот же баг
> который он в пингвинах ругал :). Epic!Баг совсем другой — курсор не застывает, другие программы работают в отличие от...
> Оно вообще "первый блин комом". У 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 showLabel: '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-2Label: '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-1Btrfs 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
> Изя, ты как всегда в лужу. Деградация производительности при малом количестве свободного
> места - беда всех CoW файловых систем. Так что ext4/xfs вполне
> нормально живут при почти полной занятости дисков.Может вам повезло ? На лоре полно людей у которых нормально жило а потом ...
> (точнее, требует держать на
> сторадже меньше данных, чем его размер).Админов которые не следуют данному правилу нужно гранать за проф непригодность.
>> (точнее, требует держать на
>> сторадже меньше данных, чем его размер).
> Админов которые не следуют данному правилу нужно гранать за проф непригодность.ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий старое). под это дело у вас хранилище на 20Тб. зачем в такой ситуации фс с cow?
>>> (точнее, требует держать на
>>> сторадже меньше данных, чем его размер).
>> Админов которые не следуют данному правилу нужно гранать за проф непригодность.
> ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что
> сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий
> старое). под это дело у вас хранилище на 20Тб. зачем в
> такой ситуации фс с cow?Если там не будет хотябы 1Tб свободно то скорость записи может так упасть что вся эта хрень подвиснет :)) и дефраг весьма полезен, в ночьное время :)) Интересно было бы увидеть тесты быстродействия фс сего этак через годик эксплуотации.
>>> (точнее, требует держать на
>>> сторадже меньше данных, чем его размер).
>> Админов которые не следуют данному правилу нужно гранать за проф непригодность.
> ну конечно же. представьте сервер видеонаблюдения. вы пишете с камер то что
> сейчас + немало людей смотрят записанное(+ бегает в фоне процесс, подтирающий
> старое). под это дело у вас хранилище на 20Тб. зачем в
> такой ситуации фс с cow?Именно. Абсолютно без пользы.
Может быть месье нагулял предложит пользу от CoW в данном конкретном случае? Особенно интересует классический случай с fixed bitrate и преаллокацией по временным отрезкам.
> Может вам повезло ? На лоре полно людей у которых нормально жило
> а потом ...Ты еще на хабре поищи...
>> Чушь полная. Нишевыми ZFS как раз делает ФС прошлого поколения.
> lol'd
> ну изен с 5 MBps с диска тут уже былТут у нас у одного поциента навязчивые идеи ... Хотя до весны еще далеко.
> Неужели никому zfs не нужна что её полтора энтузиаста пилят?...потому что btrfs будет даже лучше :)
>> Неужели никому zfs не нужна что её полтора энтузиаста пилят?
> ...потому что btrfs будет даже лучше :)бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому да выдавит зфс.
btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего.
> btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего.Бсдишнеги такие бсдишнеги, всегда выдают желаемое за действительное. Без будущего - это хрень типа zfs, где даже экстентный аллокатор не осилили. По поводу чего оно получилось тормозиловом.
> btrfs - мертворожденный проект. Либо будет очередным велосипедом без нормального будущего.Все гораздо печальнее, недостаточно оттестированную фс пихают в убунту, уже почти по дефолту ...
>>> Неужели никому zfs не нужна что её полтора энтузиаста пилят?
>> ...потому что btrfs будет даже лучше :)
> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому
> да выдавит зфс.Что вообще можно не осилить в zfs?
> Что вообще можно не осилить в zfs?Экстентный аллокатор и TRIM например :)
>> Что вообще можно не осилить в zfs?
> Экстентный аллокатор и TRIM например :)Первое сферический конь в вакуме сомнительной нужности, второе если следовать рекомендациям сана и оставлять 5-10% дискового пространства неразмеченным тоже ... нужно как первое :))
> если следовать рекомендациям санак некрофилам
>> если следовать рекомендациям сана
> к некрофиламИ это пишет человек сидящий под виндовс :))
> И это пишет человек сидящий под виндовс :))Why not? (c)
В отличие от винды санка - 100% RIP.
> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому
> да выдавит зфс.Для начала, они посмотрели на основные продолбы ZFS, в частности общую тормознутость. И сделали вместо блочного аллокатора экстентный. За что воздалось - по бенчам сразу видно кто слоупок.
>> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому
>> да выдавит зфс.
> Для начала, они посмотрели на основные продолбы ZFS, в частности общую тормознутость.
> И сделали вместо блочного аллокатора экстентный. За что воздалось - по
> бенчам сразу видно кто слоупок.Бенци в студию, фороникс не предлагать :))
ЗЫ Если екперимент имеет научную основу он повторяем ;)
> бтрфс пишется глядя на зфс но с учётом простоты для пользователя, потому
> да выдавит зфс.Ага сначал вдавит а потом ... может быть :)) Это фс разных систем. Под linux zfs экзотика, не более ... Под bsd btrfs ? Привет из паралельной вселенной ?
Вообще ее пилят Lawrence Livermore National Laboratory для своего IBM Sequoia (топовый суперкомпьютер на сегодня), правда они я так понял больше заинтересованы в zpool, чтобы на нее люстру положить.
http://www.youtube.com/watch?v=c5ASf53v4lI
http://public.dhe.ibm.com/systems/deepcomputing/LLNL_-_Sequo...
Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР??
> Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР??Толстота!..
Улыбнуло ))
> а где найти ZFS пакет для Виндус ХРПополните лицевой счет своего мобильного телефона. Отправьте на номер 7490 SMS с произвольной суммой не менее 10УЕ, данная сумма будет зачислена на счет почтальона который принесёт вам ZFS пакет для вашего дистрибутива Виндус (доставка в день заказа).
7490 смс по 10 баксов - это как-то довольно дофига :)
colinux.org
> Скажите пожалуйста, а где найти ZFS пакет для Виндус ХР??На сайте ubuntu.com :)
Там же, где btrfs. Абзацем выше ссылка. Там попросят регистрацию, но она не обязательная, можно просто нажать "пропустить".
Для Федоры не сделают никак рпм
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991
> Для Федоры не сделают никак рпм
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991Там предпочитают собвственный велопарк соденржать.
> Для Федоры не сделают никак рпм
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=1991для федоры не нужно. федора ядра бсд в репах не держит.
> для федоры не нужно. федора ядра бсд в репах не держит.А оно каким боком, простите?
>> для федоры не нужно. федора ядра бсд в репах не держит.
> А оно каким боком, простите?А оно лишь бы ляпнуть и неважно что.
Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще
> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообщечтение.
правда для чтения хватит fuse
а зачем?
даже если вы винты с zfs заполняете данными и складируете в уголке, то можно с ливсд опенсоляры (и клонов) загрузиться.
при чём в виртуалке.
у меня все сервера переведены по ксен - запустил виртуалку, подсоединил винт и всё.
ну, для десктопа сойдёт и виртуалбокс.
Зыж
кстати, являясь гентушником, пробовал также сабж и однозначно остановился у себя на руте ноута на бтр. с ноября 2011 живу с бтр и не жалуюсь.
По скорости и экономии ресурсов намного лучше zfs и совсем немного хуже ext4.
Cварганил даже себе замену тайм-машин. :D
И даже лучше - не нужен отдельный винт, любой снэпшот равноправен любому субволому - т.е. В любой момент с него можно перезагрузиться и использовать дальше как рут и намного быстрее создаются.
А всё остальное как в маке (снепшоты создаются каждый час за последние сутки, каждые сутки за последнюю неделю, какждую неделю за последние 3-и месяца, каждый месяц за последний год). Так вот, на ноуте гентушника(!!!) - никаких проблем (правда я сам составляю график обновлений ядра и бтрфс-прогс по спискам рассылки. Ну и старые ливсд нельзя использовать)
>[оверквотинг удален]
> ext4.
> Cварганил даже себе замену тайм-машин. :D
> И даже лучше - не нужен отдельный винт, любой снэпшот равноправен любому
> субволому - т.е. В любой момент с него можно перезагрузиться и
> использовать дальше как рут и намного быстрее создаются.
> А всё остальное как в маке (снепшоты создаются каждый час за последние
> сутки, каждые сутки за последнюю неделю, какждую неделю за последние 3-и
> месяца, каждый месяц за последний год). Так вот, на ноуте гентушника(!!!)
> - никаких проблем (правда я сам составляю график обновлений ядра и
> бтрфс-прогс по спискам рассылки. Ну и старые ливсд нельзя использовать)А я предпочитаю на пляж ходить и с девушками знакомиться ...
> А я предпочитаю на пляж ходить и с девушками знакомиться ...Если ты это делаешь так, как здесь пытаешься обсуждать ZFS - я тебе искренне соболезную - ты все руки наверняка уже до мозолей стёр.
>> А я предпочитаю на пляж ходить и с девушками знакомиться ...
> Если ты это делаешь так, как здесь пытаешься обсуждать ZFS - я
> тебе искренне соболезную - ты все руки наверняка уже до мозолей
> стёр.Друг мой, я нехочу ставить диагноз без фотографии, но ваши ассоциации - то "в темноте под одеялом" то "накатить", теперь вот "руки до мозолей стёр" наводят на некоторые размышления. :))) Вы берегите себя :)) ...
> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообщеНет уж спасибо, я выберу ZFS.
Крисс очень опечален этим :/
> Нет уж спасибо, я выберу ZFS.Скатертью дорожка. Правда вот btrfs шустрее и задизайнен лучше. Но выбирать кактус по вкусу - неотъемлимое право каждого индивида.
> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообщеА Btrfs ещё пилят?
а ты подпишись на списки рассылки и сам всё увидишь.
http://vger.kernel.org/vger-lists.html
http://vger.kernel.org/vger-lists.html#linux-btrfs
если кратко - гораздо больше чем в сабже и бсд вместе взятых.
а если учесть, что и сабж, и бсд подходят к порогу того что открыто, то вообще будущее zfs в них в тумане.
> гораздо больше чем в сабже и бсд вместе взятых.Из свежего: http://www.spinics.net/lists/linux-btrfs/msg18435.html
"Date: Wed, 15 Aug 2012 19:28:16 +0200Hi,
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 busyOr 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"
Правда весело?
> Правда весело?Вообще любую фс можно добить, но с бтрфс оно обычно случается достаточно легко на ровном месте. Я когда с ней игрался, умудрился фс за полчаса довести до состояния когда ничего штатное не помогает. С zfs сложнее и в крайнем случае (баг zfsonlinux) данные достаются соляркой.
> Вообще любую фс можно добить, но с бтрфс оно обычно случается достаточно
> легко на ровном месте.Ну так у бздунов по первости тоже воплей было мама не горюй. Вплоть до дедлока всей машины на некоторых операциях.
>[оверквотинг удален]
> 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 на шестой и седьмой ветке тоже проблем было будь здоров.
О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для не работающего толком поделия по сравнению с уже работающим. А при проблемах в "шестой-седьмой ветке" так же дружно кидались какашками "оно не работает"
> О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо
> большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для
> не работающего толком поделия по сравнению с уже работающим.Про это поделие между прочим автор порта zfs считает более совершенным технически и полагает что оно зарулит ZFS со временем. И кстати ваши ZFS вообще не писали. А всего лишь привинтили халяву от саней. Сами вы вообще такого масштаба проект не поятнете нифига. А пингвиноиды вот потянули.
>> О.. уже отползаем.. Сначала хвалимся, что БТР любовно доводят до ума гораздо
>> большее количество энтузиастов чем ZFS. Теперь выясняется, что это нормально для
>> не работающего толком поделия по сравнению с уже работающим.
> Про это поделие между прочим автор порта zfs считает более совершенным технически
> и полагает что оно зарулит ZFS со временем. И кстати ваши
> ZFS вообще не писали. А всего лишь привинтили халяву от саней.
> Сами вы вообще такого масштаба проект не поятнете нифига. А пингвиноиды
> вот потянули.Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :))
Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил из Oracle и, скорее всего, проект ему уже малоинтересен.
> Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :))Они btrfs надизайнили с нуля. Получше чем.
> Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил
> из Oracle и, скорее всего, проект ему уже малоинтересен.Прости, а ничего что он свалили в контору которая занимается хранением данных? :) Проектом он как я понимаю по прежнему занимается весьма даже. Кроме того там ща коммитит толпень народа. Так что твоя трогательная забота о процветании проекта просто умиляет :)
>> Что, "пингвиноиды" ZFS для себя с нуля что ли написали? :))
> Они btrfs надизайнили с нуля. Получше чем.Не "они", а он. Не "получше", а как захотелось ему. RAID-5 и -6 до сих пор не осилил. +детские непонятки с отмонтированием. Для продакшена Btrfs использовать не рекомендуется.
>> Btrfs вообще много чего не умеет, что умеет ZFS. Автор Btrfs свалил
>> из Oracle и, скорее всего, проект ему уже малоинтересен.
> Прости, а ничего что он свалили в контору которая занимается хранением данных?Контора Стива Возняка, по слухам, занимается мобильными девайсами. Автор Btrfs уже там.
> :) Проектом он как я понимаю по прежнему занимается весьма даже.
Не, не слышал.
> Кроме того там ща коммитит толпень народа.
Не, не знаю никого.
> Так что твоя трогательная забота о процветании проекта просто умиляет :)
Признай уже, что Btrfs загибается от недостатка финансирования и мозгов.
> Не "они", а он.Насколько я помню, там была "помощь зала" :). В частности модификацию b-деревьев подсказал какой-то другой перец, ну и так далее.
> Не "получше", а как захотелось ему.
Ему захотелось посмотреть на существующие дизайны и выдернуть лучшее из них, постаравшись не получить явных минусов. Более-менее получилось вроде.
> RAID-5 и -6 до сих пор не осилил.
Ты так говоришь как будто кодит там один Крис.
> +детские непонятки с отмонтированием.
Что-то не заметил "непоняток". В чем они состоят? oO
> Для продакшена Btrfs использовать не рекомендуется.
Тем не менее, его внедряют ынтырпрайзные дистры уже. И даже поддержку декларируют.
>> Прости, а ничего что он свалили в контору которая занимается хранением данных?
> Контора Стива Возняка, по слухам, занимается мобильными девайсами. Автор Btrfs уже там.Насчет слухов не знаю, т.к. не бабка на лавочке. А в описании конторы явно задекларировано что они занимаются современными сторажами. Логично что Крис туда свалил :)
>> :) Проектом он как я понимаю по прежнему занимается весьма даже.
> Не, не слышал.Ну я понимаю, ты не в состоянии лог коммитов в кернель посмотреть до того как языком молоть. Поэтому [как обычно] с умным видом втираешь полную чушь :)
>> Кроме того там ща коммитит толпень народа.
> Не, не знаю никого.Да кто бы сомневался что ты только языком молоть умеешь. А посмотреть лог коммитов в git - это уже слишком сложно для таких как ты.
Однако процесс разработки намного удобнее оценивать не по трепанию языком изенов а по логам коммитов. Ну вот например, в готовящемся ядре 3.6 сделали поддержку send/receive. Как раз кто-то из ZFSников лишний раз заткнется :)
>> Так что твоя трогательная забота о процветании проекта просто умиляет :)
> Признай уже, что Btrfs загибается от недостатка финансирования и мозгов.Признай уже что недостаток мозгов не позволяет тебе посмотреть логи коммитов в эту подсистему линуксного кернеля. Так что долго тебе придется ждать пока он загнется. Если ты не понял, оно надо толпени народа. И по этому поводу загибаться не собирается. Там его такая толпень нынче пилит что многие другие позавидуют.
> Что-то не заметил "непоняток". В чем они состоят? oOВ этом: http://www.opennet.me/openforum/vsluhforumID3/86056.html#64
>>> Так что твоя трогательная забота о процветании проекта просто умиляет :)
>> Признай уже, что Btrfs загибается от недостатка финансирования и мозгов.
> Признай уже что недостаток мозгов не позволяет тебе посмотреть логи коммитов в
> эту подсистему линуксного кернеля.Нет. Мне не хочется тратить время на всякую недоделанную чушь.
> Так что долго тебе придется ждать пока
> он загнется. Если ты не понял, оно надо толпени народа.Oracle сама Btrfs не нужна == не надо энтерпрайзу с большими базами и клиентам Oracle. Это предельно чётко и ясно.
Для мобильных девайсов Btrfs, возможно, будет ещё ничего, может заменит морально отсталую Ext4. Но пока даже в этом подвижек никаких.
> И
> по этому поводу загибаться не собирается. Там его такая толпень нынче
> пилит что многие другие позавидуют.Не пугай меня.
> В этом: http://www.opennet.me/openforum/vsluhforumID3/86056.html#64О, по одному случаю да еще на кернеле который на почти 2 версии старее текущего изен делает глобальные выводы. Да чтоб ты бзди так же оценвал, а? :)
> Нет. Мне не хочется тратить время на всякую недоделанную чушь.
Тогда не понятно зачем засорять форум откровенной дезой. Пользуйся себе своей не-чушью и трать время на чтение файлов со скоростью 6мб/сек, мне не жалко. А для себя я вообще такие скорости приемлимыми в принципе не считаю.
> Oracle сама Btrfs не нyжна == не надо энтерпрайзу с большими базами
Вообще, нужна. Как тонкая прослойка между их БД и накопителями. Впрочем, участие оракла сводилось к целому Крису. Который никуда не делся и занимается тем же чем и занимался. А клиенты оракля вообще никакого влияния на процесс не оказывают ;)
> и клиентам Oracle. Это предельно чётко и ясно....и наверное именно поэтому оракель декларирует поддержку btrfs в unbreakable? Как-то твоя красивая теория не стыкуется с наблюдаемыми на деле фактами, что намекает ;)
> Для мобильных девайсов Btrfs, возможно, будет ещё ничего, может заменит
> морально отсталую Ext4. Но пока даже в этом подвижек никаких.Смотрите, известный эксперт-аналитик по ФС и их развитию выступает с докладом. Будет забавно почитать это через годик-другой :)
>> И по этому поводу загибаться не собирается. Там его такая толпень нынче
>> пилит что многие другие позавидуют.
> Не пугай меня.Да чего тебя пугать, ты сам себе такое пугало что тебя пугать даже и не требуется. Ну вот например ты сам себе спровоцировал эквивалент обcираемого тобой "линуксного" бага с плохой отзывчивостью системы. И сам признался в этом. По логике вещей ты должен обругать fbsd за то что там есть такой паскудный баг, который ты так крыл в линуксах :)
> Признай уже, что Btrfs загибается от недостатка финансирования и мозгов.Оракл похерил ... и вероятно присматривает чтоб кто случайно не помог.
Вот когда зарулит тогда и поговорим. Хотя я подозреваю всё будет как обычно. Работать будет но... то лапы мерзнут, то хвост отваливается.
> Изя, давай будем честными, в BSD с ZFS на шестой и седьмой
> ветке тоже проблем было будь здоров.("Изя" это кто?)
На шестой ветке разве есть поддержка ZFS? Что-то меня гложут сомнения в этом.
ZFS на седьмой ветке была чисто экспериментальной, а готовой к промышленному использованию эта ФС объявлена лишь в восьмой версии FreeBSD.
> ("Изя" это кто?)Это ты. //информирует Кэп
> эта ФС объявлена лишь в восьмой версии FreeBSD.
...что не мешало ей ловить локапы + не был нормально реализован sendfile(). Такой продакшн.
>> Когда допилят brtfs, тогда zfs будет не нужен на linux-e вообще
> А Btrfs ещё пилят?Да, увы ...
> достаточно стабилен для использования энтузиастамиВот уж эти выражения ))) Так да или нет?
> Вот уж эти выражения ))) Так да или нет?Да, но
>энтузиастамиТо есть в продакшн не годится пока что.
How to install Fedora on top of ZFS
http://rudd-o.com/linux-and-free-software/installing-fedora-...
How ZFS continues to be better than btrfs
http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-...
> How ZFS continues to be better than btrfs
> http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-...Видно, что человек не понимал половину из того, о чём пишет...
ага.
>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 Snapshotshttp://docs.oracle.com/cd/E19082-01/817-2271/ghzvz/index.html
>[оверквотинг удален]
> ха!
> Джаст 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
И никакой простыни!
идиотом прикидываешься?
мне надо просто перегрузиться в другой субволум, а тебе провести процесс восстановления(!!!).
который ещё не факт что закончится успешно.
ззыж
и да, врёшь уже откровенно (или такой знаток)смотрим доку 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-е(!!!) перезагрузки.
Ты этого не знал? или нагло соврал?
>[оверквотинг удален]
> # 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 не знаю как, так что не претендую на всеобъемлемость.
>делал несколько раз, проблем не испытывалдай угадаю - данный сервер работает только для тебя одного (бесусловно-любимого)
зыж
не, в линухе тоже можно перейти в синглмод, смонтировать рут в ридонли, потом смонтировать в рут другой субволум и перейти в init 3.
а можно просто смонтировать в другую точку монтирования и вытащить что нужно.это не отменит того, что ты делаешь rollback данных, а я просто монтирую.
при этом случай кернел-паник и не_возможность загрузки тобой вообще не рассматривается.
ну грузится с рут, не монтируется вообще.
у меня есть старый, проверенный субволум, у тебя нет.
> при этом случай кернел-паник и не_возможность загрузки тобой вообще не рассматривается.
> ну грузится с рут, не монтируется вообще.
> у меня есть старый, проверенный субволум, у тебя нет.Так как у меня система сама на ZFS, то kernel panic при невозможности загрузиться с ZFS не возникает (что логично). В этом случае используется загрузочная флешка для восстановления системы — просто загружается система восстановления и выясняется причина невозможности штатной загрузки.
Было такое: невозможно загрузиться.
Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld) и система недоустановилась; остались снимки предыдущего образа рабочей ОС.
Решение проблемы: гружу с флешки систему восстановления, импортирую пул в определнную точку монтирования, разбираюсь с занятым местом, делаю zfs rollback файловым системам старого образа; перезагружаюсь уже в работающую систему.
> Было такое: невозможно загрузиться.
> Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld)Печалька пионерская... Нормальным binary-based дистрибутивам такой ахтунг неведом.
Ну да, для таких извращений CoW нужен в принципе, потому что шанс угробить систему любым чихом неиллюзорен.
>> Было такое: невозможно загрузиться.
>> Оказалось: кончилось место в пуле во время обновления операционной системы (make installworld)
> Печалька пионерская... Нормальным binary-based дистрибутивам такой ахтунг неведом.
> Ну да, для таких извращений CoW нужен в принципе, потому что шанс
> угробить систему любым чихом неиллюзорен.Это вы про обновление grub2 после которого система может не подняться ? :)) Помню помню ... :))
> Это вы про обновление grub2 после которого система может не подняться ?
> :)) Помню помню ... :))У вас не поднялась? У меня за последние 5 лет ни одной проблемы с GRUB. ЧЯДНТ?
> Решение проблемы: гружу с флешки систему восстановления, импортирую пул в определнную точку монтирования, разбираюсь с занятым местом, делаю zfs rollback файловым системам старого образа; перезагружаюсь уже в работающую систему.вот и я говорю - жесть.
я же просто монтирую снепшот.зыж
ну глупо же отрицать очевидное - концепция что снэпшот не что иное, как субволум гораздо прогрессивнее, удобнее и безопаснее.ззыж
>Так как у меня система сама на ZFS, то kernel panic при невозможности загрузиться с ZFS не возникает (что логично).попахивает "махровым" фанатизмом.
>[оверквотинг удален]
>> 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 не радует, а доверять это одминоДЦ уж тем более ...
> ага.
>>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. На первый взгляд это мелочь, но так понемногу и набирается до того, что что-то сложнее одной фс уже неуправляемо.
>Да, можно отдельно смонтировать 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)бтр вообще по структуре куда более юниксвейна.
а значит вариантов работы с ней гораздо больше и на любой вкус.
ззыж
>индейская национальная изба - фигвам называется!чё за бред?
ну создайте два субволума в zfs с одинаковыми именами, удачи.зыж
более идиотского примера привести наверное было бы трудно.
>> How ZFS continues to be better than btrfs
>> http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-...
> Видно, что человек не понимал половину из того, о чём пишет...Этот товарисч делал zfs-fuse если что...
> Этот товарисч делал 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.
> Этот товарисч делал zfs-fuse если что...Тогда понятно почему он в бтр такие ляпы делает
>> How ZFS continues to be better than btrfs
>> http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-...
> Видно, что человек не понимал половину из того, о чём пишет...Это нужно читать как алекс непонял и половины написанного :))