The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от opennews (??) on 19-Сен-12, 13:02 
Представлен (https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...) новый экспериментальный выпуск  модуля для ядра Linux с поддержкой ZFS - zfsonlinux 0.6.0-rc11 (http://zfsonlinux.org/). Несмотря на официальный статус экспериментальной разработки, пакет ZFSonLinux достаточно стабилен для использования энтузиастами. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo и Sabayon Linux. Представленная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава FreeBSD 9.0 и 8.3.


В новой версии продолжено портирование компонентов ZFS из проекта Illumos, в рамках которого создано полностью свободное и развиваемое независимым сообществом ответвление от кодовой базы OpenSolaris. Среди наиболее значительных улучшений отмечено:


-  Поддержка устройств подкачки на основе ZVOL;
-  Поддержка ядер Linux с патчами PREEMPT_RT (ветка "-rt");
-  Заметно увеличена производительность msync();
-  Улучшено поведение в условиях нехватки памяти;
-  Расширены возможности поиска при выполнении 'zpool import';
-  Добавлена поддержка команды  'zstreamdump';
-  Добавлена поддержка команды 'zfs get -t datatype".

URL: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...
Новость: https://www.opennet.ru/opennews/art.shtml?num=34885

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Kroz email(??) on 19-Сен-12, 13:02 
Как оно на практике?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от redixin email(ok) on 19-Сен-12, 14:00 
Юзаю несколько месяцев на сервере который хранит бекапы (бекапы бекапов. фс все таки экспериментальная), а так же несколько слейвов mongodb которые снапшотятся. Фс юзается весьма активно, и даже пару раз было внезапное отключение питания и проблем не возникало.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

13. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +4 +/
Сообщение от iCat (ok) on 19-Сен-12, 15:08 
Больше года:
- на томе, лежащем на zfs, подключенном по iSCSI к Windows 2003 крутится пяток SQL-баз 1С.
- на томе, расположенном на двух HDD по схеме ZRAID, с включённой дедупликацией (коэффициент дедупликации приблизился к 3x), лежат файлы пользователей.

Снапшоты делаются ежедневные (с глубиной ротации 31 день) и еженедельные (с глубиной ротации 365 дней).
Пользовательские файлы раздаются SAMBA. Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Хрен с горы on 19-Сен-12, 15:15 
>Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет...

Круто! А как такое делается?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

23. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от Elhana (ok) on 19-Сен-12, 15:34 
>>Что интересно: пользователи при right-click на папке или файле выбирают свойства, а там - "Предыдущие версии", выбирают архивную копию за требуемую дату и копируют к себе, куда им надо... Впрочем, это уже, наверное, к zfs отношения не имеет...
> Круто! А как такое делается?

Точно также как тут: http://help.ubuntu.ru/wiki/samba_shadow_copy
только снапшоты zfs, а не LVM - на одном диске и без оверхеда по лишней записи.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

25. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Хрен с горы on 19-Сен-12, 15:36 
Спасибо!
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

46. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от redixin email(ok) on 19-Сен-12, 17:53 
> подключенном по iSCSI

кстати, оно не тормозит?

> на двух HDD по схеме ZRAID

raidz из двух дисков?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

59. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iCat (ok) on 20-Сен-12, 01:48 
>> подключенном по iSCSI
>кстати, оно не тормозит?

"тормозит" - понятие относительное. С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются...

>> на двух HDD по схеме ZRAID
>raidz из двух дисков?

А чем это смущает?

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

79. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от ананим on 20-Сен-12, 13:55 
>С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются...

ну ещё бы! :D
пусть только попробуют!

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

133. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iCat (ok) on 22-Сен-12, 14:56 
>>С теми базами, которые лежат на iSCSI работают программисты. Они не жалуются...
> ну ещё бы! :D
> пусть только попробуют!

У меня с ними хорошие взаимоотношения.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

69. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 20-Сен-12, 10:51 
Достаточно стабильно для меня, чтобы не бояться держать на нём домашнюю директорию: при кросс-платформенной разработке под несколько Юниксов возникает проблема обмена данными между различными установленными на одной и той же машине операционками.

Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris поддерживают разве что FAT. :) А ZFS очень и очень выручает.

Ну и, конечно, приятно наличие "RAID'а для notebook'ов" -- при установке "zfs set copies=3" авторы ZFS _гарантируют_ сохранность данных при разрушении ~8% поверхности HDD, что для вечно таскаемого ноута не такая уж невозможная ситуация -- совет поставить второй HDD на USB как-то не радует. :)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

72. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от nagual email(ok) on 20-Сен-12, 11:14 
> Достаточно стабильно для меня, чтобы не бояться держать на нём домашнюю директорию:
> при кросс-платформенной разработке под несколько Юниксов возникает проблема обмена данными
> между различными установленными на одной и той же машине операционками.
> Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris
> поддерживают разве что FAT. :) А ZFS очень и очень выручает.
> Ну и, конечно, приятно наличие "RAID'а для notebook'ов" -- при установке "zfs
> set copies=3" авторы ZFS _гарантируют_ сохранность данных при разрушении ~8% поверхности
> HDD, что для вечно таскаемого ноута не такая уж невозможная ситуация
> -- совет поставить второй HDD на USB как-то не радует. :)

С ноутами засада. Если стукнуть диск заклинит и тогда и ZFS не поможет а если поставить SSD и там контролер вылетит тот вероятность восстановления вообще 0% ...

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

73. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 20-Сен-12, 12:50 
> С ноутами засада. Если стукнуть диск заклинит и тогда и ZFS не поможет

Если именно _заклинит_ -- то есть, из-за гироскопического эффекта искривится ось шпинделя -- тогда можно снять тарелку, переставить в рабочую технологическую "банку" и попытаться "поймать калибровку". Дорого, требует аргонового бокса и терпения, но для данных совершенно безопасно. Если же калибровка "не ловится", тогда нужно примерно 5-6 млн. руб. и установка для рамановской спектроскопии (спектроскопии комбинационного рассеяния) -- ну и, конечно, мощная числодробилка для спектрального анализа.

Не надо думать, что варианты теоретические -- из-за потерь описания и алгоритмов шифрования магнитных лент NASA до сих пор не может прочитать данные из космоса, полученные между 1959 и 1965 годами, они стоят гораздо дороже пяти миллионов рублей, так же и данные, хранившиеся на "склинившем" винчестере ноутбука могут стоить пару вагонов с такими ноутбуками. :)

А вот если головкой прочертит по поверхности, тогда шансы на восстановление без избыточности довольно призрачны.

Про SSD согласен, во всяком случае, пока -- на текущий момент технологии восстановления данных с разрушившегося SSD мне неизвестны.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

101. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 02:51 
> -- тогда можно снять тарелку, переставить в рабочую технологическую "банку" и
> попытаться "поймать калибровку". Дорого, требует аргонового бокса и терпения,

Аргон то нафига? Хитачики вон еще только собираются делать диски с гелием. А в современных пока-что обычный воздух. Все-равно банка не идеально герметична. Так что и простой воздух катит, только обеспыленный, так что то о чем вы вещаете - "чистая комната". Ну или чистый бокс для тех кто не настолько крутой. А вот насчет всего остального есть крупные сомнения что такая операция закончится успехом. Во первых если по диску долбанули так что шпиндель согнулся, есть шанс что головы заодно порядочно запилили поверхность. Во вторых, хотя на блинах и есть сервометки по которым и позиционируются головы, у каждого винта есть еще и индивидуальные калибровки. Сомнительно что они подойдут при такой пересадке, а пересчитать их врядли выйдет кроме как на фабрике. Даже если допустить что такой хардкор мог бы привести к успеху, такая долботня специалиста потребной квалификации стоит как целая стопка жестких дисков. По поводу чего, простите, намного проще и дешевле просто делать бэкапы важных данных.

> но для данных совершенно безопасно. Если же калибровка "не ловится", тогда нужно примерно
> 5-6 млн. руб. и установка для рамановской спектроскопии (спектроскопии комбинационного
> рассеяния) -- ну и, конечно, мощная числодробилка для спектрального анализа.

И как, много винтов таким методом прочитали? Там же еще кодирование, специфичное для производителя и прочая - придется полностью реверсить все и вся. Я допускаю что особо крутые лабы могут даже в принципе осилить сие для сильно некоторых производителей за сильно отдельные бабки или получить инфо от производителя даже. И то не факт.

> дороже пяти миллионов рублей, так же и данные, хранившиеся на "склинившем"
> винчестере ноутбука могут стоить пару вагонов с такими ноутбуками. :)

Капитан намекает что если у кого есть такие ценные данные то обычно и бэкапы есть.

> Про SSD согласен, во всяком случае, пока -- на текущий момент технологии
> восстановления данных с разрушившегося SSD мне неизвестны.

Отпаять микросхемы флеша да прочитать на программаторе. Вот и вся методика. Ни вам чистых боксов, ни нежной механики, ни супердупер калибровок. Далее потребуется разгрести логику wear leveling + сжатие (если есть, оным особенно славится SandForce, юзающий его для ускорения записи) чтобы отстроить нормальный образ девайса эквивалентный тому что контроллер SSD вывесил бы операционке. У современных контроллеров может быть достаточно навороченно, но все это как раз вполне реально, т.к. требует только мозговых усилий и они зачастую были проделаны. Шифрование (если было) - скорее всего не разгребут. А так - продвинутые сервисмэны все это умеют. И поскольку реверсить wear leveling надо лишь 1 раз в отличие от возни с механикой каждый раз, а далее все написанный софт будет на автомате разруливать - есть даже надежда на не очень конский ценник. Но это очень зависит от.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

112. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:04 
> Отпаять микросхемы флеша да прочитать на программаторе. Вот и вся методика. Ни
> вам чистых боксов, ни нежной механики, ни супердупер калибровок.

Сразу видно месье не в теме ...

> Далее потребуется
> разгрести логику wear leveling + сжатие

Прецендентов пока небыло.


Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

178. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:30 
> Сразу видно месье не в теме ...

Мсье как раз мониторит состояние отрасли.

>> разгрести логику wear leveling + сжатие
> Прецендентов пока небыло.

А как же тогда конторы по дата рекавери предлагают достать информацию с SSD и флешек? Или предлагается поверить в то что nagual эксперт а все кто предлагает такие услуги - гонщики?


Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

197. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 23-Сен-12, 17:08 
> Мсье как раз мониторит состояние отрасли.

Месье мэнаджэр ? :-))

> А как же тогда конторы по дата рекавери предлагают достать информацию с
> SSD и флешек? Или предлагается поверить в то что nagual эксперт
> а все кто предлагает такие услуги - гонщики?

Почуствуйте разницу между "предлагают" и "достать". Хотябы приведите сравнительно цены этого "достать" между SSD и HDD.

Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

224. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 20:22 
> Месье мэнаджэр ? :-))

Нет. Мсье просто интересуется подобными вопросами.

>> а все кто предлагает такие услуги - гонщики?
> Почуствуйте разницу между "предлагают" и "достать". Хотябы приведите сравнительно цены
> этого "достать" между SSD и HDD.

Простите, с HDD в сложных случаях цена может быть даже более конская или же данные вообще не смогут достать.

Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

126. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Клыкастый2 on 21-Сен-12, 16:36 
> Как ни смешно, но кроме ZFS _одновременно хорошо_ FreeBSD, Linux и Solaris

Вы так говорите, как будто постоянно в 3 операционки винты перетыкаете.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

71. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 20-Сен-12, 11:09 
Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS.

Oracle, к сожалению, "распылило усилия", и не в лучшую сторону -- в частности, поддержка использования ZFS DMU в Lustre была практически готова ещё в 2010 году, но Oracle практически забросила Solaris и ZFS, так что допиливать поддержку пришлось сторонним организациям.

ldiskfs в Lustre обладает довольно серьёзным ограничением на том -- всего 8 ТБ. Конечно, "в те годы, когда Коран писали...", оно было и ничего, но не во второй декаде XXI века.

Но LLNL не дремлет: http://zfsonlinux.org/llnl-zfs-lustre.html

Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет.

В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

75. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 13:39 
однобокое суждение.
1. вначале люстру санки насильно прогнули под zfs и не доделали.
теперь в этих недоделках оракл конечно виноват.
ага. а то что там вполне возможно просто архитектурные ограничения (нафиг там zfs, если она до этого и без него отлично работала? решили тормозить непадецки? ну-ну).
разрабы помалкивают, но есть определённая уверенность, что люстра БЕЗ zfs лучше люстры С zfs.
санкам это было нужно - они с линухом конкурировали. ораклу же всё-равно что продавать.
2. на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph.
конечно можно это не замечать ("люстра то в топ500, а где ceph?" - эдакий мс-подход). как и то, что статус её разработки примерно такой же, как и в люстре+zfs.
в любом случае на данный момент факт такой:
3. в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет - собственно а нахрена уже работающей люстре из оперного театра ещё и вот та гармонь с балалайкой.
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

78. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от ананим on 20-Сен-12, 13:54 
зыж
А вообще прикольный пассаж! :D
>Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет.
>В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится.

сводится к такому:
"в топ500 есть люстра, поэтому zfs круче btrfs".

прикольно. вы в сфере маркетинга работаете? :D

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

83. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 20-Сен-12, 15:58 
> А вообще прикольный пассаж! :D
>>Вполне может быть, что Sequoia (№1 в Top 500 суперкомпьютеров) использует именно Люстру поверх ZFS под Линуксом. Или будет.
>>В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится.
> сводится к такому:
> "в топ500 есть люстра, поэтому zfs круче btrfs".

А как вы собираетесь сравнивать качество программного обеспечения, если не по месту его использования? По сексуальной ориентации авторов, что ли?-)

Ню-ню.

> прикольно. вы в сфере маркетинга работаете? :D

А вы с какой целью интересуетесь?

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

84. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 16:02 
>А как вы собираетесь сравнивать качество программного обеспечения, если не по месту его использования?

а я и сравниваю... на своём ноуте! :D
а в топ500 их сравнение пока не предвидится.

>> прикольно. вы в сфере маркетинга работаете? :D
>А вы с какой целью интересуетесь?

с целью школы и времени обучения.
интересно в общем.

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

95. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:16 
>> А как вы собираетесь сравнивать качество программного обеспечения, если не по месту
>> его использования?
> а я и сравниваю... на своём ноуте! :D

Ага. Люстровы
>>> прикольно. вы в сфере маркетинга работаете? :D
>>А вы с какой целью интересуетесь?
> с целью школы и времени обучения.
> интересно в общем.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

96. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:19 
>> А как вы собираетесь сравнивать качество программного обеспечения, если не по месту
>> его использования?
> а я и сравниваю... на своём ноуте! :D

Ага. Люстровый кластер на виртуалках развёрнут, да?

Ну, админы localhost'а -- большие специалисты по качеству программного обеспечения...

> а в топ500 их сравнение пока не предвидится.

... и по прогнозам, это всем известно.

>>> прикольно. вы в сфере маркетинга работаете? :D
>> А вы с какой целью интересуетесь?
> с целью школы и времени обучения.

Я готов вас обучить. Готовы ли вы платить за обучение?

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

98. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 21-Сен-12, 01:43 
Не, млин, зетэфесный!!!

Зыж
> Я готов вас обучить. Готовы ли вы платить за обучение?

БЕЗУСЛОВНО.
Как только вы докажите свою квалификацию.
Пока - ниже двоечки.

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

102. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 03:13 
> прикольно. вы в сфере маркетинга работаете? :D

А это у всех солярщиков и маркетоидов так. Зато наш маркетолог не умеет чинить SSD. А те кто занимается data recovery вполне осиливают SSD, потому как там все относительно просто как раз. И данные в цифровом виде вынуть прямо из чипов можно.

Другое дело что чем навороченнее ФС, чем больше там слоев RAID, сжатия, дедупликации и прочих снапшотов - тем меньше шансов что спецы по дата рекавери смогут этого шалтая-болтая собрать в нечто работающее и тем больше они будут возиться и дороже сдерут, т.к. все менее автоматически и все более геморройно по мере возрастания навороченности ФС. А встроенные средства починки из откровенно убитого состояния у ZFS хиленькие, так что на автоматику спецам надеяться не придется особо, как и на то что частично разрушенная ФС сможет сама себя как-то прочитать. В этом плане чем проще ФС, тем лучше.

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

113. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:06 
>[оверквотинг удален]
> в цифровом виде вынуть прямо из чипов можно.
> Другое дело что чем навороченнее ФС, чем больше там слоев RAID, сжатия,
> дедупликации и прочих снапшотов - тем меньше шансов что спецы по
> дата рекавери смогут этого шалтая-болтая собрать в нечто работающее и тем
> больше они будут возиться и дороже сдерут, т.к. все менее автоматически
> и все более геморройно по мере возрастания навороченности ФС. А встроенные
> средства починки из откровенно убитого состояния у ZFS хиленькие, так что
> на автоматику спецам надеяться не придется особо, как и на то
> что частично разрушенная ФС сможет сама себя как-то прочитать. В этом
> плане чем проще ФС, тем лучше.

Месье тонко манипулирует понятиями, сначала говорит про SSD потом оказывается что это уже ZFS не думаю что он это делает со злым умыслом, куда ему болезному :)) просто провалы в памяти на фоне осеннего обострения ...

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

180. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:35 
> Месье тонко манипулирует понятиями,

Не понятно в каком месте манипуляция. Обычный капитанинг. Если вы припретесь в дата рекавери лабу что с SSD что с HDD которые были пулом ZFS - тут вас обдерут, да. Если ZFS вот так сходу не соберется - это будет попадос, потому что собирать такое монстрило по кусочкам - удовольствие очень так себе. То же самое касается и RAID, особенно экзотичных. Дешево, просто и быстро - только типовые и массовые грабли. А всякий кастом будет стоить вам совершенно отдельных денег.

> сначала говорит про SSD потом оказывается что это
> уже ZFS не думаю что он это делает со злым умыслом,

Вы еще и думать умеете?

> куда ему болезному :)) просто провалы в памяти на фоне осеннего обострения ...

Реквестирую скан диплома, подтверждающий вашу квалификацию, позволяющую ставить подобные диагнозы. Иначе будете объявлены шарлатаном.

Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

82. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 20-Сен-12, 15:52 
> 1. вначале люстру санки насильно прогнули под zfs и не доделали.
> теперь в этих недоделках оракл конечно виноват.

Не "не доделали", а "не успели доделать до поглощения Ораклом".

> ага. а то что там вполне возможно просто архитектурные ограничения (нафиг там zfs,
> если она до этого и без него отлично работала? решили тормозить непадецки? ну-ну).

"Там" -- это где? В Lustre? Или в ldiskfs?

Если в Lustre, то там никаких архитектурных ограничений нет (так же, как в TCP нет ограничения на размер передаваемых во время одного connect()'а данных). А если в ldiskfs -- то да, есть, о чём я и написал. А в связке ZFS DMU/Lustre их нет, и этот код есть, и работает.

Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать?

> на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph.

Я их весь сайт облазил. Дайте, пожалуйста, ссылку внутри ceph.com, где написано, что "на базе BtrFS, и рассчитывая на её архитектурные особенности".

> в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет

Это у вас откуда такая уверенность, что нет?

Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца Sequoia. Вы лично в LLNL звонили, что ли?

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

85. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 20-Сен-12, 16:06 
>[оверквотинг удален]
> я и написал. А в связке ZFS DMU/Lustre их нет, и
> этот код есть, и работает.
> Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать?
>> на базе бтр и рассчитывая на её архитектурные особенности, развивается ceph.
> Я их весь сайт облазил. Дайте, пожалуйста, ссылку внутри ceph.com, где написано,
> что "на базе BtrFS, и рассчитывая на её архитектурные особенности".
>> в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет
> Это у вас откуда такая уверенность, что нет?
> Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца
> Sequoia. Вы лично в LLNL звонили, что ли?

Кстати ОРАкля zfs v30 v31 под свободной лицензией не пускает ... неудивительно что это в linux не принимается ... Вобщем можно подвести итог: ОРАкле удалось задавить ZFS бтрфс мускуль опеофис и даже жабу :-))) ... вобщем все до чего ручки дотянулись.

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

87. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 16:18 
btrfs очень сильно развивается.
число коммитов (и участников) увеличилось если не в десятки, то в разы.
недавно вот тестировал сэнд/ресив. вроде работает.

вот пруфы - список рассылки http://vger.kernel.org/vger-lists.html#linux-btrfs
график коммитов - http://dir.gmane.org/gmane.comp.file-systems.btrfs
сами патчи - http://www.spinics.net/lists/linux-btrfs/ ("сабжектс" начинаются с [PATCH] Btrfs:)

сейчас разработка идёт очень активно.
что характерно, специалистами оракл - процентов 5, не более на мой взгляд.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

182. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:36 
> btrfs очень сильно развивается.

Ну так бсдшные оналитеги не пописаны на рассылки и список коммитов не смотрят. Зато аналитику толкнуть горазды.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

187. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от iZEN (ok) on 23-Сен-12, 12:49 
>> btrfs очень сильно развивается.
> Ну так бсдшные оналитеги не пописаны на рассылки и список коммитов не
> смотрят. Зато аналитику толкнуть горазды.

А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована для продакшена баз данных.
http://www.spinics.net/lists/linux-btrfs/msg19006.html
//---
Subject: Re: Experiences: Why BTRFS had to yield for ZFS
From: Avi Miller <avi.miller@xxxxxxxxxx>
Date: Wed, 19 Sep 2012 07:46:26 +1000
Cc: Casper Bnag <casper.bang@xxxxxxxxx>, linux-btrfs@xxxxxxxxxxxxxxx
In-reply-to: <5058A5C8.8080107@affinityvision.com.au>

Hi,

On 19/09/2012, at 2:48 AM, Andrew McGlashan <andrew.mcglashan@xxxxxxxxxxxxxxxxxxxxx> wrote:

> On 17/09/2012 8:05 PM, Avi Miller wrote:
>> Oracle Database is not certified to run on either btrfs or ZFS on Linux, so if certification is an issue, you can't use either filesystem. Out of interest, have you done a performance benchmark with ASM using ASMlib on the same platform?
>
> I thought that Oracle considered BTRFS to be production ready.  It
> surprises me that running an Oracle database on BTRFS is not a supported
> configuration.

The Oracle Linux team considers btrfs production-ready and we support it for production purposes for customers. However, we have nothing to do with Database and their certification process, and the Database (and other) product teams have not certified it for use with their products yet. This is also why product certification lags: we have nothing to do with individual product certification processes on various operating systems/platforms.

So, while I'm aware that the database team is planning to certify btrfs "at some point", I suspect with Oracle OpenWorld coming up in a few weeks time, they have other things on their plate right now. :)

--
Oracle <http://www.oracle.com>
Avi Miller | Principal Program Manager | +61 (412) 229 687
Oracle Linux and Virtualization
417 St Kilda Road, Melbourne, Victoria 3004 Australia

---//

Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

227. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 20:25 
> А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована
> для продакшена баз данных.

Бсда вообще никак не сертифицирована для оракла. Ни с ZFS, ни без. Так что причина понтов не понятна.

Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

235. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:34 
>> А чего там смотреть? Всё и так ясно — Btrfs не сертифицирована
>> для продакшена баз данных.
> Бсда вообще никак не сертифицирована для оракла. Ни с ZFS, ни без.
> Так что причина понтов не понятна.

Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену, а вендоры готовых решений что-то не торопятся на неё переходить. Почему? Беспонтово потому что — терять данные на ровном месте никто не хочет, кто бы что бы там не объявлял.

А вот пионеры в лице User294 всё ещё надеются, что в Btrfs произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть напишут нормальный дефрагментатор и допишут btrfsck, которые сделают работу этой замечательной во всех отношениях CoW ФС более-менее человечной, а не сикась-накось. Про сертификацию Oracle СУБД для работы на этой замечательной ФС я уже не говорю — что-то движется ЗА горизонтом, но очертания не ясны.

Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

239. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:38 
> А вот пионеры в лице User294 всё ещё надеются, что в Btrfs
> произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть

Не надо поддержки RAID-5 на уровне ФС. Только не это.

> напишут нормальный дефрагментатор

А в ZFS его не напишут никогда. Хотя CoW FS без нормального дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением read/add/delete/overwrite примерно в 100/1/1/0.

Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

247. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:59 
> Не надо поддержки RAID-5 на уровне ФС. Только не это.

Почему? Что плохого в RAID-5 на уровне ФС?

>> напишут нормальный дефрагментатор
> А в ZFS его не напишут никогда. Хотя CoW FS без нормального
> дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением read/add/delete/overwrite примерно в 100/1/1/0.

Я вроде как опроверг твоё мнение на счёт скорости софтверного RAID-5 (RAID-Z). Да, действительно, при заполнении на 97-99% операции чтения-записи на такой пул тормозят. Но если свободно хотя бы 15 — лучше 30 ГБ, то скорости чтения/записи будут в порядке.
Для SSD это нивелируется ещё больше, так как на SSD не действует естественная фрагментация CoW ФС.

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

265. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 22:55 
> Я вроде как опроверг твоё мнение на счёт скорости софтверного RAID-5 (RAID-Z).

Это читом с закешированным файлом? Нет уж, давай либо на холодное кеширование, либо файлом более чем размер кеша. Вот тот самый 14-гиговый файл, думаю, будет неплохим примером, если в системе не более 8 Гб памяти.

Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

513. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 21:06 
>> А вот пионеры в лице User294 всё ещё надеются, что в Btrfs
>> произойдут качественные изменения, появится поддержка RAID-5 на уровне ФС, может быть
> Не надо поддержки RAID-5 на уровне ФС. Только не это.
>> напишут нормальный дефрагментатор
> А в ZFS его не напишут никогда. Хотя CoW FS без нормального
> дефрагментатора/GC в долгосрочной перспективе юзабельна только под файлопомойку с соотношением
> read/add/delete/overwrite примерно в 100/1/1/0.

Скажите а Reiser4 это продолжение развития reiserfs ?
http://habrahabr.ru/post/108629/
А то пишут что там с дефрагментацией все плохо:"...Например, при использовании reiser4 на разделе с торрентами, получалось больше 11000 фрагментов на 700-мегабайтный файл, и никаким копированием не получалось сбить этот показатель хотя бы до нескольких сотен. При этом были ощутимы негативные последствия для производительности..."

И еще журнал там тоже только на метаданные ?

Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

532. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 06-Окт-12, 15:42 
> Скажите а Reiser4 это продолжение развития reiserfs ?

Скорее тотальный rewrite "по мотивам".

> А то пишут что там с дефрагментацией все плохо:"...Например, при использовании reiser4
> на разделе с торрентами, получалось больше 11000 фрагментов на 700-мегабайтный файл,

Да и фиг с ним - это совсем сырая ФС для камикадзе.

Ответить | Правка | ^ к родителю #513 | Наверх | Cообщить модератору

327. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 20:38 
> Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену,

Поддержку с ней объявили 2 конторы, ну и не более того. На свой страх и риск, в своих дистрах, юзающих порядком допатченные ядра.

> а вендоры готовых решений что-то не торопятся на неё переходить.

На *BSD вообще мало кто нынче переходит. Если уж сравнивать - так *BSD нынче вообще в *опе.

> Почему? Беспонтово потому что — терять данные на ровном месте никто
> не хочет, кто бы что бы там не объявлял.

Так правильно, такую штуку надо тестировать как следует.

> А вот пионеры в лице User294 всё ещё надеются, что в Btrfs
> произойдут качественные изменения,

Вот чего-чего а фич там уже более чем. Теперь все это застабилизировать окончательно надо. Хотя, конечно, НеПианерам (tm) со скоростью 6Мб на шпиндель виднее как оно там лучше в дисковых технологиях. Но я бы при такой скорости взвыл и соптимизил бы ее в разы, так или иначе :P.

> появится поддержка RAID-5 на уровне ФС, может быть напишут нормальный дефрагментатор

Там уже есть дефрагер. А в zfs мало того что его нет и не планируется, так что оно не подарок для механики, так еще и TRIM нету, так что оно не подарок для SSD. Замечательно. А в btrfs и trim уже есть. Ха.

> и допишут btrfsck,

(аналогов которого в ZFS нет и не предвидится вообще)

> которые сделают работу этой замечательной во всех отношениях CoW
> ФС более-менее человечной, а не сикась-накось.

Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету, fsck - тоже, trim не поддерживается. В общем красота.

> Про сертификацию Oracle СУБД для работы на этой замечательной ФС я уже
> не говорю — что-то движется ЗА горизонтом, но очертания не ясны.

А *bsd оракл в принципе сертифицировать не собирается.

В результате, если не просто наезжать на сферические недостатки в вакууме а сравнить с ближайшими конкурентами, получаем классическую картину "бревно и соринка".

Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

328. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 20:49 
> На *BSD вообще мало кто нынче переходит. Если уж сравнивать - так
> *BSD нынче вообще в *опе.

У соседа корова сдохла, совсем чужой человек, мелочь, а как приятно ... :-)))

> Там уже есть дефрагер. А в zfs мало того что его нет
> и не планируется, так что оно не подарок для механики, так
> еще и TRIM нету, так что оно не подарок для SSD.
> Замечательно. А в btrfs и trim уже есть. Ха.

Неужели после детального разжовывания на хабре вы все еще бредите необходмостью трима ?
Месье не закусывал когда пил тормозную жидкость?

> В результате, если не просто наезжать на сферические недостатки в вакууме а
> сравнить с ближайшими конкурентами, получаем классическую картину "бревно и соринка".

Раз уж зашло о бревнах http://phpsuxx.blogspot.com/2010/08/raid-z.html изучите, чтоб потом не говорили что не заметили.

Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

388. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 18:58 
>> *BSD нынче вообще в *опе.
> У соседа корова сдохла, совсем чужой человек, мелочь, а как приятно ... :-)))

Это вы о себе? Потому что наперли на факт что ФС официально не поддерживается, а про то что у вас вся система официально не поддерживается, а не то что отдельная ФС - тактично промолчали. Очень напоминает озвученный подход. При том что у вас вообще весь хлев выкосило, вы радуетесь что у соседа хоть 1 корова - захворала. Пффф.

>> Замечательно. А в btrfs и trim уже есть. Ха.
> Неужели после детального разжовывания на хабре вы все еще бредите необходмостью трима

Я не только брежу, я им еще пользуюсь. Потому что сам себе не враг. Кстати я и без всяких хабрашвабров представляю себе как все это работает, поэтому сам в состоянии делать выводы.

> Месье не закусывал когда пил тормозную жидкость?

Я не пью тормозную жидкость.

> Раз уж зашло о бревнах http://phpsuxx.blogspot.com/2010/08/raid-z.html изучите, чтоб
> потом не говорили что не заметили.

Ну и что это за капитанинг? Ну есть, ну raid. Да, с чексуммами райд лучше чем без, как раз потому что можно понять какая из версий данных верна в случае когда диск не сдох совсем но стал завирать. Я это и так знаю. И чего?

Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

329. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 20:53 
>> Причина понтов с Btrfs тоже непонятна. Ну объявили её якобы готовой к продакшену,
> Поддержку с ней объявили 2 конторы, ну и не более того. На
> свой страх и риск, в своих дистрах, юзающих порядком допатченные ядра.

Отстали вы от жизни однако со своими тестами криокамеры https://www.opennet.ru/opennews/art.shtml?num=34218

Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

389. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 19:01 
> Отстали вы от жизни однако со своими тестами криокамеры https://www.opennet.ru/opennews/art.shtml?num=34218

Я что-то не понял - в чем проблема? Оракл как раз одна из этих контор. Они сами для себя решили оказывать поддержку по btrfs. Их право.


Ответить | Правка | ^ к родителю #329 | Наверх | Cообщить модератору

331. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 20:55 
> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету,
> fsck - тоже, trim не поддерживается. В общем красота.

TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL...


Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

336. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 24-Сен-12, 21:47 
>> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету,
>> fsck - тоже, trim не поддерживается. В общем красота.
> TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL...

Никак — все изменения под CDDL, чего требует оригинальная лицензия ZFS. Добавленные файлы тоже под CDDL. :p


Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

396. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 20:24 
>>> Ну то-есть, по словам изена, ZFS - кривая ФС. Дефрага - нету,
>>> fsck - тоже, trim не поддерживается. В общем красота.
>> TRIM собираются спереть из ZFSoL, ибо припёрло. Интересно, как обойдут GPL...
> Никак — все изменения под CDDL, чего требует оригинальная лицензия ZFS. Добавленные
> файлы тоже под CDDL. :p

Интересно если все изменения в ZFS могут быть только под CDDL то каким местом zfs v30 закрыто ?

Ответить | Правка | ^ к родителю #336 | Наверх | Cообщить модератору

400. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 22:16 
> Интересно если все изменения в ZFS могут быть только под CDDL то
> каким местом zfs v30 закрыто ?

CDDL - это пермиссив для "юзеров". У компании-автора, априори, неограниченная лицензия. И ничего под CDDL они назад не бэкпортили. Поэтому могут перелицензировать, ни у кого, кроме себя, не спрашивая.

Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

390. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 19:03 
> TRIM собираются спереть из ZFSoL, ибо припёрло.

Неужели маркетинговый буллшит прокатывать перестал? Какая досада! Зато мы скоро сможем лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее резко нахваливать на все лады :)

Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

391. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 19:06 
>> TRIM собираются спереть из ZFSoL, ибо припёрло.
> Неужели маркетинговый буллшит прокатывать перестал? Какая досада! Зато мы скоро сможем
> лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее
> резко нахваливать на все лады :)

TRIM практически увеличит скорость записи на флэш. Зачем отказываться от такой фичи?!


Ответить | Правка | ^ к родителю #390 | Наверх | Cообщить модератору

445. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 19:20 
>> лицезреть как эти лицемерные клоуны вопившие насчет "ненyжной" фичи начнут ее
>> резко нахваливать на все лады :)
> TRIM практически увеличит скорость записи на флэш. Зачем отказываться от такой фичи?!

Ну, что я говорил? Приятно чувствовать себя провидцем :)


Ответить | Правка | ^ к родителю #391 | Наверх | Cообщить модератору

465. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 01-Окт-12, 15:16 
> TRIM собираются спереть из ZFSoL, ибо припёрло.

ZFSLoL :) //fixed

Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

86. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 16:11 
>> 1. вначале люстру санки насильно прогнули под zfs и не доделали. теперь в этих недоделках оракл конечно виноват.
> Не "не доделали", а "не успели доделать до поглощения Ораклом".

могу ещё раз повторить, если вы не поняли - есть мнение, что таки доделали.
но результат (как и ожидалось в общем-то. по техническим причинам) оказался хуже, чем оригинал.
>"Там" -- это где? В Lustre? Или в ldiskfs?
>Если в Lustre, то там никаких архитектурных ограничений нет...

мы тут всё ещё про zfs говорим? или уже нет? :D
или как обычно - и не zfs, и не целиком, и не в люстре.
>Я что-то не пойму, вы с каким утверждением пытаетесь полемизировать?

ваше высказывание - "Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS."?
не? где практика то?
или тут - "В BtrFS ничего подобного нет, и, насколько я понимаю, в обозримом будущем не предвидится."? тоже не?
>> в топ500 нет люстры+zfs. и есть подозрения (переходящие в уверенность) что и не будет
>Это у вас откуда такая уверенность, что нет?
>Лично я высказывал _подозрения_, что есть -- соотнося разработчика Lustre/ZFS и владельца Sequoia. Вы лично в LLNL звонили, что ли?

вы высказывали УТВЕРЖДЕНИЯ.
обосновывая их _подозрения_ми_.
оригинально.
похоже на серьёзную маркетинговую школу.
вот только целевой аудиторией вы ошиблись.

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

94. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:14 
> могу ещё раз повторить, если вы не поняли - есть мнение, что таки доделали.
> но результат (как и ожидалось в общем-то. по техническим причинам) оказался хуже,
> чем оригинал.

Слуште, я спрашивал у ZFS'ников уже после поглощения Sun'а Oracle'ом на последних Sun Tech Days, как дела с использованием DMU в Lustre. Мне совершенно чётко было отвечено: в 1.8 НЕ будет, потому что есть проблемы с выносом подсчёта контрольных сумм ZFS на сторону клиента -- ZFS всё, что можно, чексуммирует -- и связка Lustre+ZFS DMU делает это не на стороне DMU, а на стороне клиента -- чтобы ещё и сетку чексуммить.

А вы откуда взяли свои домыслы?

> мы тут всё ещё про zfs говорим? или уже нет? :D

Нет, и не начинали. Мы говорим про использование ZFS DMU в Lustre под Linux.

> ваше высказывание - "Впрочем, "на практике для больших" оно тоже лучше, чем BtrFS."?
> не? где практика то?

Хм. LLNL -- не "большие"? Они пишут код поддержки ZFS DMU для Lustre в теории, не на практике? Чего ж они хвалёный BtrFS не заюзали?-)

> вы высказывали УТВЕРЖДЕНИЯ.

"Это иллюзии". А вы таки в LLNL звонили, или нет? А то вы с такой уверенностью утверждаете, что Секвойя что-то там не использует... ;)

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

99. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от ананим on 21-Сен-12, 01:50 
>Слуште, я спрашивал у ZFS'ников уже после...

а я пробовал.
..
и участвовал.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

8. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –3 +/
Сообщение от nagual email(ok) on 19-Сен-12, 14:09 
ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось. Вероятно бэтээр уже труп ... Многие кто был в нем заинтерисован посмотрели в сторону ZFS.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +10 +/
Сообщение от Одмин on 19-Сен-12, 15:01 
> бэтээру такое финансирование и не снилось.

действительно, откуда у оракл деньги

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Crazy Alex (ok) on 19-Сен-12, 15:03 
Вот только btrfs  в ядре, так что user base  у него будет всяко много больше => больше баг-репортов и людей, к нему привычных.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

22. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от Vadim email(??) on 19-Сен-12, 15:33 
> Вот только btrfs  в ядре, так что user base  у
> него будет всяко много больше => больше баг-репортов и людей, к
> нему привычных.

Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой.


Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

27. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от Аноним (??) on 19-Сен-12, 15:56 
> Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой.

Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее даже систему можно ставить :)

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

33. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от Elhana (ok) on 19-Сен-12, 16:55 
> Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее
> даже систему можно ставить :)

На zfs тоже можно систему ставить.
А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

37. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +2 +/
Сообщение от Аноним (??) on 19-Сен-12, 17:15 
> На zfs тоже можно систему ставить.

Вот так прям взять и выбрать в инсталляторе?

> А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств.

Сказано же: допилят лет через пять.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

103. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 03:15 
> Сказано же: допилят лет через пять.

Оракель и суся ее недавно в продакшновые ынтырпрайзные дистры засунули и объявили официальную поддержку. Другое дело что до кернеля 3.5 примерно его лучше не юзать - багов много. Но вообще оно уже работает, если не очень сильно извращаться.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

114. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:07 
>> Сказано же: допилят лет через пять.
> Оракель и суся ее недавно в продакшновые ынтырпрайзные дистры засунули и объявили
> официальную поддержку. Другое дело что до кернеля 3.5 примерно его лучше
> не юзать - багов много. Но вообще оно уже работает, если
> не очень сильно извращаться.

Там был один баг не закрытый всего и связанный с большой нагрузкой ...

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

183. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:40 
> Там был один баг не закрытый всего и связанный с большой нагрузкой

Опять этот Ыксперт и его сферические кони в вакууме.


Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

535. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 03-Авг-17, 20:02 
>> А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств.
> Сказано же: допилят лет через пять.

Не допилили - хотят выбросить: https://www.opennet.ru/opennews/art.shtml?num=46955


Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

56. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 19-Сен-12, 21:12 
>На zfs тоже можно систему ставить.

можно. но сложно.
и сконвертировать имеющийся ext2/3/4 нельзя, как в бтрфс.
>А btrfs у меня пол года назад падала с грохотом через 15 минут моих издевательств.

не верю.
год как на руте живёт (генту, куча сменившихся ядер и тд) - всё ок.
с другой стороны историй с падающими zfs в тырнете тоже не мало.
так что случаев не более, чем с любой другой фс.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

50. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –2 +/
Сообщение от nagual email(ok) on 19-Сен-12, 18:00 
>> Начиная с zfs-linux 0.0.6-rc10 модуль для ядра ставится при помощи dkms одной командой.
> Полная фигня, по сравнению с btrfs, которая идет из коробки. На нее
> даже систему можно ставить :)

Можно  ... но ненужно :-) потому как без гига оперы под кеш оно так же прекрасно как и ZFS :-)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

68. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 20-Сен-12, 10:36 
> Можно  ... но ненужно :-) потому как без гига оперы под
> кеш оно так же прекрасно как и ZFS :-)

Вот только у ZFS кеш "плюсом" к системному, а BTRFS нормально юзает системный кеш. Разница "на лице".

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

70. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 20-Сен-12, 11:08 
>> Можно  ... но ненужно :-) потому как без гига оперы под
>> кеш оно так же прекрасно как и ZFS :-)
> Вот только у ZFS кеш "плюсом" к системному, а BTRFS нормально юзает
> системный кеш. Разница "на лице".

Эксперименты показывают отсутствие разницы :-)) ...ох уж этот маркетинг.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

74. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 20-Сен-12, 13:02 
> Эксперименты показывают отсутствие разницы :-)) ...ох уж этот маркетинг.

Эксперименты где? На локалхосте?

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

184. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:41 
> Эксперименты где? На локалхосте?

Я думаю что он вообще не экспериментировал. Иначе он бы не втирал булшит про 1-2 гига памяти, актуальный только для ZFS с его отдельным кешом.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

199. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 23-Сен-12, 17:15 
>> Эксперименты где? На локалхосте?
> Я думаю что он вообще не экспериментировал.

Сразу видно кто пробовал а кто книжки пишет :-)))


Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

228. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 20:27 
> Сразу видно кто пробовал а кто книжки пишет :-)))

Я то btrfs гоняю на регулярной основе. Просто потому что он мне нужен и я заинтересован в этом результате. А вот вы судя по тому какой маразм втираете видели его сугубо на картинке. Иначе не понятно откуда бред про 2 гига оперативки достали.

Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

76. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 13:47 
один раз вы уже вбрасывали эту дезу - https://www.opennet.ru/openforum/vsluhforumID3/85027.html?n=n... .
теперь вот опять.
так вот - БРЕХНЯ.
Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

80. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –2 +/
Сообщение от nagual email(ok) on 20-Сен-12, 14:04 
> один раз вы уже вбрасывали эту дезу - https://www.opennet.ru/openforum/vsluhforumID3/85027.html?n=n...
> .
> теперь вот опять.
> так вот - БРЕХНЯ.
> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.

У правильных экспериментаторов бульдозер проигрывает core i5 ... хотя в некоторых тестах core i5 волшебным образом становится core i7 раскаченным за 5ГГц ...

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

81. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от ананим on 20-Сен-12, 14:32 
понятно.
вопросов больше не имею.
Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

97. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от Andrew Kolchoogin on 21-Сен-12, 01:31 
> теперь вот опять.
> так вот - БРЕХНЯ.
> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.

Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку.

И вообще, что значит "гораздо менее требовательна к ресурсам" применительно к файловой системе?

Нормальная файловая система должна стараться использовать _все_ доступные ресурсы ОЗУ и микропроцессора -- Disk I/O -- bottleneck _всегда_, если у вас не СХД на InfiniBand'е, так что извините, но это не ZFS требует много ресурсов -- это все остальные FS не умеют их использовать, не подменяйте понятия.

Далее по курсу: в ZFS существуют архитектурные ограничения, свойственные _всем_ аналогично устроенным хранилищам. Заполненный zpool на 95-97% тормозит _жутко_ -- но так же будет тормозить, к примеру, Squid, если его раздел с кэшем заполнен на эти самые ~95-97%. Это особенность _всех_ COW-стораджей, она не лечится, это бага^Wхорошо задокументированная фича.

И последнее: дефолтные настройки ZFS сделаны под некий "средний по больнице" workload: скажем, если у вас специфичный workload, требующий одномоментной аллокации здоровых кусков ОЗУ, ZFS с дефолтными настройками будет работать плохо. Гайка, закручивающая размер ARC, описана в ZFS Evil Tuning Guide, там же описаны corner cases, когда этот тюнинг надо делать.

Читайте доки -- они рулез, как известно...

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

100. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 21-Сен-12, 01:56 
>> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.
>Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку.

методику? :D
извольте - есть у меня вайфай-роутер, нетгир wndr3700.
а тут вдруг я сенд/ресив попробовал. уже почти все винты. на нетгире (последняя опенврт).
во-о-от.
есть винт по усб, на бтр. раздаётся с него на 2.5-3. по самбе.
вот так то.
лучше нтфс.
а zfs в опе.

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

514. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 02-Окт-12, 21:22 
>> Эксперименты показывают, что бтр гораздо менее требовательна к ресурсам.
> Чьи? Ваши? Опишите методику. Не ваши? Дайте ссылку.

Я по приколу запускал на железке с 64Мб рам на все про все. Без свопа. Даже довольно сносно работает. EXT4 конечно лучше, но...

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

104. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 03:20 
> кеш оно так же прекрасно как и ZFS :-)

Лучше, ибо экстентные аллокаторы - не такие слоупоки как блочные. Плюс дефрагер встроенный есть, что для CoW ФС актуально. Так что вон фороникс только на днях бенчей сделал, забенчив на свежем ядре EXT4, XFS и BTRFS. В целом получилось довольно забавно: никто не победил. В целом EXT4 немного порезвее, но в целом - на одних тестах получше ext4, на других XFS, на третьих btrfs, при том в большинстве тестов разница не особо велика. В общем то вся троица показала весьма приличный результат, а то что у них разные сильные и слабые стороны - вполне ожидаемо в силу ряда отличий в устройстве ФС, так что одним удобнее одни типы нагрузок, а другим - другие.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

54. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от BratSinot on 19-Сен-12, 19:00 
> с btrfs, которая идет из коробки

И ничего, что этот модуль тоже собирать надо?

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

57. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 19-Сен-12, 21:14 
ничего.
поддержка бтр "из коробки" уже почти во всех ядрах современных дистров.
и, что не маловажно, почти любых ливсиди.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

105. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 03:21 
> И ничего, что этот модуль тоже собирать надо?

Самому его надо собирать только если вы гентушник. В бинарных дистрах он как правило по дефолту собран вместе с остальными модулями ФС. Что да, крупный плюс. Можно с места в карьер поюзать.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

53. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Crazy Alex (ok) on 19-Сен-12, 18:36 
Это если исходник есть в репозиториях... И где оно будет? В дебиане и редхете - не будет точно. В убунте - тоже вряд ли. То есть как минимум надо тащить для этого дополнительную репу. Что явно снизит количество желающих попробовать - одно дело тупо при инсталляции для пары разделов btrfs выбрать по принципу "а дай поиграюсь", другое - целенаправленно что-то ставить.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

58. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 19-Сен-12, 21:16 
ну, с бтр можно начать играться и уже на готовой системе - сконвертнул из ext4 и всё.
не понравилось, вернул ext4 обратно.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

106. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 03:22 
> не понравилось, вернул ext4 обратно.

Кстати да, гибкость BTRFS в плане размещения данных и метаданных - доставляет. Для нее EXT4 завраппленый в нее - это вот такой вот "типа, снапшот". Просто потому что это можно офрмить как снапшот. Здорово придумано, кстати :)

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

15. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +2 +/
Сообщение от Аноним (??) on 19-Сен-12, 15:14 
> Многие кто был в нем заинтерисован посмотрели в сторону ZFS.

Ага, два раза :)
Особенно оракл, который создал btrfs с учетом ошибок, сделанных в архитектуре ZFS.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

20. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Vadim email(??) on 19-Сен-12, 15:30 
Неделю назад в рассылке zfs-discuss как раз была ссылка на позицию Oracle по портированию на linux:

Regarding Oracle's position on ZFS (and other  technologies  inherited from Sun), here's an interesting  article: http://www.serverwatch.com/server-trends/oracle-pushing-forw...

Regarding ZFS specifically, here's what  Wim Coekearts, a "Senior VP"  at Oracle, has declared:
      "According to Coekaerts, porting ZFS to Linux involves a non-optimal approach that is not native. As such, there is likely not a need to attempt to bring ZFS to Linux since Btrfs is now around to fit the bill. "

As long as Oracle doen't try to interfere and stop others like the ZFSOnLinux folks from doing so, I for one am happy enough with Oracle's decision to get out of the way in regards to porting ZFS to Linux.  

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

47. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 19-Сен-12, 17:54 
>> Многие кто был в нем заинтерисован посмотрели в сторону ZFS.
> Ага, два раза :)
> Особенно оракл, который создал btrfs с учетом ошибок, сделанных в архитектуре ZFS.

Но коник не взлетел ... и не взлетит потому как рядом рухнул купленный коник MySQL и все это возле мучительно умирающиго коника солярки ... Может что то с кормом не то ? :-)))

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

55. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от filosofem (ok) on 19-Сен-12, 19:06 
>Может что то с кормом не то ? :-)))

Да, комбикорма приготовили из полуразложившегося трупа ZFS.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

62. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 20-Сен-12, 10:10 
> Но коник не взлетел ... и не взлетит

О, пипец доморощенные аналитики. А чуваки из майнлайн ядра пилят его толпой и не знают что какой-то там nagual уже оказывается btrfs'а давно закoпал.

Поскольку вы генерируете только трындеж на форуме, а те парни генерируют код который у меня работает - им я буду верить несколько больше, извините.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

63. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 20-Сен-12, 10:12 
> купленный коник MySQL

То-то все хостинги по сей день юзают оный. А если оракл будет слишком выпендриваться, есть MariaDB совместимая с ним но от других граждан, так что удачи ораклу в попытках обнаглеть. Как максимум получат повтор истории с либрофисом :)

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

66. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 20-Сен-12, 10:29 
>> купленный коник MySQL
> То-то все хостинги по сей день юзают оный. А если оракл будет
> слишком выпендриваться, есть MariaDB совместимая с ним но от других граждан,
> так что удачи ораклу в попытках обнаглеть. Как максимум получат повтор
> истории с либрофисом :)

Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день ... все таки много лет делалось но купили имеено с этой целью. Все более людей уходит с мусуля на его клоны. Кстати о btrfs и ZFS как только они стали хотябы теоритически составлять конкуренцию хардварным решениям ОРАкля их тут же купило, нет не чтобы похерить. Ога.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

67. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 20-Сен-12, 10:35 
C чего бы? Мы наоборот вернулись с MariaDB на MySQL, потому, что в 5.5 много вкусного, а у MariaDB как-то с форком долго было глухо.
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

107. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 04:19 
> Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день
> ... все таки много лет делалось но купили имеено с этой целью.

Наврядли. Ну не конкурент мускуль их базе, просто потому что мускуль - просто гольная скульная база. А оракель - нев....й фреймворк для разработки бизнес хрени. Прогулочная яхта не такой уж и страшный конкурент круизному лайнеру.

> Все более людей уходит с мусуля на его клоны.

Просто потому что оракл не умеет рулить открытыми проектами, только и всего.

> Кстати о btrfs и ZFS как только они стали хотябы теоритически составлять
> конкуренцию хардварным решениям ОРАкля их тут же купило, нет не чтобы
> похерить. Ога.

Оракль вообще не особо занимается оборудованием. С санями они получили это направление, но судя по всему - просрyт все полимеры. Сани они купили в основном потому что ява и клиентская база. Btrfs им нужен как подложка для их БД. Вполне способная работать так как им надо и позволяющая админить все-таки файлы в ФС а не черти-что в RAW разделах, что админам удобнее.

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

115. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:12 
>> Месье застрял в криокамере? Безусловно ОРАкля не сломает мускуль за один день
>> ... все таки много лет делалось но купили имеено с этой целью.
> Наврядли. Ну не конкурент мускуль их базе, просто потому что мускуль -
> просто гольная скульная база. А оракель - нев....й фреймворк для разработки
> бизнес хрени. Прогулочная яхта не такой уж и страшный конкурент круизному
> лайнеру.

Вот кластер рампочты на мускуле если верить слонику а мог бы быть на оракле ...
И таких потенциальных клиентов множество.


Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

120. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 12:29 
> Вот кластер рампочты на мускуле если верить слонику а мог бы быть на оракле ...

Прогулочную яхту арендовать несколько дешевле чем круизный лайнер, знаете ли. Поэтому когда хватает мелкой яхты - очень мало кто побежит арендовать целый лайнер.

> И таких потенциальных клиентов множество.

Мало кто будет арендовать трансокеанский лайнер для вечеринки. Тем более что готовых предоставить свои яхты стоит целая толпа. В свете чего профит с потуги пересадить всех с мелких яхт на огромные лайнеры выглядит неубедительно. Будут жить и те и другие - разная весовая категория.

Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

123. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 12:35 
> Прогулочную яхту арендовать несколько дешевле чем круизный лайнер, знаете ли. Поэтому когда
> хватает мелкой яхты - очень мало кто побежит арендовать целый лайнер.

Х...се 1к серверов в кластере :))) что то с круизным лайнером не то если 1к яхт лучше :)))

> Мало кто будет арендовать трансокеанский лайнер для вечеринки. Тем более что готовых
> предоставить свои яхты стоит целая толпа. В свете чего профит с
> потуги пересадить всех с мелких яхт на огромные лайнеры выглядит неубедительно.
> Будут жить и те и другие - разная весовая категория.

Там проект уже прибит к мускулю гвоздями с клеем и так просто без изменения структуры проекта на оракл не переделать, а переделывать стоит кучу денег и в условиях кризиса одержимых безумнными идеями все переделать гонят ссаными тряпками. Вобщем оракл там нужен как в бане лыжи и только менагеры оракла могут не понимать это ...

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

185. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:46 
> Х...се 1к серверов в кластере :))) что то с круизным лайнером не то если 1к яхт лучше :)))

1К яхт обойдутся дешевле чем 1К круизных лайнеров ;)

> Там проект уже прибит к мускулю гвоздями с клеем и так просто
> без изменения структуры проекта на оракл не переделать,

Тем более. Переделывать чтобы попасть на жесткий вендор лок-ин и заплатить бабла чуть ли не больше чем стоят сервера? Ну да, за кадром слышен конский топот сферических коней в вакууме. Побежавших переписывать все и вся под оракл. Ради... ради чего?

Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

188. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от анон on 23-Сен-12, 12:52 
> Вот кластер рампочты на мускуле если верить слонику

Много раз читаю про кластер рампочты и не понимаю, кто этот кластер нагружает. В последний раз почта, заканчивающаяся на @rambler.ru, встречалась мне лет... уфф, лет семь или восемь назад

Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

161. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от iZEN (ok) on 23-Сен-12, 11:22 
> Btrfs им нужен
> как подложка для их БД. Вполне способная работать так как им
> надо и позволяющая админить все-таки файлы в ФС а не черти-что
> в RAW разделах, что админам удобнее.

Btrfs в конфигурации для Oracle DB не поддерживается официально.


Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

186. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 12:46 
> Btrfs в конфигурации для Oracle DB не поддерживается официально.

А *bsd и тем более ZFS на оной и тем более с оракловой базой - вообще никак не поддерживается.

Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

189. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 12:53 
>> Btrfs в конфигурации для Oracle DB не поддерживается официально.
> А *bsd и тем более ZFS на оной и тем более с
> оракловой базой - вообще никак не поддерживается.

Так свободные системы для свободных людей, разве нет? Какая же в Linux свобода, если в нём заправляют корпорации и диктуют условия использования недоделанных продуктов (Btrfs пока не сертифицирована для использования с СУБД)?


Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

232. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 20:31 
> Так свободные системы для свободных людей, разве нет?

Так я и не утверждал что мне нравится проприерасия от оракла и что я горю желанием в нее влопаться. Просто вы полезли меряться и получили резонное сравнение. Кстати свободные люди тоже бсды не особо серьезно воспринимают нынче. Вон интель недавно тут высказался о том что проблемы бсдшных слоупоков - не их проблемы, их это не интересует и они не собираются по этому поводу тормозить развитие линуксного кода.

> Какая же в Linux свобода, если в нём заправляют корпорации

Они если что и заправляют там то только бензобак. А с пустым бензобаком далеко не уедешь.

> и диктуют условия использования недоделанных продуктов (Btrfs пока
> не сертифицирована для использования с СУБД)?

Охренеть, производитель СУБД диктует ее системные требования и перечисляет проверенные и заведомо рабочие конфигурации. Шок! Сенсация! Караул! Грабеж!

Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

61. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 20-Сен-12, 10:00 
> ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось.

А бтр пилят разработчики майнлайнового ядра. Не знаю считается ли это за финансирование, но пилят его довольно интенсивно и в майнлайне. А не где-то сбоку под левой лицензией. За чем будущее - несложно догадаться. Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с невнятными перспективами всего этого начинания.

...просто потому что BTRFS сможет то что и ZFS. И даже больше. И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы - вопрос интересный. И что случится с этой кодовой базой - тоже интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от этого начинания и выбросят его на свалку - тогда чего? Как с опенсолярой и ораклем, да? :)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

64. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –3 +/
Сообщение от nagual email(ok) on 20-Сен-12, 10:23 
>> ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось.
> А бтр пилят разработчики майнлайнового ядра. Не знаю считается ли это за
> финансирование, но пилят его довольно интенсивно и в майнлайне. А не
> где-то сбоку под левой лицензией. За чем будущее - несложно догадаться.

Еще одна FS в коллекцию недофс линукса ...

> Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с
> невнятными перспективами всего этого начинания.

Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно становится маргинальной хренотенью ...


> ...просто потому что BTRFS сможет то что и ZFS. И даже больше.
> И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы -
> вопрос интересный. И что случится с этой кодовой базой - тоже
> интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от
> этого начинания и выбросят его на свалку - тогда чего? Как
> с опенсолярой и ораклем, да? :)

Ну не летают кони у Оракла ... корма не те :-)))


Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

108. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 05:59 
> Еще одна FS в коллекцию недофс линукса ...

Ну да, и только вы на белом коне. Сферическом. В вакууме. А ничего что у всяких соляр и бздей на выбор полторы ФС, при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы, но там тоже ничего интересного. Совсем античный FAT да тормозной и старинный NTFS. Ну и все. Еще есть UDF (правда толку то с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых. Ну в общем покажите ФС которые не "недо" по вашему мнению тогда.

> Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно
> становится маргинальной хренотенью ...

Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация BTRFS? То что она нужна толпе народа, в том числе и для всевозможных дел приносящих бабки - так это нормально вполне. Не верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как вам оно. Тогда глядишь и других за зарабатывание денег само по себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие методы, а есть не очень.

>> этого начинания и выбросят его на свалку - тогда чего? Как
>> с опенсолярой и ораклем, да? :)
> Ну не летают кони у Оракла ... корма не те :-)))

Да, сферические кони в вакууме - это прерогатива адептов *BSD :)

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

116. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:16 
> Ну да, и только вы на белом коне. Сферическом. В вакууме. А
> ничего что у всяких соляр и бздей на выбор полторы ФС,
> при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая -
> ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы,
> но там тоже ничего интересного. Совсем античный FAT да тормозной и
> старинный NTFS. Ну и все. Еще есть UDF (правда толку то
> с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых.
> Ну в общем покажите ФС которые не "недо" по вашему мнению
> тогда.

Судя по этом бреду месье не часто инсталит ОС ...


> Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация
> BTRFS? То что она нужна толпе народа, в том числе и
> для всевозможных дел приносящих бабки - так это нормально вполне. Не
> верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как
> вам оно. Тогда глядишь и других за зарабатывание денег само по
> себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие
> методы, а есть не очень.

Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз планирует загубить бтр.

> Да, сферические кони в вакууме - это прерогатива адептов *BSD :)

У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати.


Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

119. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 12:17 
>> Ну в общем покажите ФС которые не "недо" по вашему мнению тогда.
> Судя по этом бреду месье не часто инсталит ОС ...

Иногда - инсталлит. Но не слишком часто, ибо не является эникейщиком протирающим мышки.

> Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз
> планирует загубить бтр.

Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как в подстилке для своих БД.

>> Да, сферические кони в вакууме - это прерогатива адептов *BSD :)
> У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати.

Ваши данные протухли. Не, если сравнивать только с архаичным UFS и тормозным ZFS - вы даже может быть и правы. А если вспомнить о "недо-ФС" Linux и взять например, XFS то на больших файлах он обставит NTFS как делать нефиг. К тому же он намного меньше фрагментируется, там с фрагментацией борятся очень здорово. А если еще и более чем 1 диск в хранилище, XFS просто эпически рвет всех. Просто потому что ориентирован на параллельный доступ с его группами аллокации и поэтому почти всегда юзает диски параллельно, независимо от того как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских битовых карт на каждый пшик. Стоит ли говорить что работает сие не в пример шустрее в ряде случаев? Вообще, очень позитивная и резвая ФС вышла. По сути это лучшее что можно выжать из заюзанных технологий. А btrfs мало того что не особо то и тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12... - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей) так еще и фич предлагает много.

Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о том как там все плохо, я с удовольствием послушаю о том как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается еще и кормят плохо.

Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

121. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 12:30 
> Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это
> выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как
> в подстилке для своих БД.

Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент.

>[оверквотинг удален]
> как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать
> не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от
> древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских
> битовых карт на каждый пшик. Стоит ли говорить что работает сие
> не в пример шустрее в ряде случаев? Вообще, очень позитивная и
> резвая ФС вышла. По сути это лучшее что можно выжать из
> заюзанных технологий. А btrfs мало того что не особо то и
> тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12...
> - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей)
> так еще и фич предлагает много.

Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет выше чем с любой фс, не ? Месье неисилил школьный курс физики? И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь.

> Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о
> том как там все плохо, я с удовольствием послушаю о том
> как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается
> еще и кормят плохо.

Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки не ставьте свой линукс на btrfs и вы сэкономите время на переустановку.


Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

124. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 12:55 
> Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла

У оракла есть друзья? А я то думал что при капитализме человек человеку - волк и конкурент. И если можно набить карман лишний раз - это следует сделать. А тут прямо какие-то новые открытия.

> производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент.

Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше у них баз купят, тем лучше. И чем проще, быстрее и дешвле все остальное и чем проще оно админится и лучше работает - тем по идее выше спрос на БД. Так что в принципе btrfs вполне хорошо вписывается в их желание продавать их БД. Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто хотел аппаратный RAID - пойдет да купит его. А btrfs - просто полезняшка для админов этакая.

> Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет
> выше чем с любой фс, не ?

Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит идеально непрерывно, одним фрагментом - практически любая ФС будет читать со скоростью примерно равной RAW доступу к диску. Стормозить при этом - это еще суметь надо. Не на чем тормозить :). Так что я ставлю на то что большинство ФС в этом случае дружно покажут результат крайне близкий к физическим пределам накопителя при чтении этих блоков просто так, не в рамках разбора ФС. Алсо, бывает такая вещь как SSD. Там важнее сколько операций делает ФС и какой от этого оверхед. Потому что seek time накопителя близок к нулю, скорости выше, так что начинает сильно влиять то сколько лишних операций проделает ФС. И bitmap-based ФС в этом плане опять оказываются в полной опе. Потому что педалить большие битовые карты - не очень то и быстро.

Основная проблема с указанным случаем - это сферический случай в вакууме, который почти никогда не случается в реальности и потому малоинтересен на практике.

> Месье неисилил школьный курс физики?

Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня физике, особенно как раз разделам механики и электричества. Удачи в этом начинании :). Вот только я то как раз обычно достаточно отчетливо представляю себе во что именно физически и логически трансформируется то или иное  действо в цифровых девайсах.

> И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь.

А железные решения ничего такого фантастического не делают. Кроме того у них есть недостаток: они оперируют проприетарным форматом метаданных, так что если не дай боже железка вылетела а запасной такой же у вас нет - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно.

Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно. Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей планет. Ы? :)

> Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе
> btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки
> не ставьте свой линукс на btrfs и вы сэкономите время на переустановку.

Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет, в отличие от. Это у саней полностью отдельный кэш, живущий отдельно от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и BTRFS нет ни одной из этих проблем.

Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

125. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 13:12 
> У оракла есть друзья? А я то думал что при капитализме человек
> человеку - волк и конкурент. И если можно набить карман лишний
> раз - это следует сделать. А тут прямо какие-то новые открытия.

Что то не везет вам в думании ...

> Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше
> у них баз купят, тем лучше.

Неужели после всего вышенаписанного для месье открытие что весь капитализм как явление природы принадлежит узкой группе сильно ограничсенных людей? Месье так и не заметил в силу своей природной незамечательности что иногда интересы очень разных корпараций вдруг удивительно сочетаются?

> И чем проще, быстрее и
> дешвле все остальное и чем проще оно админится и лучше работает
> - тем по идее выше спрос на БД. Так что в
> принципе btrfs вполне хорошо вписывается в их желание продавать их БД.
> Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх
> которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто
> хотел аппаратный RAID - пойдет да купит его. А btrfs -
> просто полезняшка для админов этакая.

Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ...

> Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит
> идеально непрерывно, одним фрагментом - практически любая ФС ...

Дальше можно не читать. Странно что при всей своей эрудиции месье не понимает что файл идеально непрерывно может лежать только после дефрагментации и только в ntfs или fat :))) а для других фс даже дефрагментаторов нет :)))

> Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня
> физике, особенно как раз разделам механики и электричества. Удачи в этом
> начинании :). Вот только я то как раз обычно достаточно отчетливо
> представляю себе во что именно физически и логически трансформируется то или
> иное  действо в цифровых девайсах.

Неужели месье асилил Левашева ?

> А железные решения ничего такого фантастического не делают. Кроме того у них
> есть недостаток: они оперируют проприетарным форматом метаданных, так что если не
> дай боже железка вылетела а запасной такой же у вас нет
> - вы вообще остаетесь без доступа к данным. Резко, больно и
> внезапно.

Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров сразу идут лесом.

> Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно.
> Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей
> планет. Ы? :)

К чему это ... наверно обострение.

> Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет,
> в отличие от. Это у саней полностью отдельный кэш, живущий отдельно
> от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким
> количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и
> BTRFS нет ни одной из этих проблем.

Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц Ну если хотите в этом сами убедиться - попробуйте.

Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

129. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 22-Сен-12, 07:06 
> Что то не везет вам в думании ...

Да ладно вам, нормально вполне. Кстати понимание работы этой механики еще не означает одобрение такого подхода и/или симпатий ко многим методам работы капиталистов.

> заметил в силу своей природной незамечательности что иногда интересы очень разных
> корпараций вдруг удивительно сочетаются?

Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А как только дружба начинает мешать выгоде - так сразу же вчерашний друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов не забывайте о том что они улыбаясь и дружа с удовольствием прокатят "ближнего своего" и пырнут в спину, если это сулит хоть какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет по головам и трупам. Природа настоящего капиталиста такова.

>> хотел аппаратный RAID - пойдет да купит его. А btrfs -
>> просто полезняшка для админов этакая.
> Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ...

Да, я додумал: вы зациклены на *bsd и ZFS. И никак не можете понять, что архитектурно btrfs мало того что не слишком похож на zfs, так еще исправляет ряд его упущений и обладает рядом настроек которые в принципе позволят ему достаточно сухо и комфортно жить на весьма разных по своей природе накопителях.

>> Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит
>> идеально непрерывно, одним фрагментом - практически любая ФС ...
> Дальше можно не читать. Странно что при всей своей эрудиции месье не
> понимает что файл идеально непрерывно может лежать только после дефрагментации

Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться добиться именно такого случая настолько насколько позволяют реалии свободного места на диске. Чем больше свободного места на диске и меньше фрагментировано свободное место, тем лучше это получается. В клиническом случае если мы резво пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно.

>  и только в ntfs или fat :)))

Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают и приветствуют. Чисто практически - уж насколько получится. И даже мелкие неидеальности типа seek в сторону 1 раз на 100Мб мало чего меняют. Ну будет не 100% скорости а 99%, допустим. Никто и не заметит особой разницы. Фрагментация являет собой проблему когда том становится загажен и не удается выкроить непрерывный кусок.

> а для других фс даже дефрагментаторов нет :)))

Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением старого размазанного варианта, например. При этом используется свойство аллокатора пытаться разложить файл максимально линейно. Таким манером можно частично отдефрагментировать практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь бы свободного места было много, иначе аллокатору негде будет развернуть деятельность по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, если совсем опа в ФС еще не наступила. По поводу чего и не советуют тома забивать более чем на 70-90%. Иначе сильно фрагментируется свободное место и том коллапсирует. Что будет - отлично видно на примере изена, с его легендарными 6Мб/сек на шпиндель :)

Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу.

В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. А раз он всяко есть и кантует блоки - пусть заодно и дефрагит в процессе! В btrfs этот достаточно очевидный факт до разработчиков дошел и там GC совмещен с дефрагером, по поводу чего у btrfs есть встроенный дефраг. В ZFS такого не было, да. Почему? Наверное потому что это одна из первых CoW ФС.

Так что ваши сведения кривоваты и староваты. FAIL.

> Неужели месье асилил Левашева ?

Не припоминаю такой фамилии. Но мсье знает некоторые другие фамилии. Например, Ланау и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на 2 страницы и полагают что все остальные могут не хуже, поэтому просто не приводят подобные преобразования в своей книжке :). Ну а в плане электроникм мсье попалась достаточно годная книжка по основам полупроводниковой схемотехники от У. Титце и К. Шенка (в переводе на русский, они изначально немцы). Все основы изложенные там до сих пор вполне актуальны.

И да, смею заверить что грубо прикинуть как будет разложен файл, хоть немного преставляя себе логику работы ФС - я в состоянии. Как в состоянии предсказать некоторые сценарии, например то что получилось на томе у какого-нибудь изена :). Я даже не видя того что у него на томе могу примерно представить себе как сие выглядит, если отрисовать занятость тома. ИЧСХ, оно как-то так обычно и оказывается.

>> - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно.
> Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот
> потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров
> сразу идут лесом.

Собственно, одна из причин по которым не все юзают аппаратные рэйды. А также ФС с управлением томами самолично имеет больше шансов разложить данные по дискам более удачно если природа хранилища не скрыта от нее железкой.

А так - оракл может чисто номинально дружить с кем угодно. Но в конечном итоге они базы продают. Рэйды им могут быть интересны, если это помогает базы продавать. Но в целом им перпендикулярно, существуют рэйды или нет. Это вообще кастомеровские проблемы и проблемы сторонних контор. А их интересуют продажи баз. Продастся ли при этом аппаратный рэйд - уж точно не проблема оракла. Поэтому называя вещи своими именами, ораклу более-менее все-равно. Тем более что если некое хранилище работает, то btrfs поверх него ничему не противоречит. Тем более что в btrfs настраивается как именно хранить данные и метаданные. Например если кто уверен что хранилище офигеть какое надежное - он может выключить зеркалирование метаданных, например. Скорость возрастет. А надежность... ну если хранилище надежное - сами знали на что шли.

> К чему это ... наверно обострение.

Да, обострение чувства голода. Кушать хочется после того как втирают всякое ламерство про фрагментацию :)

> Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц
> Ну если хотите в этом сами убедиться - попробуйте.

Это вы про ZFS. Не надо переносить его свойства на btrfs. Я его ради лулзов запускал на железке с 64Мб и хилым процом. Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации и меньше нагружал проц, что для мелкой железки актуально. А на типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать вполне по королевски. Оно в целом помедленнее ext4 (который вышел на удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на недавние бенчи привел.

Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

131. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 22-Сен-12, 10:12 
> Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А
> как только дружба начинает мешать выгоде - так сразу же вчерашний
> друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это
> просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов
> не забывайте о том что они улыбаясь и дружа с удовольствием
> прокатят "ближнего своего" и пырнут в спину, если это сулит хоть
> какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет
> по головам и трупам. Природа настоящего капиталиста такова.

Нет никакой необходимости записывать свои открытия в форуме.

> Да, я додумал: вы зациклены на *bsd и ZFS. И никак не
> можете понять, что архитектурно btrfs мало того что не слишком похож
> на zfs, так еще исправляет ряд его упущений и обладает рядом
> настроек которые в принципе позволят ему достаточно сухо и комфортно жить
> на весьма разных по своей природе накопителях.

Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно.

> Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи
> файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться
> добиться именно такого случая настолько насколько позволяют реалии свободного места на
> диске. Чем больше свободного места на диске и меньше фрагментировано свободное
> место, тем лучше это получается. В клиническом случае если мы резво
> пишем файл на только что созданную пустую ФС, он скорее всего
> будет выложен идеально линейно.

Последняя враза явная лож :))) как минимум для половины фс.

> Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно
> на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают
> и приветствуют. Чисто практически - уж насколько получится. И даже мелкие
> неидеальности типа seek в сторону 1 раз на 100Мб мало чего
> меняют. Ну будет не 100% скорости а 99%, допустим. Никто и
> не заметит особой разницы. Фрагментация являет собой проблему когда том становится
> загажен и не удается выкроить непрерывный кусок.

Вы что то упустили в теории.


> Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением
> старого размазанного варианта, например. При этом используется свойство аллокатора пытаться
> разложить файл максимально линейно. Таким манером можно частично отдефрагментировать
> практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь
> бы свободного места было много, иначе аллокатору негде будет развернуть деятельность
> по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов,
> если совсем опа в ФС еще не наступила. По поводу чего
> и не советуют тома забивать более чем на 70-90%. Иначе сильно
> фрагментируется свободное место и том коллапсирует. Что будет - отлично видно
> на примере изена, с его легендарными 6Мб/сек на шпиндель :)

Месье может назвать хоть одну фс в линуксе которая попадает под его критерий- практически любую "классическую" ?


> Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными
> утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно
> есть сразу.

Есть но до виндозного ему еще очень далеко :))

> В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий
> устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа.
> А раз он всяко есть и кантует блоки - пусть заодно
> и дефрагит в процессе! В btrfs этот достаточно очевидный факт до
> разработчиков дошел и там GC совмещен с дефрагером, по поводу чего
> у btrfs есть встроенный дефраг. В ZFS такого не было, да.
> Почему? Наверное потому что это одна из первых CoW ФС.

Палундра в ZFS нет дефрагментатора %)

> Не припоминаю такой фамилии.

Я почему то не ожидал другова ответа :-))

>Но мсье знает некоторые другие фамилии. Например, Ланау
> и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на
> 2 страницы и полагают что все остальные могут не хуже, поэтому
> просто не приводят подобные преобразования в своей книжке :).

И какая практическая польза от этой ментальной маструбации ?


> Это вы про ZFS. Не надо переносить его свойства на btrfs. Я
> его ради лулзов запускал на железке с 64Мб и хилым процом.
> Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации
> и меньше нагружал проц, что для мелкой железки актуально. А на
> типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать
> вполне по королевски. Оно в целом помедленнее ext4 (который вышел на
> удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на
> недавние бенчи привел.

Оно себя будет чуствовать по королевски пока вы не запустите лису или что там у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш.

С счастью большинство читателей не станут тратить время на этот бред. В целом это называется калейдоскапический идиотизм. Диагноз гуглится.

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

142. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 09:47 
> Оно себя будет чуствовать по королевски пока вы не запустите лису или
> что там у вас на ноуте, тоесть пока 2 гига памяти
> свободны и могут использоваться под кеш.

Бугыг. Только хотел этому кексу написать "а ты текущую из всех щелей лису на что-нибудь другое менять пробовал" - как он сам сразу и спалился.

Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

200. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 17:58 
> Нет никакой необходимости записывать свои открытия в форуме.

Ну я не виноват что вы не знаете элементарных вещей, приходится разъяснять и в ротик класть. Я бы предпочел этого не делать, честно-честно.

>> настроек которые в принципе позволят ему достаточно сухо и комфортно жить
>> на весьма разных по своей природе накопителях.
> Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно.

Вообще-то это было про btrfs. А то что вы не видели - не удивительно. Вы видите только то что хотите видеть, а не то что есть на самом деле. Вы всегда пытаетесь выдать желаемое за действительное и ужасно палитесь на различных нестыковках :)

>> пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно.
> Последняя враза явная лож :)))

Хоть это и не форум русского языка, но орфографические ошибки за которые ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с мягким знаком на конце.

> как минимум для половины фс.

Почему для половины? А не четверти? Или трех восьмых? Обоснуйте. Столь фундаментальная заява должна иметь под собой простое и понятное даже кухарке обоснование.

Со своей стороны я могу себе представить как на свежесозданной ФС файл будет разложен линейно вплоть до почти полной емкости диска. Просто потому что ничего не валяется на проходе и не мешает его так раскладывать.

>> не заметит особой разницы. Фрагментация являет собой проблему когда том становится
>> загажен и не удается выкроить непрерывный кусок.
> Вы что то упустили в теории.

Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость заметно падает если диск заметный процент времени проводит делая перемещения голов нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом.

> Месье может назвать хоть одну фс в линуксе которая попадает под его
> критерий- практически любую "классическую" ?

Например, ext4 (в принципе и все ext2...ext4). JFS. До некоторой степени - XFS. У него правда есть allocation groups - он как раз не совсем линейно раскладывает файлы, нарезая их кусками. Но куски большие и по этому поводу скорость не только не проседает, но и вообще, это очень шустрая ФС. Особенно - в плане работы с большими файлами как раз. А за счет такой нарезки оно выигрывает в скорости на многодисковых хранилищах.

>> утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу.
> Есть но до виндозного ему еще очень далеко :))

Да, гламурных кнопочек нету. Какая трагедия.

>> Почему? Наверное потому что это одна из первых CoW ФС.
> Палундра в ZFS нет дефрагментатора %)

Да вон iZEN уже ощущает результат. И даже если он осовободит место, сильно лучше может и не стать. В общем то нет простого метода расчистить такое без дефрагментатора.

>> Не припоминаю такой фамилии.
> Я почему то не ожидал другова ответа :-))

Наверное потому что это достаточно специфичный субъект. В то время как меня интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не просто домыслы. По этой причине я вообще достаточно осторожно отношусь к любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно отличается от практически наблюдаемого.

>> просто не приводят подобные преобразования в своей книжке :).
> И какая практическая польза от этой ментальной маструбации ?

Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст миллионов в кармане. И даже набить брюхо не поможет. Просто у некоторых людей интересы простираются чуть дальше.

> Оно себя будет чуствовать по королевски пока вы не запустите лису или что там
> у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш.

А оно и при небольшом кеше не сдувается так как ZFS. Вы прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что с блоками переменного размера.

> С счастью большинство читателей не станут тратить время на этот бред. В
> целом это называется калейдоскапический идиотизм. Диагноз гуглится.

Да уж. Диагноз называется "BSDшник-пионер".

Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

202. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 18:28 
> ... приходится разъяснять
> и в ротик класть. Я бы предпочел этого не делать, честно-честно.

И не делайте, тем более половина неверная ...

> Вообще-то это было про btrfs. А то что вы не видели -
> не удивительно. Вы видите только то что хотите видеть, а не
> то что есть на самом деле. Вы всегда пытаетесь выдать желаемое
> за действительное и ужасно палитесь на различных нестыковках :)

Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ... Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ?

> Хоть это и не форум русского языка, но орфографические ошибки за которые
> ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с
> мягким знаком на конце.

Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь не часто ...

> Со своей стороны я могу себе представить как на свежесозданной ФС файл
> будет разложен линейно вплоть до почти полной емкости диска. Просто потому
> что ничего не валяется на проходе и не мешает его так
> раскладывать.

В UFS и ZFS это точно не так :-)))

>>> не заметит особой разницы. Фрагментация являет собой проблему когда том становится
> Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость
> заметно падает если диск заметный процент времени проводит делая перемещения голов
> нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость
> между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными
> наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом.

Все эти построения основаны на необходимости считывать данные которые могут хотябы потенциально быть записаны последовательно. Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу либо это удивительное совпадение которых в реальной жизни не бывает.

> Да, гламурных кнопочек нету. Какая трагедия.

Как насчет объединения свободного пространства ?


> Наверное потому что это достаточно специфичный субъект. В то время как меня
> интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не
> просто домыслы. По этой причине я вообще достаточно осторожно отношусь к
> любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно
> отличается от практически наблюдаемого.

Неужели вам удалось поймать нейтрино?

> Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст
> миллионов в кармане. И даже набить брюхо не поможет. Просто у
> некоторых людей интересы простираются чуть дальше.

В двух словах пользы никакой :-)))

> А оно и при небольшом кеше не сдувается так как ZFS. Вы
> прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что
> с блоками переменного размера.

Именно переменные блоки дают преимущества над железными RAID. У btrfs его нет увы, поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-)))

> Да уж. Диагноз называется "BSDшник-пионер".

Ох уж эти маркетологи.

Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

248. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 21:01 
> И не делайте, тем более половина неверная ...

Не так уж плохо по сравнению с вашими сообщениями. У вас КПД намного хуже, увы.

>> то что есть на самом деле. Вы всегда пытаетесь выдать желаемое
>> за действительное и ужасно палитесь на различных нестыковках :)
> Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ...

Не совсем понимаю при чем тут ваш sysctl. Что за перевод стрелок? Из ярких примеров - вы откуда-то взяли про 2 гига потребные btrfs. Явно путая его с ZFS или просто откровенно завирая на форуме.

> Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ?

Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким ламерюгам желания совершенно нет. Вот если вы опишете конфигурацию и что хотите получить - тогда можно будет подумать что можно покрутить. И то большинство твиков очевидны и я не вижу смысла метать бисер.

> Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь
> не часто ...

Просто если некто изъясняется на уровне папуаса, возникает ощущение что у него и интеллект в целом на уровне папуаса остался. Вон например тут рядом изен - типовой папуас рассказывающий про то как работает микроволновка: кладем еду, жмем это и это - она жужжит - получается еда. Во. При слове "магнетрон" или "волны" у папуаса случается кернелпаник :)

>> Со своей стороны я могу себе представить как на свежесозданной ФС файл
>> будет разложен линейно вплоть до почти полной емкости диска. Просто потому
>> что ничего не валяется на проходе и не мешает его так раскладывать.
> В UFS и ZFS это точно не так :-)))

На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то близкое к этому. Если это не так - ну ой, сочувствую, плохо значит там с аллокаторами дела. Я в этом не виноват. И если для CoW это еще можно понять (хотя опять же, а что мешает класть фрагменты друг за другом последовательно?) то для "классики" это вообще трындец какой-то.

>> наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом.
> Все эти построения основаны на необходимости считывать данные которые могут хотябы
> потенциально быть записаны последовательно.

Так мы вроде и говорили о идеальном случае когда 1 файл пишется на пустую ФС линейно. Большинство ФС его при этом весьма линейно и впихнет. При этом почти любая ФС покажет скорость записи и чтения сравнимую с скоростью работы диска в режиме RAW доступа без разбора ФС. Просто потому что в этой ситуации нечему тормозить.

> Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу
> либо это удивительное совпадение которых в реальной жизни не бывает.

А тут вы попались на невнимательности, поскольку это было про случай столь симпатичных вам сферических коней в вакууме - создаем файл на пустой ФС и смотрим какая скорость.

>> Да, гламурных кнопочек нету. Какая трагедия.
> Как насчет объединения свободного пространства ?

Хм, вот это не помню, может и не умеет. В принципе объединение пространства неплохая идея, но в конечном итоге это уже относительно некритичный улучшайзер. Если уж посмотреть на бсды, там и такого нет.

>> отличается от практически наблюдаемого.
> Неужели вам удалось поймать нейтрино?

Их в общем то нынче уже регулярно ловят, если что. Можно считать что на промышленной основе. Самолично не ловил, т.к. это требует слишком монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы хоть что-то поймать, вещества должно быть много. Значит, установка будет большой.

>> некоторых людей интересы простираются чуть дальше.
> В двух словах пользы никакой :-)))

Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно так же в этом плане. Так что странно что вы ими умудряетесь при этом пользоваться. Хотя судя по тому что вы так хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно не фонтан.

> Именно переменные блоки дают преимущества над железными RAID.

А обосновать столь громкую заяву? В чем преимущества, откуда получаются, чем обусловлены на уровне физики и логики процесса?

> У btrfs его нет увы,

У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) как в ZFS. Что это означает? То что при непрерывной записи больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его его как ОДНУ запись экстента. А вот ZFS при этом будет вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых. Что быстрее: пометить регион в хренадцать мегов как занятый за 1 присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно намекают.

> поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-)))

Так экстенты - то же самое по смыслу, только без тупых ограничений на максимальный размер в всего 128 кило/1 мег.

>> Да уж. Диагноз называется "BSDшник-пионер".
> Ох уж эти маркетологи.

Да уж, основательно промыли ваши мозги маркетинговым буллшитом.

Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

261. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 22:04 
> У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть
> один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум)
> как в ZFS. Что это означает? То что при непрерывной записи
> больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если
> некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его
> его как ОДНУ запись экстента. А вот ZFS при этом будет
> вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых.
> Что быстрее: пометить регион в хренадцать мегов как занятый за 1
> присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно
> намекают.

Тест от 27 июня 2012 года:

"For the 8GB IOzone write test, ZFS on the OCZ Solid 2 SSD was right in the middle between EXT4 and Btrfs while on the HDD it was tied with EXT4 for being the slowest."
http://www.phoronix.com/scan.php?page=article&item=linux_zfs...

На HDD Ext4 чуточку слила LLNL ZFS v0.6.0-rc9. Так что вы там про экстенты говорили и про "лопатитЬся меньше данных"?... ;)  

Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

272. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 23:21 
На Threaded I/O Write Test, особенно на HDD, ZFS можно сравнивать только с BTRFS. Почему - уже объяснял в этой теме.
Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

446. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 19:25 
> http://www.phoronix.com/scan.php?page=article&item=linux_zfs...
> На HDD Ext4 чуточку слила LLNL ZFS

...а про то что их в этих тестах на механике совершенно дико порвал btrfs - тактично промолчал. Ох уж эти бсдшники! :)

"Если факты не подтверждают теорию, от них надо избавиться!" (законы мерфи). К сожалению для вас я иногда хожу по ссылкам :P

Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

263. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 22:47 
> Не совсем понимаю при чем тут ваш sysctl.

Ох уж эти провалы в памяти ...

> Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким
> ламерюгам желания совершенно нет.

С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-))


>> В UFS и ZFS это точно не так :-)))
> На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то
> близкое к этому.

Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье ЧСВ в потолок уперлось. :-)))

>> Все эти построения основаны на необходимости считывать данные которые могут хотябы
>> потенциально быть записаны последовательно.

Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались приблизительно с одинаковой скоростью ? Не ?

> Хм, вот это не помню, может и не умеет. В принципе объединение
> пространства неплохая идея, но в конечном итоге это уже относительно некритичный
> улучшайзер. Если уж посмотреть на бсды, там и такого нет.

Опять провалы в памяти ...

> Их в общем то нынче уже регулярно ловят, если что. Можно считать
> что на промышленной основе. Самолично не ловил, т.к. это требует слишком
> монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей
> различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы
> хоть что-то поймать, вещества должно быть много. Значит, установка будет большой.

Нейтрино не взаимодействует ни с чем ... месье далек от физики ? :-))

> Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно
> так же в этом плане. Так что странно что вы ими
> умудряетесь при этом пользоваться. Хотя судя по тому что вы так
> хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно
> не фонтан.

Анекдот в тему: приходят два недо-пхп-программиста сисадминами на работу устраиваться, и один другому говорит: - не bsdи? прорвемся ...

>> Именно переменные блоки дают преимущества над железными RAID.
> У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть
> один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум)
> как в ZFS. Что это означает? То что при непрерывной записи
> больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если
> некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его
> его как ОДНУ запись экстента.

Ага а если питаение в этот момент пропадет то его одним куском и похерит :-))


Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

332. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 21:17 
>> Не совсем понимаю при чем тут ваш sysctl.
> Ох уж эти провалы в памяти ...

Так продолжите мыслю в нормальном виде.

>> ламерюгам желания совершенно нет.
> С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-))

Ну и замечательно, мне же меньше геморроя.

> Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье
> ЧСВ в потолок уперлось. :-)))

Я могу себе представить как выглядело бы соответствующее размещение структур на диске. Только и всего. Насколько близко к этому приблизится реальный аллокатор - зависит от его реализации, разумеется. Просто в отличие от вас, полагающих что вам в высокие материи врубиться не дано, я предпочитаю понимать основы того как все это работает. И это не ЧСВ а констатация очевидных фактов. Просто капитанинг.

> Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались
> приблизительно с одинаковой скоростью ? Не ?

Они хотели одного: не бубухать в его переделку людские ресурсы которых у бсдшников сроду нет. Поэтому они оставили архаичный дизайн, примотав к нему скотчем и проволокой улучшайзеры.

А указанную вами цель на 100% не достигает практически ни 1 дизайн ФС. Ну кроме случая когда ФС отдефрагят, но там свои проблемы, в том что в клиническом случае дефраг может не справиться ни за какое разумное время вообще. Например, мсье как-то раз видел как виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе на всего жалких 40Гб за целые сутки непрерывного хрустения. Какая скорость работы всего этого - несложно догадаться. Да-да, хваленый вами нтфс выдавал 5-10Мб/сек, что для десктопного винча просто смехотворно. В итоге оказалось проще сдвинуть оттуда все файлы и переформатить. Не в пример быстрее и результативнее.

>> пространства неплохая идея, но в конечном итоге это уже относительно некритичный
>> улучшайзер. Если уж посмотреть на бсды, там и такого нет.
> Опять провалы в памяти ...

Ох, правда? Тогда покажите мне дефрагеры в вашей любимой bsd.

> Нейтрино не взаимодействует ни с чем ...

Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино и узнал что теория относительности не пошатнулась, просто GPS используемый для синхронизации малость налажал.

> месье далек от физики ? :-))

Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл "детектор нейтрино" - даже расскажут про них, какие бывают, где строят и прочая. Хотя может быть, все эти лохи тоже далеки от физики и только nagual у нас тут умный. Вот только он упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его относительная величина - мизер. А как же тогда радар у гайцев работает? А почему в GPS его учитывают? Они еще и теорию относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской механикой. А вот ФИГ.

> и один другому говорит: - не bsdи? прорвемся ...

Да, вам этот анекдот подходит, судя по постам :)

>> некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его
>> его как ОДНУ запись экстента.
> Ага а если питаение в этот момент пропадет то его одним куском и похерит :-))

Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл или будет в старом состоянии, или в новом. А что вы будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен. Зато выглядит почти как живой. В этом плане btrfs вообще монстр. Всегда можно отмотать на снапшот. Это настолько простая и легкая операция что он их на автомате делает. И при сбое просто отматывает на последний успешный снапшот. И рекавери при сбое быстрое и состояние файлов  куда предсказуемее чем обычно в классических ФС. В UFS это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь, мерседесом он от этого не станет.

Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

338. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 22:15 
>> Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье
>> ЧСВ в потолок уперлось. :-)))
> Я могу себе представить как выглядело бы соответствующее размещение структур на диске.
> Только и всего. Насколько близко к этому приблизится реальный аллокатор -
> зависит от его реализации, разумеется.

Ссылка на статью с описанием уже постилась.
> Просто в отличие от вас, полагающих
> что вам в высокие материи врубиться не дано, я предпочитаю понимать
> основы того как все это работает.

Судя по всему получается плохо ...
> И это не ЧСВ а
> констатация очевидных фактов. Просто капитанинг.

nagual выглядывая в окно - Однако осень.

> Поэтому они оставили архаичный дизайн, примотав к нему
> скотчем и проволокой улучшайзеры.

ext2 ext3 ext4 ... ждем ext5 ? :-))

> Например, мсье как-то раз видел как
> виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе
> на всего жалких 40Гб за целые сутки непрерывного хрустения.

Неужели месье за столько лет работы с разными фс так и не понял что любую фс нельзя забивать выше 70% ?


>> Нейтрино не взаимодействует ни с чем ...
> Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом
> вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют
> с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить
> вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более
> того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино
> и узнал что теория относительности не пошатнулась, просто GPS используемый для
> синхронизации малость налажал.

Товарищ сержант а танки летают ? летают только очень низко ... :-)))

> Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл
> "детектор нейтрино"

Если бы месье асилил хотябы первый том Левашева ему бы в голову не пришло вводить в гугл "детектор нейтрино"  :-)))

> даже расскажут про них, какие бывают, где строят
> и прочая. Хотя может быть, все эти лохи тоже далеки от
> физики и только nagual у нас тут умный.

Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну и где практическая польза от вложения ?

> Вот только он
> упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его
> относительная величина - мизер. А как же тогда радар у гайцев
> работает? А почему в GPS его учитывают? Они еще и теорию
> относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской
> механикой. А вот ФИГ.

Это те радары которые постоянно глючат ? :-)))


> Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл
> или будет в старом состоянии, или в новом. А что вы
> будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен.

Вспоминается копирование файла в несколько гиг по сети в вин 98 ... копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-)))

> Зато выглядит почти как живой. В этом плане btrfs вообще монстр.
> Всегда можно отмотать на снапшот. Это настолько простая и легкая операция
> что он их на автомате делает. И при сбое просто отматывает
> на последний успешный снапшот. И рекавери при сбое быстрое и состояние
> файлов  куда предсказуемее чем обычно в классических ФС. В UFS
> это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна
> этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь,
> мерседесом он от этого не станет.

Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в продакшен ни ни ...


Ответить | Правка | ^ к родителю #332 | Наверх | Cообщить модератору

340. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 22:35 
> Неужели месье за столько лет работы с разными фс так и не
> понял что любую фс нельзя забивать выше 70% ?

[root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/dev/null bs=1048576
1088+1 записей считано
1088+1 записей написано
скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c

[root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_03_\(1920x1080_Blu-ray_FLAC\)_\[115BDB01\].mkv of=/dev/null bs=1048576
1044+1 записей считано
1044+1 записей написано
скопировано 1095420279 байт (1,1 GB), 11,2429 c, 97,4 MB/c

[root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_04_\(1920x1080_Blu-ray_FLAC\)_\[73670FA5\].mkv of=/dev/null bs=1048576
1068+1 записей считано
1068+1 записей написано
скопирован 1120538941 байт (1,1 GB), 10,574 c, 106 MB/c

[root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=1024
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 3,41094 c, 315 MB/c

[root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t3 bs=1048576 count=1024
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 3,32492 c, 323 MB/c

[root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t4 bs=1048576 count=4096
4096+0 записей считано
4096+0 записей написано
скопировано 4294967296 байт (4,3 GB), 16,3468 c, 263 MB/c

[root@storage ~]# dd if=/data/Anime/test.t2 bs=1048576 of=/dev/null
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 5,15343 c, 208 MB/c

[root@storage ~]# dd if=/data/Anime/test.t3 bs=1048576 of=/dev/null
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 5,09285 c, 211 MB/c

[root@storage ~]# dd if=/data/Anime/test.t4 bs=1048576 of=/dev/null
4096+0 записей считано
4096+0 записей написано
скопировано 4294967296 байт (4,3 GB), 20,0763 c, 214 MB/c

[root@storage ~]# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/mapper/Anime-Anime
                      1,3T  1,2T   30G  98% /data/Anime

[root@storage ~]# mount
/dev/mapper/Anime-Anime on /data/Anime type ext4 (rw,user_xattr)

Что я делаю не так? Том забит на 98%, новые файлы пишутся и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом...

Все зависит от ворклоада. Ну и да - там, где блочный аллокатор сдохнет, экстентный живет вполне нормально.

Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более того.

# cat /proc/meminfo
MemTotal:        1020596 kB

Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

345. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 23:39 
> Что я делаю не так? Том забит на 98%, новые файлы пишутся
> и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом...
> Все зависит от ворклоада. Ну и да - там, где блочный аллокатор
> сдохнет, экстентный живет вполне нормально.
> Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более
> того.
> # cat /proc/meminfo
> MemTotal:        1020596 kB

Во первых диск ссд а не хдд, во вторых кеширование, в третих интересна только запись. Если у месье все тесты проводятся с такой точностью то наверно не стоит тратить время ...


Ответить | Правка | ^ к родителю #340 | Наверх | Cообщить модератору

354. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 23:51 
> Во первых диск ссд а не хдд, во вторых кеширование, в третих

Seagate 7200.11, RAID 5

> интересна только запись

Дык, она выше есть.

Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

357. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 23:55 
> Seagate 7200.11, RAID 5

3 диска в массиве. Параллельно с этого же массива выполняются 7 виртуальных машин, из которых 4 достаточно бодренькие по отношению к диску - MySQL, две площадки LA(M)P, и MaNGOS. Роутерная виртуалка со сквидом не в счёт.

Ответить | Правка | ^ к родителю #354 | Наверх | Cообщить модератору

362. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 00:20 
>скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c

Да нет там кеширования :-))
Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз записано ? :-)) Вот и в современной науке полно ученых с такими навыками тестирования :-))

Ответить | Правка | ^ к родителю #354 | Наверх | Cообщить модератору

369. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 07:34 
> Да нет там кеширования :-))

"Вызывает небольшую погрешность измерений при записи, но не более того." - не предполагает отсутствия кэша, какбэ. Естественно, кэш есть. <512 Мб свободных на площадке, и 512 Мб в контроллере (общий на всю платформу).

Поэтому если при записи 1Гб+ он еще дает какую-никакую погрешность - то при записи 4Гб она уже собственно минимальна.

Специально показал скорость кэша в первой же строчке, и во второй - то, что при чтении следующего гигового файла кеш уже не актуален - он меньше гига объёмом.

> Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз

Виртуалка. ESXi 5.0, VMFS объемом в 1.3 тера, 98% занято.

Ответить | Правка | ^ к родителю #362 | Наверх | Cообщить модератору

375. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 08:42 
>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше.

Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй яй :-)))

Ответить | Правка | ^ к родителю #369 | Наверх | Cообщить модератору

378. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 25-Сен-12, 09:17 
>>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше.
> Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи
> как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на
> подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй
> яй :-)))

Один конкретный читатель оказался настолько туп, что увидев строчку с тестом кеша пустил сопли.

Ответить | Правка | ^ к родителю #375 | Наверх | Cообщить модератору

447. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 19:28 
> Во первых диск ссд а не хдд,

И что? Ну выпускаются они. Массово. Стало быть с ними надлежит нормально работать.

Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

342. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 22:39 
>> Поэтому они оставили архаичный дизайн, примотав к нему
>> скотчем и проволокой улучшайзеры.
> ext2 ext3 ext4 ... ждем ext5 ? :-))

Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.

Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

349. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 24-Сен-12, 23:45 
>>> Поэтому они оставили архаичный дизайн, примотав к нему
>>> скотчем и проволокой улучшайзеры.
>> ext2 ext3 ext4 ... ждем ext5 ? :-))
> Между ext3 и ext4 - огромная пропасть.

Скотч проволка клей и спички ?


Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

466. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 01-Окт-12, 15:21 
> Скотч проволка клей и спички ?

Прямо описание процесса разработки UFS. Надо же, к антикварному драндулету приклеили антикрыло. Которое впрочем там нафиг не упало из-за аэродинамики класса "кирпич".


Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

515. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 02-Окт-12, 21:26 
> Скотч проволка клей и спички ?

Хоть слезы девственницы, если оно работает и делает это быстро и хорошо.


Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

365. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 00:36 
>>> Поэтому они оставили архаичный дизайн, примотав к нему
>>> скотчем и проволокой улучшайзеры.
>> ext2 ext3 ext4 ... ждем ext5 ? :-))
> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.

ZFSv29 — RAID-Z/mirror hybrid allocator

Это то, о чём вы думаете?


Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

373. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 08:04 
>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.
> ZFSv29 — RAID-Z/mirror hybrid allocator
> Это то, о чём вы думаете?

Иногда лучше читать, прежде чем говорить...

Ответить | Правка | ^ к родителю #365 | Наверх | Cообщить модератору

377. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –2 +/
Сообщение от nagual email(ok) on 25-Сен-12, 08:50 
>>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.
>> ZFSv29 — RAID-Z/mirror hybrid allocator
>> Это то, о чём вы думаете?
> Иногда лучше читать, прежде чем говорить...

Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей не читали ...

Ответить | Правка | ^ к родителю #373 | Наверх | Cообщить модератору

379. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 25-Сен-12, 09:17 
> Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей
> не читали ...

И я о том же.

Ответить | Правка | ^ к родителю #377 | Наверх | Cообщить модератору

494. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 11:00 
> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.

Чтож вы не предупредили что запилено совсем недавно ?
http://forum.ubuntu.ru/index.php?topic=80218.0
Это очередная обкатка технологий корпорациями ?
Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs которую ждут с концу года
https://www.opennet.ru/opennews/art.shtml?num=32974

ЗЫ Вот так некоторые начитаются слоника в домене и строят проекты на нестабильном дистрибутиве, на нестабильной фс ...


Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

497. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 02-Окт-12, 12:42 
А между тем, в продакшне ext4 работает, и работает абсолютно стабильно.
Ответить | Правка | ^ к родителю #494 | Наверх | Cообщить модератору

533. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 06-Окт-12, 15:52 
> Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs

Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько. XFS - вообще черт знает когда. Где-то в районе 2.6.28 был прибит последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых багов там вообще особо не чинилось. А EXT4 тогда только-только собирался выйти из -dev еще. И стал реально юзабелен в районе 2.6.32 примерно. И то - пару кондовых но к счастью суперредких багов потом починили. Один баг мог приводить к разрушению ФС, но вероятность на него наступить такова что проще выиграть джек-пот в лотерею, т.к. это происходит только при работе с очень большими файлами (более скольких-то Тб размером).

Ответить | Правка | ^ к родителю #494 | Наверх | Cообщить модератору

534. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 06-Окт-12, 18:06 
> Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько.

Кем заявлено ораклом ?
А недавно микрософ заяволо о стабильности вин8 ага ...

> XFS- вообще черт знает когда. Где-то в районе 2.6.28 был прибит
> последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых
> багов там вообще особо не чинилось. А EXT4 тогда только-только собирался
> выйти из -dev еще. И стал реально юзабелен в районе 2.6.32
> примерно. И то - пару кондовых но к счастью суперредких багов
> потом починили. Один баг мог приводить к разрушению ФС, но вероятность
> на него наступить такова что проще выиграть джек-пот в лотерею, т.к.
> это происходит только при работе с очень большими файлами (более скольких-то
> Тб размером).

Ну про xfs верим.

Ответить | Правка | ^ к родителю #533 | Наверх | Cообщить модератору

393. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 20:02 
>> Только и всего. Насколько близко к этому приблизится реальный аллокатор -
>> зависит от его реализации, разумеется.
> Ссылка на статью с описанием уже постилась.

Что - ссылка? Если вы не можете кратенько, в двух словах изложить что вы имели в виду без отсылок к различным простыням - грош вам цена в базарный день. Это означает что вы сами не поняли что там написано.

> Судя по всему получается плохо ...

По крайней мере, лучше чем у вас. Во всяком случае, я могу своим мозгом прикинуть что получится и что может получиться при том или ином дизайне ФС. А вы только и умеете что куда-то отсылать. Сами сформулировать мысль вы вообще не в состоянии.

> nagual выглядывая в окно - Однако осень.

Да уж, школьники и студенты вернулись с каникул, блин. Вы домашку то уже сделали, мсье спорщик? :)

> ext2 ext3 ext4 ... ждем ext5 ? :-))

Думаю что таковым станет btrfs. И да, в 4-й версии по крайней мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать с скоростью современных ФС.

>> на всего жалких 40Гб за целые сутки непрерывного хрустения.
> Неужели месье за столько лет работы с разными фс так и не
> понял что любую фс нельзя забивать выше 70% ?

Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но лучше так все-таки не делать. Хотя с дефрагером уже и можно пожировать: в случае чего отдефрагать можно.

> Товарищ сержант а танки летают ? летают только очень низко ... :-)))

Простите, у вас 1 извилина, и та от фуражки? Ну или почему вы не в состоянии вбить в гугль фразу "детектор нейтрино" и узнать много нового о существовании таковых?

>> "детектор нейтрино"
> Если бы месье асилил хотябы первый том Левашева ему бы в голову
> не пришло вводить в гугл "детектор нейтрино"  :-)))

А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными фактами. В частности, нейтрино не только детектируют, но и использовали их в ряде экспериментов на БАК. В том числе как раз потому что они очень слабо взаимодействуют с веществом и поэтому без проблем пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами. Мало какая частица протиснется через полпланеты без построения специальных каналов для удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А нейтрино - запросто. Что делает его ценной штукой для посылки в сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в нужную сторону и все, готово. Это же свойство и затрудняет детектирование. Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе детектируется. Просто эффективность детектирования - низкая, поэтому требуется большой детектор для сколь-нибудь заметного результата.

>> физики и только nagual у нас тут умный.
> Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну
> и где практическая польза от вложения ?

Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий насчет мира элементарных частиц. Хомякам от этого ничего не будет, по крайней мере немедленно и сейчас. Но в целом знания о том где мы живем и как это устроено - нужны. Должны же мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность? Желание познавать устройство мира - одно из проявлений интеллекта.

>> относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться
>> ньютоновской механикой. А вот ФИГ.
> Это те радары которые постоянно глючат ? :-)))

Когда гражданин полицейский заинтересован палку срубить - тогда глючит. А так - эффект есть и работает. Впрочем он намного нагляднее слышен когда проезжающий мимо поезд издает гудок. При этом монотонный звук гудка превращается в очень характерный звук меняющийся по высоте. Удачи оспорить столь вопиющее проявление.

> копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-)))

Крокодил^W нейтрино не ловится, не растет кокос^W^W^W сеть глючит. Как вы живете вообще? :)

> Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в
> продакшен ни ни ...

Ну вообще с учетом тенденций указанных выше я не удивлен что у вас ext4 не чинится. И ZFS наверное рассыпется скоро.

Ответить | Правка | ^ к родителю #338 | Наверх | Cообщить модератору

395. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 20:19 
> По крайней мере, лучше чем у вас. Во всяком случае, я могу
> своим мозгом прикинуть что получится и что может получиться при том
> или ином дизайне ФС. А вы только и умеете что куда-то
> отсылать. Сами сформулировать мысль вы вообще не в состоянии.

ВЫ главное результаты своих изысканий никому не показывайте :-))

> Думаю что таковым станет btrfs. И да, в 4-й версии по крайней
> мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать
> с скоростью современных ФС.

А современные это какие если не ufs ext4 b zfs ? Неужно ntfs ? :))))

> Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике
> EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но
> лучше так все-таки не делать. Хотя с дефрагером уже и можно
> пожировать: в случае чего отдефрагать можно.

Учитывая скорость работы мозга особенно у руководства 70% это как раз тот момент когда нужно искать новое хранилище.

> Простите, у вас 1 извилина, и та от фуражки? Ну или почему
> вы не в состоянии вбить в гугль фразу "детектор нейтрино" и
> узнать много нового о существовании таковых?

У меня такое впечатление что вы распрямитель рук для головы применили. Не все йогурты одинаково полезны ...

> А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными
> фактами.

Экспериментально доказано что неуловимый Джо пойман ... :-)))
>[оверквотинг удален]
> что они очень слабо взаимодействуют с веществом и поэтому без проблем
> пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по
> пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами.
> Мало какая частица протиснется через полпланеты без построения специальных каналов для
> удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А
> нейтрино - запросто. Что делает его ценной штукой для посылки в
> сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в
> нужную сторону и все, готово. Это же свойство и затрудняет детектирование.
> Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе
> детектируется.

А еще месье до сих пор верит в Деда Мороза.

> Просто эффективность детектирования - низкая, поэтому требуется большой
> детектор для сколь-нибудь заметного результата.

Летают но очень низко ... :-)))

> Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий
> насчет мира элементарных частиц. Хомякам от этого ничего не будет, по
> крайней мере немедленно и сейчас. Но в целом знания о том
> где мы живем и как это устроено - нужны. Должны же
> мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность?
> Желание познавать устройство мира - одно из проявлений интеллекта.

Месье так же верит что в наперстки можно выиграть ? :-))) Вы случайно все это не по телевизору увидели ? :-)))))


Ответить | Правка | ^ к родителю #393 | Наверх | Cообщить модератору

212. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 19:13 
>> Палундра в ZFS нет дефрагментатора %)
> Да вон iZEN уже ощущает результат. И даже если он осовободит место,
> сильно лучше может и не стать. В общем то нет простого
> метода расчистить такое без дефрагментатора.

Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433
//---
% dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M
74+1 records in
74+1 records out
1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec)

% df /store/video
Filesystem     Size    Used   Avail Capacity  Mounted on
store/video    790G    789G    1.1G   100%    /store/video
---//

Стало:
% dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M
74+1 records in
74+1 records out
1561257376 bytes transferred in 18.599765 secs (83939630 bytes/sec)

% df /store/video
Filesystem     Size    Used   Avail Capacity  Mounted on
store/video    789G    757G     32G    96%    /store/video

И как? Стало лучше, по-твоему? ;)

На самом деле тут одна особенность выяснилась. Тормозила не столько запись на RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы).

Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

218. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 19:36 
>>> Палундра в ZFS нет дефрагментатора %)
>> Да вон iZEN уже ощущает результат. И даже если он осовободит место,
>> сильно лучше может и не стать. В общем то нет простого
>> метода расчистить такое без дефрагментатора.
> Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433
> Стало:

Косяк. Надо скорость чтения файла, который клался на том под конец его захламливания.
Понятно, что если стереть всё с тома и набить одним заходом заново - будет лучше. Но вот тому, что уже набито, от освобождения места лучше не станет.

Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

223. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:14 
>[оверквотинг удален]
>>> Да вон iZEN уже ощущает результат. И даже если он осовободит место,
>>> сильно лучше может и не стать. В общем то нет простого
>>> метода расчистить такое без дефрагментатора.
>> Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433
>> Стало:
> Косяк. Надо скорость чтения файла, который клался на том под конец его
> захламливания.
> Понятно, что если стереть всё с тома и набить одним заходом заново
> - будет лучше. Но вот тому, что уже набито, от освобождения
> места лучше не станет.

А оно изначально было "набито" без модификации, на новый чистый пул. Потом шла дозапись данными. Чему там тормозить?!


Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

229. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:27 
> А оно изначально было "набито" без модификации, на новый чистый пул. Потом
> шла дозапись данными. Чему там тормозить?!

Ключевое слово - "дозапись". А если там еще и удаления были - вот тут уже всё интереснее.
Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома до 99% :)

Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

238. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:37 
>> А оно изначально было "набито" без модификации, на новый чистый пул. Потом
>> шла дозапись данными. Чему там тормозить?!
> Ключевое слово - "дозапись". А если там еще и удаления были -
> вот тут уже всё интереснее.
> Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома
> до 99% :)

А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при просмотре и ладно. ;)

Сейчас:
% dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M
726+1 records in
726+1 records out
15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec)

Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

242. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:40 
> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при
> просмотре и ладно. ;)

Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое ставить жутковато.

Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

243. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:42 
>> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при
>> просмотре и ладно. ;)
> Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое
> ставить жутковато.

Сейчас:
% dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M
726+1 records in
726+1 records out
15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec)
Второй раз:
% dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M
726+1 records in
726+1 records out
15235365714 bytes transferred in 125.197637 secs (121690521 bytes/sec)

Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

250. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 21:05 
> 1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec)

Да-да, скорость хуже чем у самой засраной флешки.

>  32G    96%    /store/video
> И как? Стало лучше, по-твоему? ;)

По-моему, если ты возьмешь файл который читался со скоростью 6мб/сек и сотрешь другой файл, то он продолжит читаться со скоростью 6мб/сек. Просто потому что его некому дефрагментировать ;)

> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи
> файла, который был предварительно закэширован в ARC ZFS

У, блин, так ты еще и читер. Если я закеширую что-нибудь в оперативку - я тебе покажу и гигазы в секунду запросто :)

Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

258. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 21:47 
>> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи
>> файла, который был предварительно закэширован в ARC ZFS
> У, блин, так ты еще и читер. Если я закеширую что-нибудь в
> оперативку - я тебе покажу и гигазы в секунду запросто :)

Уже не различаешь скорость чистой записи в пул? Так вот, после кэширования файла в ARC и повторной операции записи показана чистая, ничем незамутнённая скорость записи данных на пул. А как ещё её проверить? Расскажи, послушаем, вместе посмеёмся. :))


Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

252. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 21:16 
>[оверквотинг удален]
> Avail Capacity  Mounted on
> store/video    789G    757G    
>  32G    96%    /store/video
> И как? Стало лучше, по-твоему? ;)
> На самом деле тут одна особенность выяснилась. Тормозила не столько запись на
> RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400
> rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного
> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи
> файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два
> раза, представлен второй, наилучший результат её работы).

А сколько было в самом начале до заполнения на 100% ?

Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

259. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 21:50 
>[оверквотинг удален]
>> store/video    789G    757G
>>  32G    96%    /store/video
>> И как? Стало лучше, по-твоему? ;)
>> На самом деле тут одна особенность выяснилась. Тормозила не столько запись на
>> RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400
>> rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного
>> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи
>> файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два
>> раза, представлен второй, наилучший результат её работы).
> А сколько было в самом начале до заполнения на 100% ?

Где? На том диске, с которого считывается тестовый файл, или на тому пуле, куда он записывается? Около 2-6 МБ/с. Где-то так. Скорость записи на освобождённый пул уже значительно больше.


Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

264. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 22:53 
>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы).

Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал скорость кэша, не более того. Да и для памяти что-то как-то очень хреново.

Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

284. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 24-Сен-12, 00:01 
>>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы).
> Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал
> скорость кэша, не более того.

Из кэша памяти на пул записываются данные. Что в этом не так?

Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

333. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 21:21 
> Из кэша памяти на пул записываются данные. Что в этом не так?

Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд. Если все так, давай тогда считать что у меня скорость записи на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на крайних треках выдает мы умолчим, во :)

Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

337. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 24-Сен-12, 21:56 
>> Из кэша памяти на пул записываются данные. Что в этом не так?
> Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд.
> Если все так, давай тогда считать что у меня скорость записи
> на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на
> крайних треках выдает мы умолчим, во :)

Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd — честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая в конце операции, стала бы филькиной грамотой.

Ответить | Правка | ^ к родителю #333 | Наверх | Cообщить модератору

339. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 22:28 
> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе
> 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd —
> честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая
> в конце операции, стала бы филькиной грамотой.

Спасибо, повеселил.

# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216
68+1 записей считано
68+1 записей написано
скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c

# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216
68+1 записей считано
68+1 записей написано
скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c

Это скорость операций с диском магически удвоилась, или все-таки ты не прав насчёт кеша? Как считаешь?

Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

363. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 00:29 
>[оверквотинг удален]
> 68+1 записей считано
> 68+1 записей написано
>  скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c
> # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv
> of=/data/Anime/test.t1 bs=16777216
> 68+1 записей считано
> 68+1 записей написано
>  скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c
> Это скорость операций с диском магически удвоилась, или все-таки ты не прав
> насчёт кеша? Как считаешь?

Я считаю, что таким образом ты сравниваешь скорость чтения-записи (суммарно) со скоростью записи (только) из кэша. В первом случае идёт разогревание файлового кэша путём считывания в него данных с диска, а во втором случае кэш уже разогрет и измеряется практически чистая скорость записи данных из оперативной памяти (разогретого файлового кэша) на диск без особых накладных расходов на чтение с механического устройства.

Если у меня файл 14 ГБ с одного диска 5400 rpm будет читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который имеет среднюю скорость записи в районе 200 МБ/с, то, как ты думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, потому что данные поступаю на запись с такой скоростью из медленного источника. Источник (медленный механический диск) — это бутылочное горлышко потока байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из оперативной памяти (буфера на запись — в общем случае), а не из какого-то ущербного соска. Я просто измерил чистую скорость записи на RAID-Z, вот и всё.

Ответить | Правка | ^ к родителю #339 | Наверх | Cообщить модератору

364. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 00:35 
>[оверквотинг удален]
> Если у меня файл 14 ГБ с одного диска 5400 rpm будет
> читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который
> имеет среднюю скорость записи в районе 200 МБ/с, то, как ты
> думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с,
> потому что данные поступаю на запись с такой скоростью из медленного
> источника. Источник (медленный механический диск) — это бутылочное горлышко потока
> байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из
> оперативной памяти (буфера на запись — в общем случае), а не
> из какого-то ущербного соска. Я просто измерил чистую скорость записи на
> RAID-Z, вот и всё.

Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png
Кстати 4 диска по цене столько же как 3 + контроллер :-)) а из raid0+1 можно вытащить 2 любых диска :-))

Ответить | Правка | ^ к родителю #363 | Наверх | Cообщить модератору

366. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 01:12 
>[оверквотинг удален]
>> имеет среднюю скорость записи в районе 200 МБ/с, то, как ты
>> думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с,
>> потому что данные поступаю на запись с такой скоростью из медленного
>> источника. Источник (медленный механический диск) — это бутылочное горлышко потока
>> байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из
>> оперативной памяти (буфера на запись — в общем случае), а не
>> из какого-то ущербного соска. Я просто измерил чистую скорость записи на
>> RAID-Z, вот и всё.
> Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из
> трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png

Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E).

> а из raid0+1 можно вытащить 2 любых диска :-))

Нет, не любые два, а только из одной страйп-ветви.

RAID-6 из четырёх дисков "позволяет" потерять два любых диска.

Ответить | Правка | ^ к родителю #364 | Наверх | Cообщить модератору

367. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 01:44 
>[оверквотинг удален]
>>> из какого-то ущербного соска. Я просто измерил чистую скорость записи на
>>> RAID-Z, вот и всё.
>> Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из
>> трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png
> Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна
> дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня
> RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E).
>> а из raid0+1 можно вытащить 2 любых диска :-))
> Нет, не любые два, а только из одной страйп-ветви.
> RAID-6 из четырёх дисков "позволяет" потерять два любых диска.

Vmware на диск пишет чествно и здравый смысл не обгоняет.

umount -f /dev/da10p1
gpart delete -i 1 da10
gpart destroy da10

gpart create -s gpt /dev/da10
gpart add -t freebsd-ufs -l disk0 da10
newfs -J -O2 -U /dev/da10p1
mkdir -p /mnt/da10p1
mount /dev/da10p1 /mnt/da10p1
touch /mnt/da10p1/test

dd if=/dev/random of=/mnt/da10p1/test bs=1M count=2000
df -H |grep da10

da10p1 deleted
da10 destroyed
da10 created
da10p1 added
/dev/da10p1: 2048.0MB (4194232 sectors) block size 32768, fragment size 4096
        using 4 cylinder groups of 512.00MB, 16384 blks, 65536 inodes.
        with soft updates
super-block backups (for fsck_ffs -b #) at:
192, 1048768, 2097344, 3145920

/mnt/da10p1: write failed, filesystem is full
dd: /mnt/da10p1/test: No space left on device
1983+0 records in
1982+0 records out
2078277632 bytes transferred in 31.129022 secs (66763345 bytes/sec)
/dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1

скорость приблизительно одинаковая 66763345 bytes/sec

без -J
2078277632 bytes transferred in 30.756519 secs (67571939 bytes/sec)

без -S
2078277632 bytes transferred in 30.515984 secs (68104559 bytes/sec)

Вобщем в виртуалке результаты тестов сомнительны.

Ответить | Правка | ^ к родителю #366 | Наверх | Cообщить модератору

372. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 08:03 
> /dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1

Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность в *BSD всегда, или надо как-то специфично изголяться?

Ответить | Правка | ^ к родителю #367 | Наверх | Cообщить модератору

467. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 01-Окт-12, 15:26 
> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность
> в *BSD всегда, или надо как-то специфично изголяться?

Ух ты, отрицательное свободное место на диске :). Интересно, это как? :)

Ответить | Правка | ^ к родителю #372 | Наверх | Cообщить модератору

478. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 00:25 
>> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность
>> в *BSD всегда, или надо как-то специфично изголяться?
> Ух ты, отрицательное свободное место на диске :). Интересно, это как? :)

Это когда на диск в 6гиг под btrfs пишешь 5.2 и вдруг нет не так ВДРУГ место кончается ...
Самое смешьное это когда одно из трех такое ВДРУГ лечится только ребутом :-)))

ЗЫ linux сер ...

Ответить | Правка | ^ к родителю #467 | Наверх | Cообщить модератору

489. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 07:32 
Ряд утилит с uint под показатель дискового места будут очень рады такому ответу системы (отрицательному значению)...
Ответить | Правка | ^ к родителю #478 | Наверх | Cообщить модератору

371. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 08:00 
> а из raid0+1 можно вытащить 2 любых диска :-))

На хабре написали?
Удачи в вытаскивании.

Ответить | Правка | ^ к родителю #364 | Наверх | Cообщить модератору

370. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 07:59 
> Если у меня файл 14 ГБ с одного диска 5400 rpm будет
> читаться со скоростью 10-20 МБ/с

То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения - надо очень постараться.

Был спор: влияет ли кэш на dd. Ты сказал, что dd - какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл опровержение. К чему все остальное словоблудие - непонятно.

Чистая скорость записи на FS без компрессии измеряется просто и быстро:

dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero of=/path/test bs/count=четырехкратный объем кеша

Результат второго запуска можно считать более-менее достоверным. Ну или просто вторую часть теста - там будет погрешность измерений порядка 10-15%, в зависимости от скорости дисков.

# dd if=/dev/zero of=/data/Anime/thrash.t1 bs=1048576 count=2048 ; dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=4096
2048+0 записей считано
2048+0 записей написано
скопировано 2147483648 байт (2,1 GB), 8,92 c, 241 MB/c
4096+0 записей считано
4096+0 записей написано
скопировано 4294967296 байт (4,3 GB), 17,8542 c, 241 MB/c

Ответить | Правка | ^ к родителю #363 | Наверх | Cообщить модератору

376. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 08:45 
> Если у меня файл 14 ГБ с одного диска 5400 rpm будет
> читаться со скоростью 10-20 МБ/с

Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе.

Ответить | Правка | ^ к родителю #370 | Наверх | Cообщить модератору

490. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 07:33 
>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет
>> читаться со скоростью 10-20 МБ/с
> Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе.

У него FreeBSD, детка.

Ответить | Правка | ^ к родителю #376 | Наверх | Cообщить модератору

381. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 12:44 
>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет
>> читаться со скоростью 10-20 МБ/с
> То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения
> - надо очень постараться.

"Очень постараться" — это иметь дедупликацию ZFS на заполненном пуле. ;)

> Был спор: влияет ли кэш на dd. Ты сказал, что dd -
> какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл
> опровержение. К чему все остальное словоблудие - непонятно.

Я не говорил, что кэш не влияет на dd(1). Я показал, какую роль играет неразогретый и разогретый кэш при чтении-записи файла с помощью dd(1) с диска на диск (обмен данными между пулами).

> Чистая скорость записи на FS без компрессии измеряется просто и быстро:
> dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero
> of=/path/test bs/count=четырехкратный объем кеша

Пишется на один диск WD:
% dd if=/dev/zero of=/downloads1/test0.img bs=100M count=10
10+0 records in
10+0 records out
1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec)
% dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10
10+0 records in
10+0 records out
1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec)
% dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50
50+0 records in
50+0 records out
5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec)
% dd if=/dev/zero of=/downloads1/test2000.img bs=2000M count=5
5+0 records in
5+0 records out
10485760000 bytes transferred in 913.458192 secs (11479190 bytes/sec)

Ответить | Правка | ^ к родителю #370 | Наверх | Cообщить модератору

382. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 12:54 
>[оверквотинг удален]
> 10+0 records out
> 1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec)
> % dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10
> 10+0 records in
> 10+0 records out
> 1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec)
> % dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50
> 50+0 records in
> 50+0 records out
> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec)

А представьте нам скрипт тестирования в полном виде, не для праздного интереса а чтоб мы могли повторить эксперимент и чтоб у нас небыло оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании фс. ;-)

Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

383. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 13:13 
> А представьте нам скрипт тестирования в полном виде, не для праздного интереса
> а чтоб мы могли повторить эксперимент и чтоб у нас небыло
> оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании
> фс. ;-)

Сейчас всё брошу и буду скрипт писать для вас.

Ответить | Правка | ^ к родителю #382 | Наверх | Cообщить модератору

384. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 13:31 
Месье учил нас пользоваться гуглем, ну чтож:

zfs core dump Результатов: примерно 33 900 (0,15 сек.)
ой

btrfs core dump Результатов: примерно 91 600 (0,12 сек.)
ОО

ufs2 core dump Результатов: примерно 19 100 (0,12 сек.)
ээх

ext4 core dump Результатов: примерно 142 000 (0,10 сек.)
аяяйяй

ext3 core dump Результатов: примерно 477 000 (0,37 сек.)
вау

ext2 core dump Результатов: примерно 212 000 (0,16 сек.)
не зря не зря его пилили ...

UFS core dump Результатов: примерно 434 000 (0,28 сек.)
сумма за все годы ?

xfs core dump Результатов: примерно 195 000 (0,45 сек.)
если суммировать ext2-ext4 да еще это добавить :-))

ntfs failed Результатов: примерно 3 260 000 (0,11 сек.)
лидер во всем :-))

raid failure Результатов: примерно 48 900 000 (0,28 сек.)

hdd failure Результатов: примерно 13 700 000 (0,30 сек.)
за все время

ssd failure Результатов: примерно 6 690 000 (0,18 сек.)
догоним и перегоним ?

lvm failed Результатов: примерно 1 020 000 (0,24 сек.)
lol

geom failed Результатов: примерно 375 000 (0,26 сек.)
да уж ...

Поиск сила :-)))

Ответить | Правка | ^ к родителю #383 | Наверх | Cообщить модератору

386. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 25-Сен-12, 17:06 
Ну да. У неуловимых Джо кейсов, естественно, близко к 0 - ибо никто не юзает и не собирается.

ext4 in production
Результатов: примерно 2 240 000 (0,45 сек.)

ext3 in production
Результатов: примерно 3 570 000 (0,43 сек.)

ufs in production
Результатов: примерно 871 000 (0,34 сек.)
упс.

zfs in production
Результатов: примерно 536 000 (0,37 сек.)
ой? :)

raid in production
Результатов: примерно 60 400 000 (0,33 сек.)
argh!

Ответить | Правка | ^ к родителю #384 | Наверх | Cообщить модератору

448. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 19:31 
> Поиск сила :-)))

Неандерталец открыл для себя микроволновку :)

Ответить | Правка | ^ к родителю #384 | Наверх | Cообщить модератору

385. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 25-Сен-12, 17:05 
> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec)

26Mb/sec
Страшно фрагментированный том, видимо.

Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

387. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 25-Сен-12, 18:26 
>> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec)
> 26Mb/sec
> Страшно фрагментированный том, видимо.

Да нет. Просто на нём свободного места около 12 ГБ.


Ответить | Правка | ^ к родителю #385 | Наверх | Cообщить модератору

392. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 19:09 
Итак давайте обсудим оптимальные для тестов  bs и count :-))
Ответить | Правка | ^ к родителю #387 | Наверх | Cообщить модератору

399. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 22:11 
> Да нет. Просто на нём свободного места около 12 ГБ.

Скорость записи не зависит от количества свободного места. А вот от его фрагментированности - запросто.

Ответить | Правка | ^ к родителю #387 | Наверх | Cообщить модератору

394. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 20:03 
> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе
> 2ГБ/с — вместе посмеёмся.

Да вон тебе перец показал уже скорость в 3Гб/сек. Тебе мало? :)

Ответить | Правка | ^ к родителю #337 | Наверх | Cообщить модератору

137. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 22-Сен-12, 23:36 
> у btrfs есть встроенный дефраг. В ZFS такого не было, да.
> Почему? Наверное потому что это одна из первых CoW ФС.

Наверно потому что в продажу пошли первые SSD диски. Это отлично что вы рассказали нам про встроенный в бтрфс дефрагментатор. Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы ... В этом плане ZFS с ее COW и SSD друзья а так как ZFS позицианируется под BD то урреждающее чтение или дефрагментация там и нафиг ненужны.

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

147. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 09:55 
>>> В этом плане ZFS с ее COW и SSD друзья

Снова садись, снова два. Без TRIM они не то, что не друзья, а вообще не совместимы генетически.

Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

155. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:13 
>>>> В этом плане ZFS с ее COW и SSD друзья
> Снова садись, снова два. Без TRIM они не то, что не друзья,
> а вообще не совместимы генетически.

Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам что вы понимаете под TRIM а то мало ли вдруг и тут что то левое :-))

Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

162. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 11:23 
> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам
> что вы понимаете под TRIM а то мало ли вдруг и
> тут что то левое :-))

Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, когда они освобождаются в ФС. Зачем это надо? Затем, что внутри флешки есть механизм веарлевелинга (по сути тот же CoW), который использует под новые данные незанятые блоки. Но вот - увы и ах - флешка ничего не знает про файловую систему. Чтобы сказать ей, что блок свободен - нужен TRIM.

И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке не останется ничего другого, кроме как использовать под веарлевелинг при любой записи небольшой "временный набор" - резерв пространства как раз для этих целей. По мере заполнения "надлежащей" файловой системы запись все чаще и чаще будет перезаписью, и срок работы флешки сократится в разы.

Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, только запись новых данных. Таким образом производительность без TRIM тоже под вопросом.

Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

166. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:33 
> По мере заполнения "надлежащей" файловой системы запись все чаще и
> чаще будет перезаписью

Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет адресовать места больше чем на диске :))) тоесть когда ZFS забьет все свбодное место она сама начнет перезаписывать самые старые неактуальные записи :-))) а писать в резервную область для ZFS принципиально невозможно потому что туда нет прямой адресации. Месье должен четко понимать что SSD диски портятся от перезаписи а не от гранения станых неактуальных блоков.

>и срок работы флешки сократится в разы.

С точностью до наоборот.


> Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока -
> флешка выполняет копирование блока с изменением нужного куска.

Блок SSD и блок ZFS должны совпадать.

> Если во внутреннем
> блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет,
> только запись новых данных. Таким образом производительность без TRIM тоже под
> вопросом.

Смотреть выше.


Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

171. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 23-Сен-12, 12:08 
> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет

Перечитай написанное мной еще раз - ты ниасилил...

Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

191. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 16:56 
>> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет
> Перечитай написанное мной еще раз - ты ниасилил...

Зачем читать я на память помню :-) спецально для месье неасилившего мой предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных блоков перекладывается с контроллера ssd на zfs что при совпадении размера блока должно дать некоторый прирост производительности, так как контроллеру небудет необходипости считывать и сравнивать блок перед перезаписью.


Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

203. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 18:35 
> Зачем читать я на память помню :-) спецально для месье неасилившего мой

Чукча не читатель?

> предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных
> блоков перекладывается с контроллера ssd на zfs что при совпадении размера

Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести он себя будет вполне обычным образом - используя под веаринг резерв.

Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

230. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 20:28 
> Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести
> он себя будет вполне обычным образом - используя под веаринг резерв.

Как же туго с логикой. Вот если на SSD все блоки уже заняты и идет запись занятого блока SSD сделает запись в запасной или с тот который уже занят ?


Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

233. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:33 
> Как же туго с логикой. Вот если на SSD все блоки уже
> заняты и идет запись занятого блока SSD сделает запись в запасной
> или с тот который уже занят ?

В свободный.
Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". Бывает ситуация "все блоки заполнены, включая резервные, но часть подлежит стиранию".
В последней ситуации в довесок еще и GC запустится, и вот тут производительности настанет самый что ни на есть пушной зверёк.

Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

262. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 22:27 
>> Как же туго с логикой. Вот если на SSD все блоки уже
>> заняты и идет запись занятого блока SSD сделает запись в запасной
>> или с тот который уже занят ?
> В свободный.

Как же туго с логикой 2.

> Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты".

LOL

> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию".

Если ОС может адресовать только видимые ей то как могут быть заполнены резервные ? :-))

> В последней ситуации в довесок еще и GC запустится, и вот тут
> производительности настанет самый что ни на есть пушной зверёк.

Ну хоть один реальный тест это подтверждающий.

Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

273. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 23:28 
> Как же туго с логикой 2.
>> Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты".
> LOL

Да, LOL. Полнейшее, лютое, вопиющее незнание логики работы накопителей на флеше детектед.
Сюда хоть загляни, что-ли, для начального ликбеза:
http://en.wikipedia.org/wiki/Write_amplification

>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию".
> Если ОС может адресовать только видимые ей то как могут быть заполнены
> резервные ? :-))

ОС не имеет отношения к тому, что происходит непосредственно на флеше. Она пинает контроллер, не более. И совершенно не в курсе внутренней структуры флеша.

>> В последней ситуации в довесок еще и GC запустится, и вот тут
>> производительности настанет самый что ни на есть пушной зверёк.
> Ну хоть один реальный тест это подтверждающий.

http://www.xbitlabs.com/articles/storage/display/kigston-hyp...

Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

279. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 23:36 
>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию".
>> Если ОС может адресовать только видимые ей то как могут быть заполнены
>> резервные ? :-))

Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло - оно фоновое, только по событию GC.

Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

283. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 00:00 
>>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию".
>>> Если ОС может адресовать только видимые ей то как могут быть заполнены
>>> резервные ? :-))
> Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло -
> оно фоновое, только по событию GC.

И что device timeout ? Бред.

Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

286. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 00:07 
> И что device timeout ? Бред.

При чем тут device timeout? Нет, всего лишь задержка в несколько МС на стирание. Заметная, но не фатальная.


Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

334. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 21:24 
> При чем тут device timeout? Нет, всего лишь задержка в несколько МС
> на стирание. Заметная, но не фатальная.

Пипец, хардкорные разработчики бсды должны сгореть со стыдухи за своих "коллег". С такими друзьями никаких врагов не надо.

Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

251. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 21:05 
> Перечитай написанное мной еще раз - ты ниасилил...

Он вообще какой-то деревянный. Еще один изен прямо.

Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

169. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 11:45 
>> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам
>> что вы понимаете под TRIM а то мало ли вдруг и
>> тут что то левое :-))
> Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные,
> когда они освобождаются в ФС. Зачем это надо? Затем, что внутри
> флешки есть механизм веарлевелинга (по сути тот же CoW), который использует
> под новые данные незанятые блоки. Но вот - увы и ах
> - флешка ничего не знает про файловую систему. Чтобы сказать ей,
> что блок свободен - нужен TRIM.

Ой, а что же будет, если размер блока ФС случайно или по незнанию пользователя совпадает с размером блока SSD или в целое число раз больше размера блока SSD?

> И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с
> CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке
> не останется ничего другого, кроме как использовать под веарлевелинг при любой
> записи небольшой "временный набор" - резерв пространства как раз для этих
> целей. По мере заполнения "надлежащей" файловой системы запись все чаще и
> чаще будет перезаписью, и срок работы флешки сократится в разы.

В Wiki про TRIM написано, что "Так как очистка ячеек в странице необходима перед тем, как в них можно будет записывать снова, но только целый блок может быть очищен, процесс перезаписи инициирует цикл чтение-очистка-модификация-запись: содержимое целого блока должно быть сохранено в кеше перед тем, как оно может быть удалено с накопителя, перезаписываемые данные модифицируются в кеше и только после этого целый блок (с обновленной страницей) записывается на накопитель. Это явление известно как усиление записи.". Никакого "резерва пространства" в SSD нет.

> Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока -
> флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем
> блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет,
> только запись новых данных. Таким образом производительность без TRIM тоже под
> вопросом.

В кэш SSD помещаются данные из целого блока (SSD), так что применимость или не применимость TRIM тут никакой роли не играет — "усиление записи" для используемых страниц (так как в традиционных ФС размер блока много меньше размера блока SSD, то они будут) всё равно произойдёт.

Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

173. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 12:13 
> Ой, а что же будет, если размер блока ФС случайно или по
> незнанию пользователя совпадает с размером блока SSD или в целое число
> раз больше размера блока SSD?

Ничего не будет. Флешка как не знала о том, что блок логически высвобожден, так и не узнает. И не будет использовать данный блок для левелинга.

> В Wiki про TRIM написано, что "Так как очистка ячеек в странице

На заборе тоже много чего написано.

Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, до того, как он понадобится системе. Стирание - не ахти какая быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно ниже традиционок - эти FS не очищают блоки, и каждая перезапись на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает ли это BTRFS - не знаю.


> В кэш SSD помещаются данные из целого блока (SSD), так что применимость
> или не применимость TRIM тут никакой роли не играет

Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного.


Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

179. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от iZEN (ok) on 23-Сен-12, 12:33 
>> Ой, а что же будет, если размер блока ФС случайно или по
>> незнанию пользователя совпадает с размером блока SSD или в целое число
>> раз больше размера блока SSD?
> Ничего не будет. Флешка как не знала о том, что блок логически
> высвобожден, так и не узнает. И не будет использовать данный блок
> для левелинга.

Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой CoW ФС.

>> В Wiki про TRIM написано, что "Так как очистка ячеек в странице
> На заборе тоже много чего написано.

Так сотри и напиши правильно. Кто мешает?

> Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее,
> до того, как он понадобится системе. Стирание - не ахти какая
> быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно
> ниже традиционок - эти FS не очищают блоки, и каждая перезапись
> на них будет инициировать стирание.

Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков совпадают) страниц блока SSD, новые данные будут записываться после обнуления предыдущего содержимого. А в традиционных ФС вместо предварительного стирания страниц (они уже ранее обнулены GC после команды TRIM) будет происходить "усиление записи" немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD), что равносильно искусственному изнашиванию ячеек флэш-памяти.

Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт дополнительной операции по обнулению блока SSD.
За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц под блок ФС было выполнено на аппаратном уровне после команды TRIM, однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший по размеру блок ФС, приводит к износу ячеек памяти.

>> В кэш SSD помещаются данные из целого блока (SSD), так что применимость
>> или не применимость TRIM тут никакой роли не играет
> Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного.

Wiki/TRIM


Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

208. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 18:45 
> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой
> CoW ФС.

Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь там контроллера. Но проблема не в том. Проблема в том что контроллер - есть. И он не знает какие блоки используются. Поэтому вынужден очищать блоки только когда туда пытаются писать по факту. А не заранее. И вот это является очень неоптимальным режимом работы. И места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать операции записи, и запись медленнее происходит.

> Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков
> совпадают) страниц блока SSD,

И вот это - плохо. Потому что операция стирания - медленная и деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и деструктивнее чем конкуренты из-за неподдержки TRIM.

> новые данные будут записываться после обнуления предыдущего содержимого.
> А в традиционных ФС вместо предварительного стирания страниц (они уже
> ранее обнулены GC после команды TRIM) будет происходить "усиление записи"

Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с поддержкой trim запись будет просто записью страниц без нужды что-то там стирать и перетрясать.

> немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD),
> что равносильно искусственному изнашиванию ячеек флэш-памяти.

"Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав контроллер SSD в наихучший режим работы из всех возможных. По поводу чего оно будет тормознее работать и сильнее протирать флеш. Erase как раз весьма деструктивная операция. А т.к. пространства для маневра у GC контроллера будет минимум, erase будет делаться постоянно, по поводу и без.

> Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных
> (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт
> дополнительной операции по обнулению блока SSD.

Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки. А у btrfs вполне себе реализован trim. Вот в таком виде подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера SSD не мешает.

> За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц
> под блок ФС было выполнено на аппаратном уровне после команды TRIM,

На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок.

> однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший
> по размеру блок ФС, приводит к износу ячеек памяти.

Больше всего изнашивает память erase как раз. Да еще для довольно большого региона сразу, в отличие от записей страниц.

> Wiki/TRIM

Там нет спецификаций касающихся логики работы конкретных контроллеров.

Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

209. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 18:50 
> И вот это - плохо. Потому что операция стирания - медленная и
> деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и
> деструктивнее чем конкуренты из-за неподдержки TRIM.
> "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав
> контроллер SSD в наихучший режим работы из всех возможных. По поводу
> чего оно будет тормознее работать и сильнее протирать флеш. Erase как
> раз весьма деструктивная операция. А т.к. пространства для маневра у GC
> контроллера будет минимум, erase будет делаться постоянно, по поводу и без.

Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще приходится делать ERASE - тем хуже флешу.

Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

335. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 21:32 
> Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще
> приходится делать ERASE - тем хуже флешу.

Я не понимаю почему они в такое не въезжают. Тупые какие-то - не могут массивы блоков представить и что произойдет в такой или эдакой ситуации.

Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

222. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 20:05 
>> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой
>> CoW ФС.
> Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь
> там контроллера. Но проблема не в том. Проблема в том что
> контроллер - есть. И он не знает какие блоки используются. Поэтому
> вынужден очищать блоки только когда туда пытаются писать по факту. А
> не заранее. И вот это является очень неоптимальным режимом работы.

Откуда ты знаешь? Без TRIM контроллер не запускает механизм очистки, а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди обнуления/записи контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру блока SSD).

> И
> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать
> операции записи, и запись медленнее происходит.

Вывод из посылки, которая не верна.

>> Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков
>> совпадают) страниц блока SSD,
> И вот это - плохо. Потому что операция стирания - медленная и
> деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и
> деструктивнее чем конкуренты из-за неподдержки TRIM.

Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, но из-за малого размера блока ФС, содержимое блока SSD каждый раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, но так же И делается "усиление записи" для всех остальных страниц блока SSD, не участвующие в хранении данных записываемого блока ФС.

Контроллер SSD записывает данные на флэш только поблочно, при этом используется оперативный кэш для заполнения вновь затребованных страниц и освежения немодифицируемых страниц. Это способствует большему износу ячеек памяти, чем если бы блок ФС совпадал с размером блока SSD.

Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Ресурс флэш тратиться на освежение, которого можно избежать в принципе — сделать размер блока ФС равным размеру блока SSD.

>> новые данные будут записываться после обнуления предыдущего содержимого.
>> А в традиционных ФС вместо предварительного стирания страниц (они уже
>> ранее обнулены GC после команды TRIM) будет происходить "усиление записи"
> Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с
> поддержкой trim запись будет просто записью страниц без нужды что-то там
> стирать и перетрясать.

Контроллер SSD по команде ФС записывает данные на флэш только поблочно, при этом имеются в виду не блоки ФС (хотя и они тоже в этом процессе участвуют), а более объёмная по отношению к ФС величина — блок SSD, имеющий размер 512 килобайт.
Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть очищенные страницы в блоке, то их не нужно предварительно обнулять (это сделал GC после команды TRIM), скорость записи на них высока. Однако в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает данные на флэш только целым блоком из оперативного кэша. Это называется "усилением записи".

> "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав
> контроллер SSD в наихучший режим работы из всех возможных.

Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как не тайна за семью печатями.

> По поводу
> чего оно будет тормознее работать и сильнее протирать флеш. Erase как
> раз весьма деструктивная операция. А т.к. пространства для маневра у GC
> контроллера будет минимум, erase будет делаться постоянно, по поводу и без.

GC работает с отдельными страницами. И тут никак не влияет на скорость поблочной (пере)записи данных, так как за один раз стирается и модифицируется весь блок SSD — мы говорим для условия, когда размеры блоков ФС и SSD совпадают. Когда же размеры блоков ФС и SSD не совпадают, то тут начинается интересная штука: при интенсивных операциях записи-стирания данных GC может и не успеть обнулить помеченные TRIM страницы, поэтому новая запись в них будет происходить с ПРЕДВАРИТЕЛЬНЫМ обнулением содержимого непосредственно перед модификацией. И мы тут сильно потеряем в скорости записи на мелких блоках ФС, так как будет постоянная перезагрузка оперативного кэша SSD для модификации его блоков. В случае с совпадением размеров блоков операция очистки производится для всего блока SSD сразу, данные записываются большими порциями — нет оверхеда на подчистку отдельных страниц.

>> Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных
>> (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт
>> дополнительной операции по обнулению блока SSD.
> Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки.
> А у btrfs вполне себе реализован trim. Вот в таком виде
> подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера
> SSD не мешает.

Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. ;) Выяснится, что GC может и не успевает за подчистками. Заодно и проверить ресурс флэшатины под обеими ФС. ;)

>> За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц
>> под блок ФС было выполнено на аппаратном уровне после команды TRIM,
> На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы
> блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок.

Ты действительно веришь, что GC после своей работы с блоком разделяет блок на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки SSD и складирует их куда-то? Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)

Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

225. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:24 
> контроллеру не нужно. Запись ФС будет происходить без задержек кроме той,
> что нужна на полную очистку блока (принимаем, что размер блока ФС

О боже. В этом и проблема. Очистка блока по меркам CPU/шины - операция длиною в вечность. Ее лучше делать в фоне, не заставляя шину ждать. А писать в свободные блоки левелера.

Я тебе секрет открою, так и быть - современный контроллер всё равно не будет стирать целевой блок, запишет в свободный блок "резерва". Поэтому даже потерю производительности заметишь не всегда. Но вот блоков этих мало, и веаринг драйва в итоге будет неоптимальным. Совсем-совсем.

> Контроллер SSD записывает данные на флэш только поблочно

Бред. Поблочно производится только очистка. Запись может идти постранично.

> Контроллер SSD по команде ФС записывает данные на флэш только поблочно

Чушь. См. выше.

> величина — блок SSD, имеющий размер 512 килобайт.

На практике - от 64Кб до 2Мб в зависимости от организации флеша. Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем.

> Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть

Еще раз: никакой модификации данных не происходит. Данные пишутся в один из "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание.

> Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает

Это происходит только в моменты работы GC.

> Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как
> не тайна за семью печатями.

Это делает сам контроллер. Все попытки навязать ему сверху какое-либо распределение приведут только к быстрому занятию всех активных блоков рабочего набора. А без TRIM - еще и к тому, что контроллер будет вынужден всегда веарить за счёт резерва.

> для модификации его блоков. В случае с совпадением размеров блоков операция
> очистки производится для всего блока SSD сразу, данные записываются большими порциями
> — нет оверхеда на подчистку отдельных страниц.

Только в случае, если есть полностью свободный блок. А учитывая, что TRIM у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, и на каждую запись будем получать ERASE. Малый размер блока даже несколько более выгоден в случае SSD, поскольку позволяет не делать ERASE на запись 1 байта, если в наличии есть свободная страница. В идеале блок должен быть именно размером со страницу, чтобы не выполнять копирования, и не стирать целые блоки при записи мелких файлов.

> Ты действительно веришь, что GC после своей работы с блоком разделяет блок
> на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки
> SSD и складирует их куда-то?

Именно так он и работает. Читай публикации по веарлевелингу флешей. Работа GC чем-то сходна с классическими дефрагментаторами. Для перекомпоновки, к слову, достаточно всего лишь одного резервного блока. Но левелинг при этом будет никакой, естественно, поэтому на "резерв" реально берется обычно 5-10% от объёма флеша.

Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

300. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 06:39 
> и веаринг драйва в итоге будет неоптимальным. Совсем-совсем.

...
> Бред. Поблочно производится только очистка. Запись может идти постранично.

Два чая этому гражданину.

>> величина — блок SSD, имеющий размер 512 килобайт.
> На практике - от 64Кб до 2Мб в зависимости от организации флеша.

Ну это же изен. Я думаю что даташиты на микросхемы флеша он вообще никогда не читал.

> Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую"
> продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем.

Собственно 512Кб достаточно типовой размер нынче. Но в целом это на усмотрение производителя чипов, так что чего ради изен к 512К привязался... как будто он еще и выровнять сможет на границу блока :)

> "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный
> момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание.

Ну вот это и будет модификацией. Только от этого SSD пытается уйти но без TRIM не особо получится.

> только к быстрому занятию всех активных блоков рабочего набора. А без
> TRIM - еще и к тому, что контроллер будет вынужден всегда
> веарить за счёт резерва.

А до изена это не доходит. Он видимо все-таки прочел как работает флеш память, но garbage collector + размазка записей кажется уже за пределами его понимания.

> Только в случае, если есть полностью свободный блок. А учитывая, что TRIM
> у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет,
> и на каждую запись будем получать ERASE.

Вот именно. А изен почему-то этого не понимает. Ха-ха.

> Малый размер блока даже несколько более выгоден в случае SSD, поскольку
> позволяет не делать ERASE на запись 1 байта, если в наличии
> есть свободная страница.

Без trim чревато тем что постепенно все зафрагментируется и свалится в режим когда для записи 1 байта надо тереть erase block. А с trim - ну да, вполне нормально будет.

> В идеале блок должен быть именно размером со страницу,

...и совпадать с ее границами :)

> Именно так он и работает. Читай публикации по веарлевелингу флешей.

Да это ж изен, для него нормально бред нести. Хотя как ни странно он начинает немного понимать как флеш работает в плане устройства по блокам. Глядишь, лет через 10 начнет понимать и работу wear leveling :)

Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

297. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от Аноним (??) on 24-Сен-12, 06:15 
> Откуда ты знаешь?

Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. Ну вот такое у меня хобби есть. Это как раз примерно то самое что в SSD нынче суют.

> Без TRIM контроллер не запускает механизм очистки,

Спасибо, Кэп.

> а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС
> и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди
> обнуления/записи контроллеру не нужно.

Ты такой умный что пипец. Правда при всем этом ты не знаешь что то что именно сделает контроллер по поводу TRIM - вообще не специфицировано. То-есть, это всего лишь хинт контроллеру что мы не юзаем данные блоки и их можно разгрести. Когда именно и как контроллер это изволит разгрести и что он сделает по этому поводу - вообще его дело. Он может например подождать минимальной нагрузки на накопитель в фоне разрулить.

> Запись ФС будет происходить без задержек кроме той,
> что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру
> блока SSD).

Опух? Erase block флеша как правило нынче 512Кб и поди еще попробуй угадать границы оного, да еще с блоками переменного размера которыми ты тут так понтуешься. И кстати erase - это весьма длительная операция. Если программирование страницы может быть довольно быстрой процедурой (и то не всегда), то erase блока запросто растягиватеся на многие миллисекунды. Максимальное время обычно указано в даташите на микросхемы флеша.

>> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать
>> операции записи, и запись медленнее происходит.
> Вывод из посылки, которая не верна.

Вполне себе верна. Чем больше пространства для маневра - тем реже приходится судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. Собственно грубый прототип того что получается ты и так увидел на забитом под завязку томе. А тут похожая логика: размазывание записи - по сути вариант CoW получается. Ну и общие свойства стало быть похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его не видно в емкости накопителя которая написана на упаковке, а вот место в чипах памяти оно жрет. Производителю не нравится напаивать больше памяти при том что цифра на упаковке не увеличивается. Ведь хомячки покупают гигабайты :)

> Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется,

В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. Тогда стирания не будет, только программирование страниц. И чем больше места не занято - тем больше пространства для маневра: может получиться воткнуть желаемую запись куда-то в уже очищенные страницы. А если trim нет то постепенно все придет к схеме когда "проблема решается по мере возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а что нет. По поводу чего и скорость записи просядет, и возможности оптимизации размещения записей у контроллера будут откушены по полной программе.

Хинт: если бы все было так как ты говоришь, никто не стал бы геморроиться с реализацией команды TRIM от которой и так нет эффекта. По-моему, это даже детсадовцу понятно? :)

> но из-за малого размера блока ФС, содержимое блока SSD каждый
> раз помещается в кэш SSD, делается запись в заранее обнуленные страницы,
> но так же И делается "усиление записи" для всех остальных страниц
> блока SSD, не участвующие в хранении данных записываемого блока ФС.

Еще раз: что такое "усиление записи"? Нельзя ли выражаться общепризнанными терминами? Ну там read, erase, page programming, ... ?

> Контроллер SSD записывает данные на флэш только поблочно,

В общем случае - постранично. У флеша 2 вида блоков.

> способствует большему износу ячеек памяти, чем если бы блок ФС совпадал
> с размером блока SSD.

Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - часто будет тереться ДВА блока там где хватило бы одного. Ну а с блоками переменного размера ты еще и никогда не сможешь выровнять ФС так чтобы ее блоки совпали с блоками флеша. Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. В случае с TRIM это не такая уж проблема, т.к. erase не будет и будет только программирование страниц по количеству записываемого. А вот без него логика контроллера свалится в черти-какой штопор. Грубый прикидон мне подсказывает что экстенты + trim будут работать не в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы и по объему желаемой записи и ... все :). Юзание TRIM порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий вообще каждый раз.

> Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных
> ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек.

Ресурс ячеек прежде всего уменьшается от ERASE'а блоков на каждый пук. А если пространства для маневрирования и удовлетворения текущего запроса нет - поневоле придется дергаться и тереть блоки на каждый пук. Правда просто?

> TRIM тут никаким боком не поможет, кроме как увеличит скорость записи.

Он даст больше пространства для маневра: может получиться оформить операцию записи как только программирование страниц. Без стирания вообще. Откуда и рост скорости. И меньшая деструктивность процесса в среднем. Грубо говоря, повышается КПД логики SSDшного контроллера.

> Ресурс флэш тратиться на освежение, которого можно избежать в принципе —
> сделать размер блока ФС равным размеру блока SSD.

Ну да, ну да, и угадать размещение блока ФС чтобы не попало на границы блоков флеша, когда будет на ровном месте тереться 2 блока вместо 1 просто потому что блок ФС угораздило же лежать в обоих. А блоки переменного размера окончательно испортят компот, сделав это начинание невозможным. Не говоря о том что тратить блок 512Кб на файлик в 1Кб размером будет достаточно обидно.

> Контроллер SSD по команде ФС записывает данные на флэш только поблочно,

Минимальной единицой записи в флеш является страница. Есть более крупные блоки - группы страниц, стирание в 0 происходит только большими группами. Ты о каких из блоков?

> при этом имеются в виду не блоки ФС (хотя и они тоже
> в этом процессе участвуют), а более объёмная по отношению к ФС
> величина — блок SSD, имеющий размер 512 килобайт.

Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с 512-Кб блоками так чтобы они совпали с секторами флеша - ты, натурально, выиграешь по скорости записи. Практически - флаг тебе в руки это сделать в ZFS с ее блоками переменного размера и смотри не удавись от жабы когда файл 1 Кб начнет жрать 512Кб блок, если это вдруг получится.

> Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть
> очищенные страницы в блоке, то их не нужно предварительно обнулять (это
> сделал GC после команды TRIM), скорость записи на них высока. Однако
> в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются.
> Но они тоже будут перезаписаны (освежены),

Проблема в том что ты вроде бы начинаешь вкуривать что такое read-modify-write, но совершенно забыл про wear leveling. Который в общем случае постарается сделать запись в другое место флеша чтобы размазать запись. И вот тут возможны варианты. В случае когда юзается TRIM - есть свобода маневра и можно просто оформить это как программирование страниц. А вот если trim нет - с чистыми блоками небогато. И вот тут придется разгребать хлам по полной. Попав на дополнительные процедуры read-modify-write и erase "просто потому что это надо хоть куда-то записать, черт возьми". А когда нет того что хотелось - придется лепить из того что есть и распихивать ну хоть как-то. Как оптимально - всем понятно. Поэтому собственно и сделали trim ;)

> так как контроллер SSD записывает данные на флэш только целым блоком
> из оперативного кэша. Это называется "усилением записи".

А я думал что это называется read-modify-write.

> Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как
> не тайна за семью печатями.

С одной стороны, прикольно что до изена стало доползать как выравнивать фс на блоки флеша. С другой - я бы посмотрел как ты ZFS на блок флеша выровняешь :D.

> GC работает с отдельными страницами.

Логично - он расчищает блоки чтобы можно было их erase'нуть без потери данных, перегруппируя страницы в другие блоки, сдвигая их так что они без "прорех" из неактуальных данных. Вот только у этой логики отбирается вся свобода маневра когда trim нет. По поводу чего оно натужно дергается в попытках выкроить свободные блоки "ну хоть как нибудь" а не разрулить запрос "как оптимальнее". Trim это основательно лечит.

> весь блок SSD — мы говорим для условия, когда размеры блоков
> ФС и SSD совпадают.

Кроме размера должны еще и границы блоков совпасть. А вот это уже не самое простое требование. А с блоками переменного размера - ну ты понял, да? :)

> для модификации его блоков. В случае с совпадением размеров блоков операция
> очистки производится для всего блока SSD сразу, данные записываются большими порциями
> — нет оверхеда на подчистку отдельных страниц.

Если забить на часть бреда, вот этот кусок даже в принципе верен. Вот только это весьма идеализированный случай. И маловероятно что ты нечто такое на ZFS вообще сможешь изобразить.

> Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных.
> ;) Выяснится, что GC может и не успевает за подчистками.

В клиническом случае может и не успеть. Вот только в этом случае SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс не больно огромный, порядка нескольких тысяч циклов всего. Так что (в идеальном случае) несколько тысяч записей объемом с накопитель и усе, он начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям.

>  Заодно и проверить ресурс флэшатины под обеими ФС. ;)

В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора менять SSD" :). А в менее суровых случаях имхо ФС с trim выиграют.

> Ты действительно веришь, что GC после своей работы с блоком разделяет блок
> на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки
> SSD и складирует их куда-то?

Естественно, на то и GC. Иначе он мог бы нарваться на тупые и смешные ситуации например когда в каждом блоке засрано по странице. Так что полную страницу записать уже нельзя. Вроде бы места дофига а записывать некуа. И чего?

> Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой
> перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)

Ну нифига себе у тебя технологии, если запись о трансляции блока занимает столько же сколько сам блок.

Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

309. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 07:35 
> Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает.
> Ну вот такое у меня хобби есть. Это как раз примерно
> то самое что в SSD нынче суют.

О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов.

> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет
> с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь -
> часто будет тереться ДВА блока там где хватило бы одного.

Absolutely.

А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы записи одной страницы. Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц.

Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

316. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 11:28 
> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы
> записи одной страницы. Пример - перезапись 1 байта в файле :)

Вот для этого существует дедуплекация.

> Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS
> - в любом случае получим запись целых блоков вместо страниц.

Если там будет контроллер SF2*** там все будет свсем не так как вы думаете :-)))


Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

320. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 12:19 
>> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы
>> записи одной страницы. Пример - перезапись 1 байта в файле :)
> Вот для этого существует дедуплекация.

При чем тут дедупликация, вообще?

>> Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS
>> - в любом случае получим запись целых блоков вместо страниц.
> Если там будет контроллер SF2*** там все будет свсем не так как
> вы думаете :-)))

А если бы еще и во рту грибы росли...

Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

321. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 24-Сен-12, 12:23 
> А если бы еще и во рту грибы росли...

Месье поял насколько он неправ ? Ну не расстраивайтесь так из-за ерунды. Вот позитивная статья http://b-a-t.livejournal.com/210090.html для поднятия настроения ... особенно каменты :-)))

Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

322. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 12:24 
>> А если бы еще и во рту грибы росли...

Пойми - ошибка конкретной фирмвари конкретного контроллера будет исправлена, если она есть.
Да и мнение одного хомячка не определяет.

Ответить | Правка | ^ к родителю #321 | Наверх | Cообщить модератору

341. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 22:37 
> О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на
> Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов.

Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в некоторых блоках не нравилось, они перекрыли запись ряда интересных блоков через свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые шлются в девайс, инициализируют железо, детектируют тип флеща и его набор команд (intel, AMD) ну и делают чтение, стирание и запись (по сути некий эквивалент олдскульных программ-мониторов, только ремотненько, по UART-у). А кроме всего прочего был расковырян формат области EEPROM в флеше, оказавшийся простой флешовой файловой системой. С простой формой wear leveling и номерами блоков вместо названий файлов. Для наиболее интересных из них был отбабахан действующий макет read-modify-write. Правда полноценный GC делать меня заломало, так что в сильно экзотических случаях оно в принципе могло обломаться. Впрочем, на практике это случалось только у особо крутых извращенцев долго мучавших зону EEPROM, таковых было очень мало и проблема не существовала. Отличная штука для понимания устройства флешовых систем: простенько но со вкусом и все основные элементы - на месте.

А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL который они уже тогда раздавали просто так. И я понял что большинство из логики работы этой штуки я уже где-то видел. В общем то вся эта механика у всех достаточно похожа по общей логике работы.

>> часто будет тереться ДВА блока там где хватило бы одного.
> Absolutely.

Ну я то представляю себе что получится. А вот nagual-ы и izen-ы очень врядли. Зато пальцы то погнуть хочется :)

> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы
> записи одной страницы.

Ну да. Одно дело если GC будет надрываться и пытаться выкроить место из того что есть под то что хотелось и другое если просто страницы распихали и готово :)

> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция.

Это почему? Оформляется выносок в сторону. Это достаточно быстро само по себе. Вот правда метаданных будет больше чем данных + фрагментация возрастет. Если все время глушить такие запросы - ФС деградирует разумеется, но это не есть типовой юзкейс. А ФС оптимизируют все-таки на более-менее типовые сценарии. То что всякими извращениями можно любую ФС на лопатки уложить - ни для кого не новость :)

> А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц.

ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку trim своим бредом. Смешные они, эти юные бсдшники :)

Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

343. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 22:51 
> Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в

Ох как, значит коллеги :)

> свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые
> шлются в девайс, инициализируют железо, детектируют тип флеща и его набор

Почти то же самое. Загрузчики только юзали самсунговские, но тоже реверсилась система команд, и прошивалка делалась, ага. SGHFD (SGH Flasher/Dumper, уже из области археологии ныне).

> А кроме всего прочего был расковырян формат области EEPROM в флеше,
> оказавшийся простой флешовой файловой системой. С простой формой wear leveling и
> номерами блоков вместо названий файлов.

У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера. Реверсинг X100 (TFS 3.03) доставил много веселых часов, потому что некоторые значения номеров блоков в левелере считались откровенно через задницу. А реверсинг E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен.

--- [из сохранившегося]
   POverEnd denotes the sector from which area after PStart + Remap Data
   Length + Remap Info Length continues (probably, but it can be relatively
   simply calculated without using this field).

   One more thing. If remap sectors come over filesystem length (as
   example mapping 23 sectors to 3C6 gets us to sector 3E8 which is
   just outbound of the data area, then it is wrapped to sector 0
   and further, so in our case 3E7 is 0 and 3E8 is really 1. Crap.
--- [из сохранившегося]

> Отличная штука для понимания устройства флешовых систем: простенько но со вкусом
> и все основные элементы - на месте.

+1

> А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL
> который они уже тогда раздавали просто так. И я понял что
> большинство из логики работы этой штуки я уже где-то видел. В
> общем то вся эта механика у всех достаточно похожа по общей
> логике работы.
>> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция.
> Это почему? Оформляется выносок в сторону.
> Вот правда метаданных будет больше чем данных.

ВотЪ. Приятно говорить с понимающим человеком :)

Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

397. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 21:08 
> Ох как, значит коллеги :)

Получается что так :)

> Почти то же самое. Загрузчики только юзали самсунговские,

А в этом случае свои были, сделанные на основе изучения сименсовских и штук от других граждан, etc. Сименсовские сильно ориентированы на флешинг апдейтов + у них протокол дурной: мелкие блоки. Заломало логику с окнами делать и прочая. Получилась штука простая как дубинка и с кучей упрощений. Но вполне работающая и в 10 раз меньше кода в бутлоадере + простой, понятный и неубиваемый протокол. Хоть и халтурка слегка (полная синхроншина, ни окон протокола, ни прерываний UART, которые поди еще найди в неизвестном проце).

> но тоже реверсилась система команд, и прошивалка делалась, ага.
> SGHFD (SGH Flasher/Dumper, уже из области археологии ныне).

Ну и сименсы х3х-х5х тоже археология уже. Ну а знания о том как делают флешовые ФС и свойства флеша и по сей день актуальны :). Кстати у английских википедиков вполне доходчиво описано на уровне устройства чипа флеша откуда берется столь странная механика.

>> номерами блоков вместо названий файлов.
> У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера.

А это немного смахивает на ранние версии JFFS, чтоли. По крайней мере трюк с допрограммированием уже программированных байтов без стирания блока за счет читерства с битиками там тоже был.

> E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен.

О как.

> --- [из сохранившегося]

О как, похоже на полноценный wear leveling. А немцы просто сгородили нечто типа флешовой ФС но попримитивнее. Потом они кстати похожий формат данных и для настоящей ФС заюзали. По сути ранний прототип flash file systems по типу JFFS получился.

>> Отличная штука для понимания устройства флешовых систем: простенько но со вкусом
>> и все основные элементы - на месте.
>>> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция.
>> Это почему? Оформляется выносок в сторону.
>> Вот правда метаданных будет больше чем данных.
> ВотЪ. Приятно говорить с понимающим человеком :)

Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту в природе мало. Только Шишкину не говорите, а то он разопрется как PoC отгрохать том состоящий почти целиком из метаданных и будет орать что это отстой :)

Ответить | Правка | ^ к родителю #343 | Наверх | Cообщить модератору

401. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 22:18 
> Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту
> в природе мало. Только Шишкину не говорите, а то он разопрется
> как PoC отгрохать том состоящий почти целиком из метаданных и будет
> орать что это отстой :)

LAWL :) +100500

Ответить | Правка | ^ к родителю #397 | Наверх | Cообщить модератору

348. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 23:44 
> ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку
> trim своим бредом. Смешные они, эти юные бсдшники :)

Ой ЧСВ пробило потолок :-))


Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

312. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 11:09 
> И кстати erase - это весьма длительная операция.

Как то раз один дурак ляпнул и теперь все заучили как молитву.
Это из раздела - переходные процессы длятся бесконечно долго :-)))
Без тестов больше эту херню тут не пишите.

>[оверквотинг удален]
> Вполне себе верна. Чем больше пространства для маневра - тем реже приходится
> судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции.
> Собственно грубый прототип того что получается ты и так увидел на
> забитом под завязку томе. А тут похожая логика: размазывание записи -
> по сути вариант CoW получается. Ну и общие свойства стало быть
> похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его
> не видно в емкости накопителя которая написана на упаковке, а вот
> место в чипах памяти оно жрет. Производителю не нравится напаивать больше
> памяти при том что цифра на упаковке не увеличивается. Ведь хомячки
> покупают гигабайты :)

Еще производитель старается подгадать срок эксплуотации под гарантийный ...

> В этом случае как раз контроллер имеет все шансы заранее сгрести мусор.
> Тогда стирания не будет, только программирование страниц. И чем больше места
> не занято - тем больше пространства для маневра: может получиться воткнуть
> желаемую запись куда-то в уже очищенные страницы. А если trim нет
> то постепенно все придет к схеме когда "проблема решается по мере
> возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок
> чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а
> что нет. По поводу чего и скорость записи просядет, и возможности
> оптимизации размещения записей у контроллера будут откушены по полной программе.

Многие люди суют ssd в рейды встроенные в матери, и большая половина этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так что ждать обновлений биоса как погоды у моря. И что многие жалуются на ужасное - ужасное падение производительности ? Кеп покажи как ты умеешь гуглить :-))

> Хинт: если бы все было так как ты говоришь, никто не стал
> бы геморроиться с реализацией команды TRIM от которой и так нет
> эффекта. По-моему, это даже детсадовцу понятно? :)

Трим маркетинговый ход на который есть патент :-)) или не ?

> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет
> с блоком SSD.

Месье не делал но знает ...
> Поэтому - да, ты очень хорошо подсказываешь -
> часто будет тереться ДВА блока там где хватило бы одного. Ну
> а с блоками переменного размера ты еще и никогда не сможешь
> выровнять ФС так чтобы ее блоки совпали с блоками флеша.

И все же это реально ...
> Так
> что многие блоки ФС попадут на пересечение блоков флеша. Вот ить
> незадача то. Тут вам и двукратный wear, и более тормозная запись
> лишний раз.

Так тестов никто и не привел ...
> В случае с TRIM это не такая уж проблема,
> т.к. erase не будет и будет только программирование страниц по количеству
> записываемого. А вот без него логика контроллера свалится в черти-какой штопор.
> Грубый прикидон мне подсказывает что экстенты + trim будут работать не
> в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы
> и по объему желаемой записи и ... все :). Юзание TRIM
> порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий
> вообще каждый раз.

Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ...


> Ну да, ну да, и угадать размещение блока ФС чтобы не попало
> на границы блоков флеша, когда будет на ровном месте тереться 2
> блока вместо 1 просто потому что блок ФС угораздило же лежать
> в обоих. А блоки переменного размера окончательно испортят компот, сделав это
> начинание невозможным. Не говоря о том что тратить блок 512Кб на
> файлик в 1Кб размером будет достаточно обидно.

А в других фс не обидно ...

> Минимальной единицой записи в флеш является страница. Есть более крупные блоки -
> группы страниц, стирание в 0 происходит только большими группами. Ты о
> каких из блоков?
> Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с
> 512-Кб блоками так чтобы они совпали с секторами флеша - ты,
> натурально, выиграешь по скорости записи. Практически - флаг тебе в руки
> это сделать в ZFS с ее блоками переменного размера и смотри
> не удавись от жабы когда файл 1 Кб начнет жрать 512Кб
> блок, если это вдруг получится.

А ьы хотели бд на zfs и там вообще 10 файлов максимум ...

> С одной стороны, прикольно что до изена стало доползать как выравнивать фс
> на блоки флеша. С другой - я бы посмотрел как ты
> ZFS на блок флеша выровняешь :D.

gnop create -S 4096 /dev/gpt/disk0
zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop
Это ?


> Кроме размера должны еще и границы блоков совпасть. А вот это уже
> не самое простое требование. А с блоками переменного размера - ну
> ты понял, да? :)

Так чтоли zfs set recordsize=128k tank/mysql/iblogs ?


> В клиническом случае может и не успеть. Вот только в этом случае
> SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс
> не больно огромный, порядка нескольких тысяч циклов всего. Так что (в
> идеальном случае) несколько тысяч записей объемом с накопитель и усе, он
> начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям.

Вот такое Г... просто ненужно покупать.


> В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора
> менять SSD" :). А в менее суровых случаях имхо ФС с
> trim выиграют.

У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-))
Как же там все темно http://habrahabr.ru/post/143659/ дословно:
Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает удалённую пользователем информацию своим особым образом и вообще хранит данные на диске в виде одного большого архива ...
Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет.


Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

318. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 12:17 
>> И кстати erase - это весьма длительная операция.
> Как то раз один дурак ляпнул и теперь все заучили как молитву.

http://www.datasheetcatalog.org/datasheet/SamsungElectronic/...
Страница 19, tBERS. Ситуация типовая для NAND.

> Это из раздела - переходные процессы длятся бесконечно долго :-)))
> Без тестов больше эту херню тут не пишите.

Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи.

> Многие люди суют ssd в рейды встроенные в матери, и большая половина
> этих рейдов ну разве кроме последних моделей понятия неимеет о триме.

Хомячки с локалхостами в контексте обсуждения мало интересны.

> Трим маркетинговый ход на который есть патент :-)) или не ?

TRIM - насущная необходимость для нормального левелинга флеша. Тчк.

> Сан юзает ссд диски под кеш zfs и знать незнает что использует

Сан уже от'юзался. Унылый такой мертвячок. А SSD под кеши юзаются в основном на аппаратных контроллерах, которые знают про TRIM.

> Вот такое Г... просто ненужно покупать.

Просто нужно нормально юзать флеш - так, как обусловлено техническими характеристиками, а не так, как левая задняя нога чешется.

Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

423. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 18:59 
> Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи.

При том даже на (английской) википедии доступно разжевано каког оно именно так.

> TRIM - насущная необходимость для нормального левелинга флеша. Тчк.

Сейчас будет фокус: как только его запилят в ZFS - они это резко осознают. Люблю все-таки лицемеров - кормят хорошо и лулзов генерят море :)

> основном на аппаратных контроллерах, которые знают про TRIM.

Еще есть категория граждан пытающихся затыкать технические прорехи маркетинговым буллшитом. Правда настолько явно лажаться - не прокатит, да и вообще, что-то не помог саням их маркетинг.

Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

344. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 23:38 
> Как то раз один дурак ляпнул и теперь все заучили как молитву.

Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы уж простите, сэр, но я почему-то полагаю что производитель чипов лучше знает свойства своих поделий чем какой-то там nagual. И они, вероятно, менее дураки, поскольку в отличие от вас они эти чипы и производят. По поводу чего должны знать их свойства. И если все производители пишут в датащитах примерно одно и то же, обобщаем и делаем вывод что это свойство "технологии вообще". ИЧСХ, это действительно свойство "технологии вообще".

> Это из раздела - переходные процессы длятся бесконечно долго :-)))
> Без тестов больше эту херню тут не пишите.

Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они ж крутые мачо. Умнее производителей чипаков :)

>> памяти при том что цифра на упаковке не увеличивается. Ведь хомячки
>> покупают гигабайты :)
> Еще производитель старается подгадать срок эксплуотации под гарантийный ...

В случае с SSD это не получится хотя-бы потому что производитель не властен над объемом записываемых данных. Да и репутация от отказов накопителей сильно страдает. Так что специально никто не пакостит. Просто издержки особенностей технологии помноженные на желание хомяков купить побольше гигазов и подешевле дают свой результат.

Все зависит от того насколько с умом подходить к делу. У меня например системный накопитель протерся на ~0.1% за полгода, судя по статистике SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает что если ничего не изменится, он еще доооооолго будет работать в таком режиме. Но во первых, я юзаю TRIM, во вторых я аккуратно оптимизнул и вынес все что делало не в меру активные записи на механику. В третьих я не забиваю накопитель на 99.9% т.к. сам себе не враг и не очень хочу дорогие SSD спускать пачками в трэш по своей глупости.

>> что нет. По поводу чего и скорость записи просядет, и возможности
>> оптимизации размещения записей у контроллера будут откушены по полной программе.
> Многие люди суют ssd в рейды встроенные в матери, и большая половина
> этих рейдов ну разве кроме последних моделей понятия неимеет о триме.

А я что, виноват что дуралеев на свете много? Хотя в том же линуксе такой RAID обычно рюхается чисто программно и от контроллера вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера. Вся поддержка со стороны мамки сводится аж к добавочному ROM для системного BIOS который умеет показывать несколько дисков как якобы один для DOS и начальных загрузчиков, так что они с этого могут начать грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых диска на контроллере. И уже сама из них изображает "RAID".

> Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так
> что ждать обновлений биоса как погоды у моря.

Лулз состоит в том что все современные операционки не используют в своей работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО делает кернель операционки. А вот незнание таких основ архитектуры современных операционок вам чести не делает. Так и запишем.

> И что многие жалуются на ужасное - ужасное падение производительности ?
> Кеп покажи как ты умеешь гуглить :-))

Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные.

>> эффекта. По-моему, это даже детсадовцу понятно? :)
> Трим маркетинговый ход на который есть патент :-)) или не ?

Прежде всего это фича призванная ускорить работу и замедлить протирание SSD. Потому что возвраты по гарантии никому не уперлись, а хомяк за новым SSD и так придет, когда выкатят в 2 раза более емкий и в 2 раза более быстрый, зря чтоли корпоративщики потребццтво прокачивали? Хомяку неизбежно захочется больше, да :)

>> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD.
> Месье не делал но знает ...

Мсье делал и как раз именно поэтому - знает. Да, это был не ZFS, но это не мешает прикинуть на основе имеющихся знаний как оно получится.

>> выровнять ФС так чтобы ее блоки совпали с блоками флеша.
> И все же это реально ...

Тогда ждем рецепт в студию с описанием технологии этого действа :). Я пока такое видел только для примитивных ФС и относительно примитивных флешек и SD карт. Там все проще. И блоки постоянного размера, и контроллеры потупее.

>> Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить
>> незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз.
> Так тестов никто и не привел ...

А какой смысл бисер метать? На тесты надо довольно много времени, так что если не попадется готовых очень кстати и нахаляву, я не буду такой объем работы воротить задаром для непойми кого. Особенно если он не знает что современные ОС BIOS'ом не пользуются в процессе работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер?

>> порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий
>> вообще каждый раз.
> Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ...

У сана вообще маркетинговый буллшит вместо технологий был в норме вещей, как я погляжу. Но такой расклад устраивает далеко не всех. Вот вы и кушайте маркетинговый шит, а я хорошие, интересные и полезные технологии предпочитаю.

> вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ...

Зато маркетологи с удовольствием втирали некомпетентному лошью маркетинговый буллщит про то как ZFS оптимизирован для SSD. Хотя инженеры саней пальца о палец для этого не ударили. Ну а что, доллары то не пахнут. Правда это не особо помогло и сани продались. Ну а оракл на этот маркетинговый шит уже забил. Благо ZFS для их БД не фонтан а больше им ничего и не надо. Тем более что клиентура все чаще желает линукс.

>> файлик в 1Кб размером будет достаточно обидно.
> А в других фс не обидно ...

Так никто в здравом уме и не юзает блоки ФС фиксированного размера в 512Кб если вы не заметили. Как по мне - достаточно выравнивать на размер страницы.

>> не удавись от жабы когда файл 1 Кб начнет жрать 512Кб
>> блок, если это вдруг получится.
> А ьы хотели бд на zfs и там вообще 10 файлов максимум ...

А с ней опа будет по другим поводам. Там логика журналирования БД подерется с природой работы ФС и будет двойная работа. CoW радостно закопирует и изменения в БД, и изменения в журнале. Многократное умножение работы - совершенно на ровном месте. Просто потому что два алгоритма не подружились между собой.

>> ZFS на блок флеша выровняешь :D.
> gnop create -S 4096 /dev/gpt/disk0
> zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop
> Это ?

Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного размера. Но может и спровоцировать выравнивание по страницам в лучшем случае, как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть в детали того как ZFS блоки переменного раскладывает.

>> не самое простое требование. А с блоками переменного размера - ну ты понял, да? :)
> Так чтоли zfs set recordsize=128k tank/mysql/iblogs ?

Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности устройства ZFS, блоков переменного размера и прочая, что я не взялся что-то гарантировать и даже прикинуть что будет если и смогу то сильно приблизительно.

Но в целом - вы как ни странно, верно уловили что ориентированные на выравнивание по блокам RAID или секторам дисков опции частично применимы и для SSD. Правда с оговорками. Проблема в том что истинную геометрию флешатины скрывает контроллер, у которого к тому же есть некая своя логика работы в фирмваре. По этому поводу честно вычислить параметры технически невозможно. Можно подобрать, сделав ряд экспериментов. Для более простых ФС и контроллеров это даже народом освоено слегка.

>> начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям.
> Вот такое Г... просто ненужно покупать.

Так другое особо и не производят. Хотя в принципе бывают SLC накопители иногда, но - стоят дофига, а объем мелкий. Что как-то не очень то и перевешивает бОльший срок службы и бОльшую скорость записи в большинстве случаев. Общество потребления, однако.

>> trim выиграют.
> У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-))

Мой системный SSD например судя по его SMART рискует сильно пережить и гарантию и вообще. А так - накопитель сдуру можно убить довольно быстро.

> Как же там все темно http://habrahabr.ru/post/143659/ дословно:
> Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется.
> Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает
> удалённую пользователем информацию своим особым образом и вообще хранит данные на
> диске в виде одного большого архива ...

А sandforce вообще странные штуки. Они жульничают с скоростями чтения-записи и прочая, делая скоростное сжатие данных. По поводу чего на нежмущихся данных скорость заметно меньше чем на жмущихся. Странные люди - маркетинг такой маркетинг. ZFSники с этого мало что выигрывают: если они хотели сжатие - оно в ZFS и так было. Да и в btrfs есть.

> Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет.

Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел - наслышан об оном.

Ответить | Правка | ^ к родителю #312 | Наверх | Cообщить модератору

359. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 00:11 
>> Как то раз один дурак ляпнул и теперь все заучили как молитву.
> Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы
> уж простите, сэр, но я почему-то полагаю что производитель чипов лучше
> знает свойства своих поделий чем какой-то там nagual.

Как правило инженеры которые делают и инженеры которые пишут это не одни и те же люди и вторые понимают первых очень плохо ... Кто может тот делает а кто неможет вот как вы других учит :-)))
> И они, вероятно,
> менее дураки, поскольку в отличие от вас они эти чипы и
> производят. По поводу чего должны знать их свойства. И если все
> производители пишут в датащитах примерно одно и то же

Да любят они копипастить друг у друга :-)) как же без этого.

>> Это из раздела - переходные процессы длятся бесконечно долго :-)))
>> Без тестов больше эту херню тут не пишите.
> Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих
> даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они
> ж крутые мачо. Умнее производителей чипаков :)

Так и запишем - месье писатель, тесты это слоржно ...

> Все зависит от того насколько с умом подходить к делу. У меня
> например системный накопитель протерся на ~0.1% за полгода, судя по статистике
> SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл
> перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает
> что если ничего не изменится, он еще доооооолго будет работать в
> таком режиме. Но во первых, я юзаю TRIM, во вторых я
> аккуратно оптимизнул и вынес все что делало не в меру активные
> записи на механику. В третьих я не забиваю накопитель на 99.9%
> т.к. сам себе не враг и не очень хочу дорогие SSD
> спускать пачками в трэш по своей глупости.

Если бы месье асилил статью на хабре он бы узнал что для половины ссд дисков трм включать не только не полезно но даже вредно :-))

> А я что, виноват что дуралеев на свете много? Хотя в том
> же линуксе такой RAID обычно рюхается чисто программно и от контроллера
> вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера.
> Вся поддержка со стороны мамки сводится аж к добавочному ROM для
> системного BIOS который умеет показывать несколько дисков как якобы один для
> DOS и начальных загрузчиков, так что они с этого могут начать
> грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых
> диска на контроллере. И уже сама из них изображает "RAID".

В двух словах люди использующие аппаратные рейды дуралеи ... Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ?

>> Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так
>> что ждать обновлений биоса как погоды у моря.
> Лулз состоит в том что все современные операционки не используют в своей
> работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО
> делает кернель операционки. А вот незнание таких основ архитектуры современных операционок
> вам чести не делает. Так и запишем.

Это делают драйвера ...

> Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше
> пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные.

Кеп неумеет гуглить ?

> Мсье делал и как раз именно поэтому - знает. Да, это был
> не ZFS, но это не мешает прикинуть на основе имеющихся знаний
> как оно получится.

На btrfs ext4 неудалось выровнять размер блока как в ссд а потому zfs гавно ... спасибо кеп ноу коментс.

> Тогда ждем рецепт в студию с описанием технологии этого действа :).

Кстати уже писалось если не асилите найти то медицина бессильна.

> А какой смысл бисер метать? На тесты надо довольно много времени, так
> что если не попадется готовых очень кстати и нахаляву, я не
> буду такой объем работы воротить задаром для непойми кого. Особенно если
> он не знает что современные ОС BIOS'ом не пользуются в процессе
> работы для доступа к контроллеру мамки. А смысл то надрывать попу,
> меча бисер?

Короче с тестами опять не судьба ...

> А с ней опа будет по другим поводам. Там логика журналирования БД
> подерется с природой работы ФС и будет двойная работа. CoW радостно
> закопирует и изменения в БД, и изменения в журнале. Многократное умножение
> работы - совершенно на ровном месте. Просто потому что два алгоритма
> не подружились между собой.

Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ?

> Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного
> размера. Но может и спровоцировать выравнивание по страницам в лучшем случае,
> как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть
> в детали того как ZFS блоки переменного раскладывает.

И тут тоже с тестами не судьба ...

> Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу
> с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности
> устройства ZFS, блоков переменного размера и прочая, что я не взялся
> что-то гарантировать и даже прикинуть что будет если и смогу то
> сильно приблизительно.

Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может...

> Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел
> - наслышан об оном.

Как это не печально но последние модели интела тоже на нем - кризис. И трим этим ссд нужен как в бане лыжи.


Ответить | Правка | ^ к родителю #344 | Наверх | Cообщить модератору

368. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 25-Сен-12, 07:32 
> Как правило инженеры которые делают и инженеры которые пишут это не одни
> и те же люди и вторые понимают первых очень плохо ...

И только nagual знает всё лучше вендоров. Вместе с братьями-акробатами на хабре.

> Если бы месье асилил статью на хабре он бы узнал что для

Я лучше по мануалам, чем по минному полю горе-экспериментаторов, не знающих теории.

> половины ссд дисков трм включать не только не полезно но даже вредно :-))

Интересно, чьё больное воображение на хабре родило сей опус? Чистой воды буллшит же.

> Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ?

Для СУБД? Да. Либо RAW, либо FS без каких-либо извращений.

> Как это не печально но последние модели интела тоже на нем -
> кризис. И трим этим ссд нужен как в бане лыжи.

Это только в ваших фантазиях, дарагой друх.

Ответить | Правка | ^ к родителю #359 | Наверх | Cообщить модератору

398. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 25-Сен-12, 21:33 
>> уж простите, сэр, но я почему-то полагаю что производитель чипов лучше
>> знает свойства своих поделий чем какой-то там nagual.
> Как правило инженеры которые делают и инженеры которые пишут это не одни
> и те же люди и вторые понимают первых очень плохо ...

Понимаете, как я написал выше, я когда-то делал специфичный софт и там был специфичный протокол. В силу небольшой халтурки с упрощением протокола, данный самопальный протоколец подклинивало между передачей блоков. В аккурат на время erase и program. По поводу чего я намного лучше вас представляю себе сколько какие процедуры касающиеся флеша занимают. Наверное потому что я же их и реализовывал и наслаждался результатом. Но вы в вашем праве полечить меня еще. Хотя я и разжирею с такого раскорма меня разными ламерами :)

> Кто может тот делает а кто неможет вот как вы других учит :-)))

Вообще-то я впполне себе реализовывал процедуры записи в флеш. По поводу чего и имею представление о том как это работает.

>> производители пишут в датащитах примерно одно и то же
> Да любят они копипастить друг у друга :-)) как же без этого.

А там нет копипасты. Это как правило более-менее честно меряется и/или приводятся worst cases соответствующие аппаратным таймаутам. Хотя удобно конечно думать что все дураки а вот вы умный. Ну, надизайньте чип и пустите в производство - тогда поверю.

>> ж крутые мачо. Умнее производителей чипаков :)
> Так и запишем - месье писатель, тесты это слоржно ...

Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье тому сколько времени они занимают, лол :)

>> т.к. сам себе не враг и не очень хочу дорогие SSD
>> спускать пачками в трэш по своей глупости.
> Если бы месье асилил статью на хабре

Это ваша прерогатива - осиливать статьи на хабрашвабре. Специально для таких как вы ресурс. Еще можете всяких Левашовых читать. Хотя лучше сразу уж не мелочиться и взять МК бульвар. Там намного интереснее материалец попадается.

> он бы узнал что для половины ссд дисков трм включать не только не полезно но даже
> вредно :-))

Для дисков с дефективной реализацией контроллера и/или его фирмвары - да. Вот только это дефект диска. По хорошему с такими багами - сразу в гарантийку и пусть чинят как хотят. Sandforce ранних выпусков вообще прославился лютыми багами типа внезапных умираний и прочих приколов.

> В двух словах люди использующие аппаратные рейды дуралеи ...

В двух словах, некоторые дуралеи не знают что на мамках в 99.9% случаев райды чисто софтварные.

> Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ?

Нет. А должен был?

>> вам чести не делает. Так и запишем.
> Это делают драйвера ...

Я догадывался. Но вы зачем-то вякнули про bios. Тем хуже для вас.

>> Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше
>> пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные.
> Кеп неумеет гуглить ?

Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до описания конструкции.

> На btrfs ext4 неудалось выровнять размер блока как в ссд а потому
> zfs гaвно ... спасибо кеп ноу коментс.

Улыбают меня эти бсдшники :). "Ну и что что с голой попой, все-равно BSD рулез!!!111" :)

>> Тогда ждем рецепт в студию с описанием технологии этого действа :).
> Кстати уже писалось если не асилите найти то медицина бессильна.

Процитируйте?

>> работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер?
> Короче с тестами опять не судьба ...

Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает. Ну или вы. Правда вам я доверяю меньше чем форониксу, увы.

>> работы - совершенно на ровном месте. Просто потому что два алгоритма
>> не подружились между собой.
> Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ?

А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если она совсем уж мешается. Правда забавно, да? :)

> И тут тоже с тестами не судьба ...

Затвердила сорока Якова одно про всякого :)

> Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может...

Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша. Ы?

>> Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел
>> - наслышан об оном.
> Как это не печально но последние модели интела тоже на нем - кризис.

А это уже новые модели где старые ляпы частично исправлены.

> И трим этим ссд нужен как в бане лыжи.

Сандфорсы вообще какие-то странные контроллеры. Но кроме них есть навалом других. Себе я бы ничего на сандфорсе покупать не стал.

Ответить | Правка | ^ к родителю #359 | Наверх | Cообщить модератору

402. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 25-Сен-12, 23:06 
> Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье
> тому сколько времени они занимают, лол :)

Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень. Это моразм ?

> В двух словах, некоторые дуралеи не знают что на мамках в 99.9%
> случаев райды чисто софтварные.

Спасибо кеп. Осень да ?

> Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор
> нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до
> описания конструкции.

https://www.google.com.ua/search?client=opera&rls=ru&q=%...

> Улыбают меня эти бсдшники :). "Ну и что что с голой попой,
> все-равно BSD рулез!!!111" :)

В лексекон настоящего линуксоида обязательно должны входить слова жопа и бсд :-))))

> Процитируйте?

zdb -U /var/tmp/zpool.cache |grep ashift
ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot
не ?

> Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает.
> Ну или вы. Правда вам я доверяю меньше чем форониксу, увы.

Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло претензий к тестам :-))

> А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если
> она совсем уж мешается. Правда забавно, да? :)

Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4 так же внезамно в kvm виснут виртуалки :-))

> Затвердила сорока Якова одно про всякого :)

А по существу ?

> Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша.
> Ы?

Это к чему ?


Ответить | Правка | ^ к родителю #398 | Наверх | Cообщить модератору

424. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 19:25 
> Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень.

Думаю что в данном случае мсье припомнил это кстати. Устройство флеша в целом мало изменилось за эти годы. Техпроцессы стали тоньше, контроллеры лучше. Но общие принципы работы никуда не делись и физика процесса вся та же. Поэтому знания мсье вполне актуальны. Вон соседний мсье не поленился даже адресно макнуть в даташит, где время стирания указано.

> Это моразм ?

Когда слово "маразм" не получается написать без ошибок - это он самый! Я гарантирую это.

> https://www.google.com.ua/search?client=opera&rls=ru&q=%...
> %D1%80%D0%BE%D0%B7&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest

Это бесплатный бонус к "моразму" для большей убедительности? Ну ладно, засчитано, тема "моразма" раскрыта :)

> В лексекон

Кроме "моразма" ничуть не менее былинно и когда слово "лексикон" не могут написать правильно. Парад деда моразма, не иначе :)

> ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot

Я так понимаю что сие нацелено на выравнивание по страницам. Что разумно и правильно. Но изен помнился хотел выравнивание на erase block. Мне не совсем понятно как это обеспечивается при блоках переменного размера или где в этой писанине отключение данной фичи.

> не ?

Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше вас знать вашу ФС чтоли?

> Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло
> претензий к тестам :-))

Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький HDD и SSD и на них ФС развернуть и помучать - это уже нечто годное. Но это много возни. Получить представление о том какие более-менее реалистичные тесты есть можно у того же фороникса. Правда они бенчат не все нагрузки, но это лучше чем ничего.

И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе чтобы вы понимали что такое погрешность измерений, например? Если уж вы бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках.

>> она совсем уж мешается. Правда забавно, да? :)
> Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4

Не знаю, у меня ничего не улетело за столько лет. Юзаю с 2.6.32 ядра. Все на месте. Хотя где-то в районе .35 редкий но меткий баг починили но его еще суметь надо огрести т.к. лезет только на очень больших файлах.

> так же внезамно в kvm виснут виртуалки :-))

Странно, а у меня они просто работают. Тем паче что бзды вообще не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения.

>> Затвердила сорока Якова одно про всякого :)
> А по существу ?

По существу, проведение бенчей в нормальном виде - достаточно долго и требует оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей - не настолько простая задача как это кажется. У них в общем то обычно есть нормальное описание конфига и какое-никакое описание методики, они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты.

>> Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша.Ы?
> Это к чему ?

К наездам на то что мсье теоретик. А вот и фиг, мсье практик. Просто даже небольшая практика требует большой теории.

Ответить | Правка | ^ к родителю #402 | Наверх | Cообщить модератору

429. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 26-Сен-12, 21:05 
> Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше
> вас знать вашу ФС чтоли?

Ну чтовы :-) вы просто неправильно поняли написанное :-))

> Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький
> HDD и SSD и на них ФС развернуть и помучать -
> это уже нечто годное.

Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и собственно работой логики фс месье настаивает ... это уже маразм.

> И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе
> чтобы вы понимали что такое погрешность измерений, например? Если уж вы
> бенчить что-то намерены. Фороникс и то в курсе и отмечают оную
> на графиках.

Ой мессье не смог вспомнить название теории Стьюдента.

> Странно, а у меня они просто работают. Тем паче что бзды вообще
> не умеют хостом для виртуалок быть и потому вообще выпадают из
> рассмотрения.

tcpdump на виртуалке запустите :-))

> По существу, проведение бенчей в нормальном виде - достаточно долго и требует
> оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей
> - не настолько простая задача как это кажется. У них в
> общем то обычно есть нормальное описание конфига и какое-никакое описание методики,
> они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты.

Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-))

> К наездам на то что мсье теоретик. А вот и фиг, мсье
> практик.

Ода мы уже заметили :-))


Ответить | Правка | ^ к родителю #424 | Наверх | Cообщить модератору

432. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 26-Сен-12, 21:46 
> Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и
> собственно работой логики фс месье настаивает ... это уже маразм.

Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я понимаю, что это далеко от идеологии BSD'шника, но всё же.

Ответить | Правка | ^ к родителю #429 | Наверх | Cообщить модератору

433. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 26-Сен-12, 23:14 
> Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я
> понимаю, что это далеко от идеологии BSD'шника, но всё же.

Это вы про тех самых инженеров которые немогут bc и count на пальцах показать ?


Ответить | Правка | ^ к родителю #432 | Наверх | Cообщить модератору

436. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 27-Сен-12, 17:30 
> Это вы про тех самых инженеров которые немогут bc и count на
> пальцах показать ?

bc - это вообще программа-калькулятор такая. А вы наверное про bs.

Ответить | Правка | ^ к родителю #433 | Наверх | Cообщить модератору

451. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 20:56 
> Ну чтовы :-) вы просто неправильно поняли написанное :-))

Наверное дело в том кто объясняет. Вот были бы вы супермозгом, типа резерфорда, вы бы и ядерную физику кухарке разжевали в 2 счета. А поскольку вы сами не понимаете что лопочете - отсюда и результат. Сложно объяснить окружающим свою мысль если сам не понимаешь или неправильно понимаешь что хотел сказать.

> Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и
> собственно работой логики фс месье настаивает ... это уже маразм.

Мсье настаивает на том что ZFS вообще не демонстрирует ничего сногсшибательного в бенчах. А в ряде бенчей испытывает откровенные проблемы.

>> бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках.
> Ой мессье не смог вспомнить название теории Стьюдента.

О, мсье даже помнит такие названия? Ну тогда может быть еще не все потеряно. Но учтите, мы тут бдим (не путать с "бздим").

>> не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения.
> tcpdump на виртуалке запустите :-))

Запустил. И чего? Вроде ничего необычного. Tcpdump, показывает трафф на интерфейсе. Вроде относительно честно.

> Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-))

А что, пробовали воспроизводить? Неужто вы нашли железо как у них? Это при том что вы 1 диск для тестов выкроить не можете? Как-то неубедительно.

>> К наездам на то что мсье теоретик. А вот и фиг, мсье практик.
> Ода мы уже заметили :-))

Кому ода? Ламерам? :)

Ответить | Правка | ^ к родителю #429 | Наверх | Cообщить модератору

245. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 20:44 
> Поэтому
> вынужден очищать блоки только когда туда пытаются писать по факту. А
> не заранее. И вот это является очень неоптимальным режимом работы.

Учитывая что все последующие инсинуации основаны всего на одном предположении извольте предоставить доставерные тесты.

Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

298. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 06:26 
> доставерные

ДостАверные тесты - это круто, да :)

Ответить | Правка | ^ к родителю #245 | Наверх | Cообщить модератору

192. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 23-Сен-12, 17:01 
> Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее,
> до того, как он понадобится системе. Стирание - не ахти какая
> быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно
> ниже традиционок - эти FS не очищают блоки, и каждая перезапись
> на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать
> "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает
> ли это BTRFS - не знаю.

Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ...
Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил.

Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

204. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 18:41 
> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ...
> Что то не припомню чоб на 100% заполненом SSD диске тест записи
> вдруг внезапно тормозил.

http://www.anandtech.com/show/2829/9
http://www.bit-tech.net/hardware/storage/2010/02/04/windows-...
Так, в качестве ликбеза.

Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

234. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 20:33 
>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ...
>> Что то не припомню чоб на 100% заполненом SSD диске тест записи
>> вдруг внезапно тормозил.
> http://www.anandtech.com/show/2829/9
> http://www.bit-tech.net/hardware/storage/2010/02/04/windows-...
> Так, в качестве ликбеза.

Очень порадовали результаты тестов по первой ссылке: одни производители SSD дали бабла писателям PCMark Vantage и там 0% а другие не дали и там аж 23%
Есть какие нибудь доставерные тесты где скорость меряется dd ?

Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

237. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:36 
> Есть какие нибудь доставерные тесты где скорость меряется dd ?

Есть. Самый достоверный тест - это произведенный собственными руками. Поэтому - прошу. К слову, результаты с теорией при правильном тестировании не разойдутся.

Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

299. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 06:29 
> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ...

Да любого - как будто, эта логика у всех сильно отличается. Детали реализации могут отличаться, а вот общий смысл - фиг.

> Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил.

Возможно выехал на резервных маневровых страницах. Но это прокатит только при сравнительно небольших записях и не всегда. Ну и просто статистику по wearing'у надо смотреть. У хороших накопителей она на редкость дотошная.

Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

313. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 24-Сен-12, 11:10 
>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ...
> Да любого - как будто, эта логика у всех сильно отличается. Детали
> реализации могут отличаться, а вот общий смысл - фиг.

Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-))

Ответить | Правка | ^ к родителю #299 | Наверх | Cообщить модератору

319. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 24-Сен-12, 12:18 
> Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-))

После скриншотика с гламурного макбука блеванул, и читать перестал.

Ответить | Правка | ^ к родителю #313 | Наверх | Cообщить модератору

201. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 17:58 
> Снова садись, снова два. Без TRIM они не то, что не друзья,
> а вообще не совместимы генетически.

А TRIM то там и нету. А в btrfs - опять же, есть. Ха.

Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

323. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 24-Сен-12, 19:45 
>>>> В этом плане ZFS с ее COW и SSD друзья
> Снова садись, снова два. Без TRIM они не то, что не друзья,
> а вообще не совместимы генетически.

Смотри-ка, что pjd вчера закоммитил в head: http://svnweb.freebsd.org/base?view=revision&revision=240868

//---
Author: pjd
Date: Sun Sep 23 19:40:58 2012 UTC (19 hours, 57 minutes ago)
Changed paths: 19
Log Message: Add TRIM support.

The code builds a map of regions that were freed. On every write the
code consults the map and eventually removes ranges that were freed
before, but are now overwritten.

Freed blocks are not TRIMed immediately. There is a tunable that defines
how many txg we should wait with TRIMming freed blocks (64 by default).

There is a low priority thread that TRIMs ranges when the time comes.
During TRIM we keep in-flight ranges on a list to detect colliding
writes - we have to delay writes that collide with in-flight TRIMs in
case something will be reordered and write will reached the disk before
the TRIM. We don't have to do the same for in-flight writes, as
colliding writes just remove ranges to TRIM.

Sponsored by:    multiplay.co.uk

This work includes some important fixes and some improvements obtained
from the zfsonlinux project, including TRIMming entire vdevs on pool
create/add/attach and on pool import for spare and cache vdevs.

Obtained from:    zfsonlinux
Submitted by:    Etienne Dechamps <etienne.dechamps@ovh.net>

---//

Тут мнение: http://forum.ixbt.com/topic.cgi?id=11:44215-55#1599

Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

403. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 13:39 
А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :)
Ответить | Правка | ^ к родителю #323 | Наверх | Cообщить модератору

404. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 26-Сен-12, 13:40 
> А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :)

Неизбежно.

Ответить | Правка | ^ к родителю #403 | Наверх | Cообщить модератору

425. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 19:26 
> Неизбежно.

Смешно будет смотреться когда им придется обсирать свою же предыдущую точку зрения :)

Ответить | Правка | ^ к родителю #404 | Наверх | Cообщить модератору

491. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 07:36 
> btrfs и SSD не совместимы ... В этом плане ZFS с
> ее COW и SSD друзья а так как ZFS позицианируется под

Без TRIM? Да, друзья. Примерно как волк зайцу.

> Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы

-o ssd при монтировании

Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

522. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 04-Окт-12, 10:12 

> А ничего что у всяких соляр и бздей на выбор полторы ФС,
> при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая -
> ископаемое с архитектурой каменноугольного периода UFS.

Интересно для кого вы пишите этот бред ? Вот теореме Пифагора более 2000 лет и никто ничего нового не придумал ? Ай яй яй !!? Может быть потому что свойства трехмерного пространства с того времени не менялись ? UFS более десяти лет может быть по тому что устройства хранения данных с того времени сильно не менялись? Ну добавили soft update журнал снапшеты но в целом все по старому ... Зато в линуксе бурный рост :)) на фоне бурных глюков :)) Куча фс которые по сути одно и тоже если не считать btrfs с ее cow но linux с btrfs как то сильно отстал от freebsd с zfs ... это случайно :)) копипастеры зазевались? Очень радует разница между jsf и xfs :)) Нахрена две почти одинаковые fs ? Кто то хотел бабла срубить ?

ЗЫ linux это та же избушка что и windows только повернута к лесу передом ...

Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

528. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 05-Окт-12, 11:37 
> Ну добавили soft update журнал снапшеты но в целом все по
> старому...

Ну да - всё те же тормоза.

> Зато в линуксе бурный рост :)) на фоне бурных
> глюков :))

Не ошибается тот, кто ничего не делает.

Ответить | Правка | ^ к родителю #522 | Наверх | Cообщить модератору

65. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –2 +/
Сообщение от nagual email(ok) on 20-Сен-12, 10:25 
>[оверквотинг удален]
> финансирование, но пилят его довольно интенсивно и в майнлайне. А не
> где-то сбоку под левой лицензией. За чем будущее - несложно догадаться.
> Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с
> невнятными перспективами всего этого начинания.
> ...просто потому что BTRFS сможет то что и ZFS. И даже больше.
> И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы -
> вопрос интересный. И что случится с этой кодовой базой - тоже
> интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от
> этого начинания и выбросят его на свалку - тогда чего? Как
> с опенсолярой и ораклем, да? :)

Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо. Используйте btrfs читайте слоника в домене ... Удачи :-))

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

77. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 13:49 
спасибо.
так и делаю. :D
Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

109. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 06:02 
> Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо.
> Используйте btrfs читайте слоника в домене ... Удачи :-))

А знаете, пока бсдшники злобно шипят, слоник как менеджер в общем то вполне нормально рулит. В том плане что собственно конторе от его деятельности скорее польза нежели вред. А то что поклонники сферичкских коней в вакууме недовольны - так это дело десятое и в оценку эффективности менеджера вообще не входит.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

117. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 08:19 
>> Для того чтоб хорошие проекты могли хорошо работать, плохие должны работать плохо.
>> Используйте btrfs читайте слоника в домене ... Удачи :-))
> А знаете, пока бсдшники злобно шипят, слоник как менеджер в общем то
> вполне нормально рулит. В том плане что собственно конторе от его
> деятельности скорее польза нежели вред. А то что поклонники сферичкских коней
> в вакууме недовольны - так это дело десятое и в оценку
> эффективности менеджера вообще не входит.

Вы просто не в курсе событий :)) сначала он раскрутил спонов на никому ненужный переход на линь когда деплой фри уже стоял работал а деплой линя нужно было писать с нуля, а потом он сменил место работы :)) так что ждем новых статей про похождения слоника :-))

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

118. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 11:58 
> сменил место работы :))

У, тогда почте рамблера имхо капец. Если б не вджоб этого руководилы, оно бы так и осталось унылой древней хренью с которой все сбежали.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

88. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 20-Сен-12, 17:07 
> ...просто потому что BTRFS сможет то что и ZFS. И даже больше.

Вот когда сможет хотя бы RAID-5, тогда приходите.

> И лучше.

Вот когда будет годный btrfsck, тогда и приходите.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

89. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 18:35 
>Вот когда сможет хотя бы RAID-5, тогда приходите.

для моего ноута не критично.
использую бтр и не жалуюсь.
>Вот когда будет годный btrfsck, тогда и приходите.

во-первых - уже.
во-вторых - а в ZFS? :D

зыж
а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то?
а то уже скоро обещают, а ты и не готов?

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

90. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 20-Сен-12, 19:36 
>>Вот когда сможет хотя бы RAID-5, тогда приходите.
> для моего ноута не критично.

А для моего десктопа критично. ;p

> использую бтр и не жалуюсь.
>>Вот когда будет годный btrfsck, тогда и приходите.
> во-первых - уже.

Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"?
http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13...

> во-вторых - а в ZFS? :D

zpool scrub <poolname>. Было с самого начала.

> зыж
> а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то?

"На Btrfs можно делать несколько копий данных?"

> а то уже скоро обещают, а ты и не готов?

Я всегда готов. Только ты об этом узнаешь ВНЕЗАПНО.

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

91. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 20-Сен-12, 20:43 
>А для моего десктопа критично. ;p

наслышен, наслышен :D
>http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13...

Ха! http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ :D
или http://hardforum.com/archive/index.php/t-1656030.html
а чудику btrfs [filesystem] balance start [options] <path> надо было сделать.
раз уж сам ставил, то сам бы и разруливал.
>Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"?
>> во-вторых - а в ZFS? :D
>zpool scrub <poolname>. Было с самого начала.

btrfs scrub start [-Bdqr] <path>|<device>
было с самого начала.
но (для посикс/лсб) сделали ещё и фсчк.
а у вас там фсчк есть? а сбойные блоки не провирть? :D
>"На Btrfs можно делать несколько копий данных?"

ага :D
>Я всегда готов. Только ты об этом узнаешь ВНЕЗАПНО.

это тебе так кажется. :D

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

92. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 20-Сен-12, 22:32 
> Ха! http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ :D

Это уже баян, который давно порвали на кусочки. В ZFSv28 (с 6 июня 2011 года во FreeBSD) есть волшебная команда "zpool import -F <poolname>" в случае FAULTED-пула.
http://www.mail-archive.com/freebsd-stable@freebsd.org/...

> или http://hardforum.com/archive/index.php/t-1656030.html

"12-02-2011, 12:13 AM"
Давайте жить сегодняшними реалиями.

> а чудику btrfs [filesystem] balance start [options] <path> надо было сделать.

Так объяснил бы этому чудику.

>>zpool scrub <poolname>. Было с самого начала.
> btrfs scrub start [-Bdqr] <path>|<device>
> было с самого начала.
> но (для посикс/лсб) сделали ещё и фсчк.
> а у вас там фсчк есть? а сбойные блоки не провирть? :D

А зачем проверять сбойные блоки, если список повреждённых файлов и путей до них перед глазами. Зачем нам нужны сбойные блоки с мусором?

>>"На Btrfs можно делать несколько копий данных?"
> ага :D

Каким образом? Через снапшоты? :))

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

93. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от ананим on 21-Сен-12, 00:20 
>Это уже баян,

угу.
>"12-02-2011, 12:13 AM"
>Давайте жить сегодняшними реалиями.

Так кто ж спорил бы! :D
>2012-05-07
>    Migration from http://btrfs.ipv5.de
>Latest btrfs-progs (c. 26 Mar 2012)
>    btrfsck can now repair some forms of filesystem breakage
>Enterprise btrfs support (Feb 2012)
>    Since February 2012 there are two vendors who support btrfs in their distributions, Oracle and SUSE.

и боянист из тебя плохой - 0.19 даже уже в википедии нет.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

111. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от Аноним (??) on 21-Сен-12, 06:04 
> и боянист из тебя плохой - 0.19 даже уже в википедии нет.

Да ты слушай больше этого Ыксперта, у тебя тоже диски будут работать как у него  :) [выжимая аж целых 6мб/сек на шпиндель, ололо]

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

134. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 22-Сен-12, 21:47 
>> и боянист из тебя плохой - 0.19 даже уже в википедии нет.
> Да ты слушай больше этого Ыксперта, у тебя тоже диски будут работать
> как у него  :) [выжимая аж целых 6мб/сек на шпиндель,
> ололо]

http://www.linux.org.ru/forum/talks/8255499?cid=8255518

Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

144. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 09:52 
> http://www.linux.org.ru/forum/talks/8255499?cid=8255518

data=journal, drive cache=off, fsync
а чтобы не извращаться - надо ставить ИБП

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

153. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:10 
>> http://www.linux.org.ru/forum/talks/8255499?cid=8255518
> data=journal, drive cache=off, fsync
> а чтобы не извращаться - надо ставить ИБП

Ну вот оказываеся ext4 без журнала гробит данные. И что же это она во всех тестах, где всех рвет - без журнала ? :-))  А с журналом что сливает ?

Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

158. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 11:17 
> Ну вот оказываеся ext4 без журнала гробит данные. И что же это
> она во всех тестах, где всех рвет - без журнала ?
> :-))  А с журналом что сливает ?

Да нет, просто журналирование ДАННЫХ (не метаданных) - удел нищебродов, неспособных позволить себе UPS на критичное приложение. А если нет критичного приложения - то и вообще не актуально.

Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

160. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:21 
>> Ну вот оказываеся ext4 без журнала гробит данные. И что же это
>> она во всех тестах, где всех рвет - без журнала ?
>> :-))  А с журналом что сливает ?
> Да нет, просто журналирование ДАННЫХ (не метаданных) - удел нищебродов, неспособных позволить
> себе UPS на критичное приложение. А если нет критичного приложения -
> то и вообще не актуально.

Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-))) Ага и чемодан с батарейками в свободную руку :-))) Короче говоря для ноутов с их тормознутами но зато противоударными дисками дисками линукс с ext4 не годится, будет еще тормознутей :-)))

Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

164. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 11:27 
> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))

Сие следует понимать так:
Работать с критичными данными на ноуте с разряженной батареей - моветон.

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

165. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 11:28 
>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))
> Сие следует понимать так:
> Работать с критичными данными на ноуте с разряженной батареей - моветон.

Ну и да - если уж нельзя "оторваться от производства" по пути - только нищеброды не могут себе позволить сменную батарею.

Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

168. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:38 
>>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))
>> Сие следует понимать так:
>> Работать с критичными данными на ноуте с разряженной батареей - моветон.
> Ну и да - если уж нельзя "оторваться от производства" по пути
> - только нищеброды не могут себе позволить сменную батарею.

А как вы смените батарею не выключая бук и не закрывая все приложения ? :-)) Гибернейшен разве у всех работает ? :-))

Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

175. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 12:14 
> А как вы смените батарею не выключая бук и не закрывая все
> приложения ? :-)) Гибернейшен разве у всех работает ? :-))

У кого в критичной среде оное не работает - милости прошу об стену или в окно.

Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

194. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 17:03 
> У кого в критичной среде оное не работает - милости прошу об
> стену или в окно.

И как помогает ? :-)))


Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

206. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 18:43 
>> У кого в критичной среде оное не работает - милости прошу об
>> стену или в окно.
> И как помогает ? :-)))

Не знаю. Первый раз человека с подобной проблемой увидел по приведенной выше ссылке. Очевидно, редкий вид. На собственной практике не случалось ни разу.

Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

405. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 13:40 
> И как помогает ? :-)))

Проверьте. Вы же любите требовать тесты. Теперь наша очередь :)

Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

177. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 12:18 
>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))
> Сие следует понимать так:
> Работать с критичными данными на ноуте с разряженной батареей - моветон.

Человек вообще не открывал те файлы, что у него обнулились, но случайно оказались в одном каталоге с запущенной программой.


Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

196. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 17:05 
>>> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))
>> Сие следует понимать так:
>> Работать с критичными данными на ноуте с разряженной батареей - моветон.
> Человек вообще не открывал те файлы, что у него обнулились, но случайно
> оказались в одном каталоге с запущенной программой.

Когда при запуске fsck в фоне обнуляются открытые файлы это херово но не ново, но вот когда соседние это просто ППЦ.

Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

207. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 18:43 
> Когда при запуске fsck в фоне обнуляются открытые файлы это херово но
> не ново, но вот когда соседние это просто ППЦ.

Я бы сказал, если руки из задницы - может и весь диск обнулиться.
Потому, что если подумать - этого не может быть потому, что не может быть.
Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных.

Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

241. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 20:40 
>> Когда при запуске fsck в фоне обнуляются открытые файлы это херово но
>> не ново, но вот когда соседние это просто ППЦ.
> Я бы сказал, если руки из задницы - может и весь диск
> обнулиться.
> Потому, что если подумать - этого не может быть потому, что не
> может быть.
> Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных.

А случай с улетевшим разделом ? Этого не может быть потому что быть не может ? Месье накурился ?


Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

244. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 20:43 
> А случай с улетевшим разделом ? Этого не может быть потому что
> быть не может ? Месье накурился ?

За два года юза ext4 в продакшне не было ни одного случая отказа FS. Был случай выпадения двух дисков в пятом рейде, но тут уже любая FS ляжет. Порядка 25 серверов. На некритичных (и включенных по этой причине без UPS) происходили в т.ч. отключения питания. Никаких развалов, обнулений файлов, и прочего. Но тут потому, что софт обучен не делать ftruncate/rewrite. Только write/unlink/mv.

Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

468. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 01-Окт-12, 15:32 
> Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных.

Он написал про какой-то фон. Уж не пнул ли этот баклан fsck на смонтированном разделе? Ну там где fsck еще истошно орет варнингами про то что в таком режиме он может раздестроить все и вся и никаких гарантий дескать нет. Если он сделал это - ну он и получил что заслужил. Потому что сложно быть глупым, да.

Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

479. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 00:29 
>> Скорее всего (с вероятностью 99%) - камиказе с отключенным журналом метаданных.
> Он написал про какой-то фон. Уж не пнул ли этот баклан fsck
> на смонтированном разделе? Ну там где fsck еще истошно орет варнингами
> про то что в таком режиме он может раздестроить все и
> вся и никаких гарантий дескать нет. Если он сделал это -
> ну он и получил что заслужил. Потому что сложно быть глупым,
> да.

Очередной высер из серии - не читал но осуждаю ...
fsck запускался из хост системы без монтирования.
Сложно сапортить когда системы ставят глупые люди.

Ответить | Правка | ^ к родителю #468 | Наверх | Cообщить модератору

516. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 02-Окт-12, 21:40 
> fsck запускался из хост системы без монтирования.

А, вот оно что. А при чем тут фон?

> Сложно сапортить когда системы ставят глупые люди.

Самокритичненько.

Ответить | Правка | ^ к родителю #479 | Наверх | Cообщить модератору

406. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 26-Сен-12, 13:41 
> Человек вообще не открывал те файлы, что у него обнулились, но случайно
> оказались в одном каталоге с запущенной программой.

Не верю (с)
либо руки

Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

408. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 26-Сен-12, 13:49 
>> Человек вообще не открывал те файлы, что у него обнулились, но случайно
>> оказались в одном каталоге с запущенной программой.
> Не верю (с)
> либо руки

Либо фс :-))


Ответить | Правка | ^ к родителю #406 | Наверх | Cообщить модератору

410. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 26-Сен-12, 14:04 
> Либо фс :-))

Многолетней практикой не подтверждено - значит руки.

Ответить | Правка | ^ к родителю #408 | Наверх | Cообщить модератору

480. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 00:30 
>> Либо фс :-))
> Многолетней практикой не подтверждено - значит руки.

Какая у вас интересная практика, неужели за все эти годы нельзя было научиться хотябы самому простому ? :-)))

Ответить | Правка | ^ к родителю #410 | Наверх | Cообщить модератору

485. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 07:22 
> Какая у вас интересная практика, неужели за все эти годы нельзя было
> научиться хотябы самому простому ? :-)))

Моя практика стабильно работает годами на множестве серверов, поэтому заявления жопоруких о "либо ФС" мне как-то не интересны.

Ответить | Правка | ^ к родителю #480 | Наверх | Cообщить модератору

428. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 26-Сен-12, 20:30 
> Либо фс :-))

Массовых воплей не видно при том что оно дефолтное в 100500 дистрах, стало быть дело не в бобине. Было б там все плохо - все багтрекеры бы уже легли под натиском пострадавших.

Ответить | Правка | ^ к родителю #408 | Наверх | Cообщить модератору

431. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  –1 +/
Сообщение от nagual email(ok) on 26-Сен-12, 21:11 
>> Либо фс :-))
> Массовых воплей не видно при том что оно дефолтное в 100500 дистрах,
> стало быть дело не в бобине. Было б там все плохо
> - все багтрекеры бы уже легли под натиском пострадавших.

Вот действительно у бсд до пследнего времени была всего одна UFS и никакой паники несмотря на грозные высеры ЛГМовцев :-))

Ответить | Правка | ^ к родителю #428 | Наверх | Cообщить модератору

452. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 30-Сен-12, 20:58 
> Вот действительно у бсд до пследнего времени была всего одна UFS и
> никакой паники несмотря на грозные высеры ЛГМовцев :-))

Стало вместо 1 тормознутой ФС две. Вторая - тормознутая и переросточная. Ассортимент, однако :)

Ответить | Правка | ^ к родителю #431 | Наверх | Cообщить модератору

486. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 07:23 
> Вот действительно у бсд до пследнего времени была всего одна UFS и
> никакой паники несмотря на грозные высеры ЛГМовцев :-))

Да там так и есть "всего одна UFS", ZFS реально эксплуатабельной считать нельзя - так, для файлопомоек сгодится, но судя по Сети - реальных юзкейсов почти 0. Собственно, поэтому и никакой паники - число юзкейсов BSD не намного превышает число юзкейсов ZFS.

Ответить | Правка | ^ к родителю #431 | Наверх | Cообщить модератору

499. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 02-Окт-12, 13:44 
>> Вот действительно у бсд до пследнего времени была всего одна UFS и
>> никакой паники несмотря на грозные высеры ЛГМовцев :-))
> Да там так и есть "всего одна UFS", ZFS реально эксплуатабельной считать
> нельзя - так, для файлопомоек сгодится, но судя по Сети -
> реальных юзкейсов почти 0. Собственно, поэтому и никакой паники - число
> юзкейсов BSD не намного превышает число юзкейсов ZFS.

Это статистика по твоей больнице что ли? :) Оно и понятно.

http://forum.ixbt.com/topic.cgi?id=11:44215-77
80 человек юзают ZFS (во FreeBSD — 43 и 7 — в Solaris)
18 человек юзают Linux (Ext* или ZoL).
17 — Windows

Ответить | Правка | ^ к родителю #486 | Наверх | Cообщить модератору

500. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 15:38 
88 человек - это МЕГА репрезентативная выборка, имя которой - "ни о чём".

Тем более очень специфично то, что именно о NAS на x86 речь идёт. Совершенно бессмысленный и беспощадный юзкейс, хотя бы по электропитанию.

Основная ЦА - самоделкины, которым в силу каких-то причин сильно лень купить нормальный сохошный NAS c линуксами внутри, стоящий гораздо меньше, чем железо, которое используется в треде.

Нет, конечно, из имеющихся под рукой говна и палок можно и NAS слепить, но тогда уж надо себе сказать, что это чисто ради эксперимента. А если делать по уму - надо делать на ARM/MIPS, и нормально (как и сделано в нормальных NAS).

У меня например сетевое хранилище совмещено с серваком, который и так есть. Тупо виртуалка с SMB и несколькими разделами ext4 на VMFS, который на рейде вместе со всем остальным. В отдельном NAS смысла не вижу.

А юзерам, у которых сервака нет - на самоделия фиолетово, и они купят какой-нибудь SOHO NAS от WD или прочих компаний.

Т.е., в итоге - имеем в треде узкий круг любителей городить огород там, где смысла в нем нет в принципе. Что показательно - в основном BSD'шники.

Ответить | Правка | ^ к родителю #499 | Наверх | Cообщить модератору

501. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 15:52 
Вот гораздо более вменяемый юзкейс:
http://www.dlink.ru/ru/products/120/1477.html
Внутри - как бы ты думал, какая ОС? :)

Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :)

Ответить | Правка | ^ к родителю #499 | Наверх | Cообщить модератору

503. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 02-Окт-12, 16:04 
> Вот гораздо более вменяемый юзкейс:
> http://www.dlink.ru/ru/products/120/1477.html
> Внутри - как бы ты думал, какая ОС? :)
> Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :)

Длинк гавно - проверено на wi-fi роутерах и адсл мопедах ...

Ответить | Правка | ^ к родителю #501 | Наверх | Cообщить модератору

504. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 02-Окт-12, 16:50 
> Длинк гавно - проверено на wi-fi роутерах и адсл мопедах ...

Чем именно?

Ответить | Правка | ^ к родителю #503 | Наверх | Cообщить модератору

517. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 02-Окт-12, 21:44 
> Длинк гaвно - проверено на wi-fi роутерах и адсл мопедах ...

Длинк - это тайванокитайцы. Поэтому у них есть все. От супершита до вполне нормальных девайсов. А модемы у них г, но местные тут когда-то делали для них нормальные прощивки. Был такой человек - McMcc. С его прошивками гэ вполне себе становилось конфеткой. Правда они прощелкали клювом и спец ушел делать прошивки конкурентам. FAIL, да.

Упомянутый - девайс как девайс. Свою нишу имеет, народом покупается. В тиражах явно превосходящих ваши полтора^W 88 землекопов на многие порядки. А подобные по смыслу штуки есть и у synology, qnap и еще 100500 производителей. У некоторых на таком пепелаце даже LAMP отбабахан :)

Ответить | Правка | ^ к родителю #503 | Наверх | Cообщить модератору

518. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 03-Окт-12, 22:54 
> Вот гораздо более вменяемый юзкейс:
> http://www.dlink.ru/ru/products/120/1477.html
> Внутри - как бы ты думал, какая ОС? :)

Тулчейн по изменению прошивки прилагается бесплатно или нужно подписывать специальное соглашение на ограничения по разработке и распространение технологических секретов? ;)

> Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :)

Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что? Твоя пузомерка в чём заключается, в технологичности или в массовости/доступности (для средних умов)?


Ответить | Правка | ^ к родителю #501 | Наверх | Cообщить модератору

519. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 03-Окт-12, 23:02 
>> Вот гораздо более вменяемый юзкейс:
>> http://www.dlink.ru/ru/products/120/1477.html
>> Внутри - как бы ты думал, какая ОС? :)
> Тулчейн по изменению прошивки прилагается бесплатно или нужно подписывать специальное
> соглашение на ограничения по разработке и распространение технологических секретов? ;)
>> Куча хранилок корпоративного уровня от SYNOLOGY - тоже на нём :)
> Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что?
> Твоя пузомерка в чём заключается, в технологичности или в массовости/доступности (для
> средних умов)?

Обновил скрипты http://actika.livejournal.com/619.html

Ответить | Правка | ^ к родителю #518 | Наверх | Cообщить модератору

520. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 03-Окт-12, 23:34 
> Куча хранилок корпоративного уровня iXsystems, Inc. на FreeBSD с ZFS и что?

Простите, что такое iXSystems? D-Link, WD, Synology - их знает весь мир. А iXSystems? В реале не встречал ни разу, честно.

Ответить | Правка | ^ к родителю #518 | Наверх | Cообщить модератору

521. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 03-Окт-12, 23:34 
А, сам себе отвечу.

Это чудесники, которые купили и похоронили PC-BSD...

Ответить | Правка | ^ к родителю #520 | Наверх | Cообщить модератору

523. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 04-Окт-12, 16:31 
> А, сам себе отвечу.

Обновил тесты
http://actika.livejournal.com/619.html
ext4 сошел с дистанции ...

Ответить | Правка | ^ к родителю #521 | Наверх | Cообщить модератору

524. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 04-Окт-12, 21:44 
> Обновил тесты
> http://actika.livejournal.com/619.html
> ext4 сошел с дистанции ...

Ржали над высером про фрагментацию на рамдиске всей командой.
Потом на перекуре долго обсуждали - сколько нужно свободного места для дефрагментации.
Пришли к выводу, что данный юзкейс с близким к 0 объемом свободного места и дефрагером мог придумать только клинический идиот.

Заскриншотил, буду показывать образчик феерического бреда будущим коллегам и потомкам.

Но вот за табличку с перформансами спасибо - сошлись во мнении, что табличка явно рассказывает, кто есть что.

Ответить | Правка | ^ к родителю #523 | Наверх | Cообщить модератору

525. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 04-Окт-12, 22:45 
>> Обновил тесты
>> http://actika.livejournal.com/619.html
>> ext4 сошел с дистанции ...
> Ржали над высером про фрагментацию на рамдиске всей командой.
> Потом на перекуре долго обсуждали - сколько нужно свободного места для дефрагментации.

Вместе с доктором ? или опять соло ?

> Пришли к выводу, что данный юзкейс с близким к 0 объемом свободного
> места и дефрагером мог придумать только клинический идиот.

Если дефрагментатор запускуается наверно он знает сколько ему нужно места ? Или админ с калькулятором прилагается к каждому дефрагментатору автоматически ?

> Заскриншотил, буду показывать образчик феерического бреда будущим коллегам и потомкам.

Тяжело спорить с клиническими идиотами, но я буду стараться ...

> Но вот за табличку с перформансами спасибо - сошлись во мнении, что
> табличка явно рассказывает, кто есть что.

Ну да фаворит(ext4fs) выбыл по причине нестабильности ... все остальные либо дохлыей (рейзер) либо древние и заброшенные(ext3 ext2) либо впереди планеты всей (btrfs) :)))


Ответить | Правка | ^ к родителю #524 | Наверх | Cообщить модератору

526. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 04-Окт-12, 22:47 
> Ну да фаворит(ext4fs) выбыл по причине нестабильности ...

пруф, или клиника...


Ответить | Правка | ^ к родителю #525 | Наверх | Cообщить модератору

527. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 04-Окт-12, 22:53 
>> Ну да фаворит(ext4fs) выбыл по причине нестабильности ...
> пруф, или клиника...

пруф жж если неасилили - клинака ...

Ответить | Правка | ^ к родителю #526 | Наверх | Cообщить модератору

529. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 05-Окт-12, 11:38 
> пруф жж если неасилили - клинака ...

ваш жж - это не пруф, а набор отборного бреда
за исключением таблички, которая четко показывает положение дел

Ответить | Правка | ^ к родителю #527 | Наверх | Cообщить модератору

530. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 05-Окт-12, 14:08 

> ваш жж - это не пруф, а набор отборного бреда
> за исключением таблички, которая четко показывает положение дел

Месье потрудится опровергнуть хотябы одно утверждение из жж ? а то слив не защитан ...
По ссылке http://www.linux.org.ru/forum/talks/8255499?cid=8302757 разжеванный вариант специально для месье.

> Ну да - всё те же тормоза.

У меня тоже возникает ощущение что я спорю с тормозом.

> Не ошибается тот, кто ничего не делает.

Умные люди предпочитают учиться на чужих ошибках ...

Ответить | Правка | ^ к родителю #529 | Наверх | Cообщить модератору

531. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 05-Окт-12, 14:16 
> По ссылке http://www.linux.org.ru/forum/talks/8255499?cid=8302757 разжеванный вариант
> специально для месье.

Бугага, тебе и там разъяснили, что ты чушь порешь по большей мере. Удачи в жевании кактусов, бро. А твои "тесты" - полнейшая туфта. BONNIE+ я и сам взять могу.

Ответить | Правка | ^ к родителю #530 | Наверх | Cообщить модератору

347. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 23:41 
> Сие следует понимать так - нетаскать упс за ноутом удел нищебродов :-)))

У ноута и так "ups" встроен.

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

122. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 21-Сен-12, 12:34 
> А для моего десктопа критично. ;p

Десктоп изена, тот что с голубыми кристаллами^W^W дисками выдающими 6Мб/сек :)

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

139. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 01:48 
>> А для моего десктопа критично. ;p
> Десктоп изена, тот что с голубыми кристаллами^W^W дисками выдающими 6Мб/сек :)

Хватит уже дурь свою показывать. Освободится место — скорость увеличится.


Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

149. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 09:57 
> Хватит уже дурь свою показывать. Освободится место — скорость увеличится.

Не увеличится, дефраггера-то нетуть...

Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

170. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 11:59 
>> Хватит уже дурь свою показывать. Освободится место — скорость увеличится.
> Не увеличится, дефраггера-то нетуть...

Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно?


Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

176. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 12:15 
> Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно?

Скорость чего? Перемещения руки вверх-вниз при просмотре содержимого?
В какой-то соседней теме замеры уже выкладывались - всё очевидно, собственно.

Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

181. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от iZEN (ok) on 23-Сен-12, 12:36 
>> Освободил 30 ГБ — скорость возросла в разы. Что я сделал неправильно?
> Скорость чего? Перемещения руки вверх-вниз при просмотре содержимого?

Скорость всего — чтения, записи, просмотра данных.

> В какой-то соседней теме замеры уже выкладывались - всё очевидно, собственно.

Вот и я говорю: спорить о скорости CoW при 97-99% заполненности данными не имеет смысла.

Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

301. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 06:50 
> Скорость всего — чтения, записи, просмотра данных.

Чего бы это ради? Файлы которые разложились неудачно и читаются медленно - так и останутся разложенными неудачно и читающимися медленно. В принципе, им можно сделать "дефраг вручную", то-есть, освободив место скопировать файл заново, так что в лучшем случае он более линейно разложится, если стертые файлы были более линейно распиханы и свободное место линейное. А если они тоже были в состоянии макарон по всему диску - ну ты понял...

Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

210. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 18:57 
> Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"?
> http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13...

Гениально! На основании того что у кого-то разбился тестовый прототип самолета мы сделаем глобальный вывод: все самолеты - гэ! Defective by design! Ходите  пешком!!!1111

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

246. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 20:48 
>> Вы хотите сказать: "Не так давно, хоть что-то появилось, что может что-то чинить"?
>> http://www.linux.org.ru/forum/talks/8203698/page4?lastmod=13...
> Гениально! На основании того что у кого-то разбился тестовый прототип самолета мы
> сделаем глобальный вывод: все самолеты - гэ! Defective by design! Ходите
>  пешком!!!1111

Правильным выводом было бы приостановить эксплуатацию этой модели самолета (btrfs) и провести детальное исследование катастрофы для устанения возможных деффектов в этой модели.

Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

302. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 24-Сен-12, 06:54 
> Правильным выводом было бы приостановить эксплуатацию этой модели самолета (btrfs) и провести
> детальное исследование катастрофы для устанения возможных деффектов в этой модели.

Сложно "приостановить эксплуатацию" для штуки явно позиционируемой как тестовый прототип. И да, у гражданина ФС жила 2.5 года, т.е. ФС создавалась и изначально писалась куда как более древним ядром. Что оно там понаворотило и сколько багов с тех пор исправили - вопрос интересный. При том от предложения расследовать гражданин отказался и вообще шустро-быстро замел все следы, что как-то подозрительно. Ну то-есть гражданин как-то и не был заинтересован в изучении результатов. Ну так его право, тогда ему грех жаловаться. А учитывая размеры раздела "с кошкину задницу" и прочая - возникает ощущение что гражданин прямо заранее нацелился на то что у него тестовый самолет расшибется и он всем скажет какое это гэ.

Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

128. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 21-Сен-12, 18:26 
>>Вот когда сможет хотя бы RAID-5, тогда приходите.
> для моего ноута не критично.
> использую бтр и не жалуюсь.
>>Вот когда будет годный btrfsck, тогда и приходите.
> во-первых - уже.
> во-вторых - а в ZFS? :D
> зыж
> а ты придумал уже, что будешь писать, когда реализуют 5-й рэйд то?
> а то уже скоро обещают, а ты и не готов?

Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет того функционала что есть в ZFS например ZFS рекомендуют ставить на диски заменяя функционал аппаратных рейдов и если btrfs с ее общесистемным кешем это отличноее решения для десктопа то ZFS с ее заменой рейда это решение для сервера ... честно говоря linux он больш для десктопа и на сервере ему делать нефиг. Была прада java которая по идейным сображениям (лицензионным вестимо) не работает на bsd но не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит :))) судя по стремительности выпуска секурных обновлений работа в этом направлени просто кипит :)))

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

130. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 22-Сен-12, 09:12 
> Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет

Не с глаголами пишется раздельно :P.

> того функционала что есть в ZFS

Да, пока еще не абсолютно все фичи реализованы. Тем не менее, есть и фичи на которые ZFS будет нечем ответить без заметной переделки. Вон например не успели BSDшники попонтоваться насчет send/receive как он был реализован в свежих ядрах :)

> например ZFS рекомендуют ставить на диски заменяя функционал аппаратных рейдов

Аппаратные рэйды имеют как свои плюсы так и свои минусы. Из очевидных плюсов, у них бывает кэш с батарейкой на случай слета питания (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок например.

> и если btrfs с ее общесистемным кешем это отличноее решения для десктопа

<sarcasm>Да, да, и вон та возможность ребалансинга на множество дисков - это тоже специально для десктопа сделано. Да что уж там, ноута с одним хилым винчом. Будем менеджить пул из целого 1 девайса, во! </sarcasm>.

> то ZFS с ее заменой рейда это решение для сервера ... честно говоря linux он больш
> для десктопа и на сервере ему делать нефиг.

Ну да, конечно, вот всякие гуглы, фэйсбуки, твиттеры и прочие википедии, обслуживающие всю планету серваками с линуксом - они лохи. А вот некий nagual лучше них знает как надо. Радуют меня такие самоуверенные кексы, с умным виом несущие пургу :)

> Была прада java которая по идейным сображениям (лицензионным вестимо) не работае на bsd

В этом месте по сценарию iZEN делит на ноль в очередной раз :D.

> но не волнуйтесь можно даже сказать не смневайтесь - оракл ёё похерит :)))

Честно говоря - мне пофиг на яву. Вымрет - туда и дорога. Меньше будет быдлокодеров и тормозных бажных переростков (которых я не люблю независимо от лицензии за тот факт что они - тормозные переростки с кучей багов, в том числе ведущих к дырам в безопасности).

> судя по стремительности выпуска секурных обновлений работа в этом направлени
> просто кипит :)))

Зато у бздельников все как обычно: паршиво поддерживается новое железо + на выбор две тормознутые ФС. Одна из которых к тому же прожорливая до RAM да еще и под кривой и странной лицензией от сан с легким копилефтным уклоном :). Зато, блин, не линукс и не гпл и "ваще типа крута, патамучта вася из 3-го подъезда так сказал".

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

132. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 22-Сен-12, 10:19 
> Да, пока еще не абсолютно все фичи реализованы. Тем не менее, есть
> и фичи на которые ZFS будет нечем ответить без заметной переделки.

О да как жежить под zfs и без дефрагментатора :-))) Обожаю дефрагментацию :)))


> Аппаратные рэйды имеют как свои плюсы так и свои минусы. Из очевидных
> плюсов, у них бывает кэш с батарейкой на случай слета питания
> (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок
> например.

Вы наверно не внимательно читали доку по zfs в двух словах это лучше чем контролер с батарейкой. Кстати иногда батарейки портятся и ппц подкрадывается незаметно :)))

> Ну да, конечно, вот всякие гуглы, фэйсбуки, твиттеры и прочие википедии, обслуживающие
> всю планету серваками с линуксом - они лохи. А вот некий
> nagual лучше них знает как надо. Радуют меня такие самоуверенные кексы,
> с умным виом несущие пургу :)

На данный момент "всякие гуглы" не ставят сырые фс под хранилища ...


> Зато у бздельников все как обычно: паршиво поддерживается новое железо + на
> выбор две тормознутые ФС. Одна из которых к тому же прожорливая
> до RAM да еще и под кривой и странной лицензией от
> сан с легким копилефтным уклоном :). Зато, блин, не линукс и
> не гпл и "ваще типа крута, патамучта вася из 3-го подъезда
> так сказал".

Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения? 8-0
А месье уже сделал домашние задания на понедельник ?


Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

143. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от AlexAT (ok) on 23-Сен-12, 09:49 
> Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения?
> 8-0

Простите, а зачем? Или ставить BSD ради поставить и настроить - это тренд такой? У нас и линуксы неплохо работают, и даже крутить 100500 тыщ ручек после установки не требуется в общем случае.

Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

152. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 11:08 
>> Что такое ? Месье неасилил поставить настроить bsd? Такой высокий порог вхождения?
>> 8-0
> У нас и линуксы неплохо работают, и даже крутить
> 100500 тыщ ручек после установки не требуется в общем случае.

В одном из двух случаев "не" явно лишнее :-))

Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

157. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +1 +/
Сообщение от AlexAT (ok) on 23-Сен-12, 11:16 
> В одном из двух случаев "не" явно лишнее :-))

В случае с *BSD - вероятно, да.

Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

211. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от Аноним (??) on 23-Сен-12, 19:12 
> О да как жежить под zfs и без дефрагментатора :-)))

Не знаю как вы там "жежите". Это наверное тут оффтопик.

> Обожаю дефрагментацию :)))

А изен вон обожает 6Мб/сек со шпинделя. Тоже вариант :)

>> (батарейка программно, простите, не эмулируется) и оффлоад вычислений коррекции ошибок например.
> Вы наверно не внимательно читали доку по zfs в двух словах это лучше чем контролер
> с батарейкой. Кстати иногда батарейки портятся и ппц подкрадывается незаметно :)))

В доках от сана замечено много маркетингового булшита и хитрого виляния попой на неудобных вопросах. В частности, по вопросу насчет фрагментации везде технично повиляно попой. Маркетологи в санях не зря хлеб кушают, но мне то не маркетинг, а чтоб работало и хорошо. Btrfs до этого состояния допинают. Его нынче такая толпа пилит что по другому у них просто не получится.

> На данный момент "всякие гуглы" не ставят сырые фс под хранилища ...

А гуглу это и не надо от ФС. У них отказоустойчивость достигается иначе, путем раскидывания блоков по узлам с неким дублированием блоков, так что вылет узла вообще ничего не меняет. Вот только ставить 100500 серверов под распределенную ФС вместо десктопа или ноута мне кажется как-то слегонца оверкиллом.

> Что такое ? Месье неасилил поставить настроить bsd?

Мсье бодал что-то там "осиливать". Ему нужна система которая будет работать и делать свое дело. Желательно быстро, качественно и с минимальными усилиями на администрирование. А осиливать, то-есть жрать через силу кактус - это ваша прерогатива.

> Такой высокий порог вхождения?

Скорее, просто геморная и грабельная система. Созданная не для жизни а для сферических коней в вакууме. Осилить я могу хоть выставление состояний CPU тумблерами на шине. Только вот в общем случае могу != хочу этим постоянно заниматься на регулярной основе для повседневных задач.

> А месье уже сделал домашние задания на понедельник ?

Еще как. Лет ...цать назад.

Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

249. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."  +/
Сообщение от nagual email(ok) on 23-Сен-12, 21:02 
> вместо десктопа или ноута ...

Безусловно btrfs отличное решение для десктопа или ноута, правда на лоре пишут что за 2.5 года сдыхает, но ничего, починят, года этак через 2.5 :-)))))

> Мсье бодал что-то там "осиливать". Ему нужна система которая будет работать и
> делать свое дело. Желательно быстро, качественно и с минимальными усилиями на
> администрирование.

Помнится по apt-update обновление на grub2 пришло и один боевой серв после ребута не поднялся. Безусловно дебиан это система которая умеет работать и
делать свое дело...быстро, качественно и с минимальными усилиями на
админист