Зачем мирсидес, если в ларёк за пивом «Запорожца» хватает? И вообще, железный рейд придумали, только чтобы с приличных людей больше денег содрать.

Да ты, я вижу, умён. Может ещё предложишь компании Maersk заменить их некрасивые корабли на яхты а-ля Абрамович?

А мужики то и не знают

Да, мужики - народ тёмный.

Довольно смелое утверждение, что на всех серверах без вариантов должен быть ZFS или BTRFS, тебе не кажется?

На LVM такого не сделаешь.

Уже сделаешь, man bcache.

Ну почему же, можете дальше заниматься самоудовлетворением под прежними знамёнами

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

Да нет, это ты не в курсе, ибо продолжаешь стоять на своем, ибо:

это тот пул, куда установлен корень системы.

ты так и не в состоянии признать, что понятие «танк» применительно к ZFS существует только лишь в твоей бестолковке :)

Увы, встречая его вне моей «бестолковки», мне сложно поверить в это утверждение.

Вот-вот, имя cistern тоже можно встретить в примерах :)

Ну надо же, даже разработчики считают, что между датасетом и некой большой ёмкостью есть много общего. Что бы это могло значить?

Ола-ла!! Документацию ты читать не читаешь, в исходный код не заглядываешь. А если бы энергию направил в конструктивное русло и заглянул в код, то увидел бы, что есть функция spa_rename()...

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

Так что, мальчик, изучил бы ты матчасть для начала.

Сначала вылези из лужи, в которую ты сел, и обсушись.

судя по твоим ответам(ниже по топику тоже), ты вообще ничего не знаешь и не желаешь

Я обминко, я не хочу ничего настраивать, я хочу свитер с оленями и пиво!

а в начале «дискуссии» для тебя это был пул, неплохой пример того, как ты разбирал по байтам.

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

ты совсем дурачок?

Приходится опускаться на интеллектуальный уровень собеседников, ничего не поделаешь. Иначе просто диалога не выйдет.

там внизу аноним тебе вроде ещё раз всё разжевал

Анонимус с размаху сел в лужу. ЛОР-аналитики такие ЛОР-аналитики.

засим откланяюсь, ибо ddos случился от потока фейспалмов с тебя.

Успехов в разработке лица ладонью!

Ещё раз: мне безразлично, пробрасывает ли LVM команды TRIM в случае одного диска.

А как всё красиво начиналось! А теперь уточнения пошли, про разнородные диски в массиве. Что, кто-то в самом деле ставит в один массив просто для прикола смесь из SAS, SATA и SSD разных типов подключений? Или ты имеешь в виду bcache?

Да ты, я вижу, умён.

Вот, так бы сразу! Приятно всё-таки, когда тебя уважают.

Может ещё предложишь компании Maersk заменить их некрасивые корабли на яхты а-ля Абрамович?

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

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

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

Судя по твоим утверждениям, что документацию ты читал и разбирал ZFS ажно до байта, и даже можешь к месту ввернуть про «корневой DSL-каталог», уж не трудишься ли ты часом в какой-нибудь Nexenta? Если так, то мне ребят из Nexenta искренне жаль.

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

Почитай что-ли про то, как устроен hardware RAID. Твоя клоунада утомляет.

А как всё красиво начиналось! А теперь уточнения пошли, про разнородные диски в массиве. Что, кто-то в самом деле ставит в один массив просто для прикола смесь из SAS, SATA и SSD разных типов подключений? Или ты имеешь в виду bcache?

Петросян, перелогинься.

На больших ZFS массивах как правило стоят SSD и используются для кеширования. ZFS отлично понимает как с ними работать. А что до твоих bcache и LVM, то с ними всё просто - недокументированное топорное говно. Bcache это не более чем примитивная прослойка, г де на SSD валятся все данные без разбора, убивая его время жизни, и превращая его в bottleneck. Более того, простое гугление bcache показывает, что он либо де-факто не поддерживается, либо поддерживается на добровольных началах одним лишь человеком (Kent Overstreet). Вперед, великий типамышь, пользуйся LVM с bcache на hardware RAID. Это - твой уровень. :)

У тебя серьезные проблемы с пониманием написанного русским по белому

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

Так что пока сходи лучше обсушись после лужи, в которую ты с с таким плеском сел.

Почитай что-ли про то, как устроен hardware RAID.

Ну да, тут мне уже один анонимус рекомендовал почитать про то, как устроен ZFS. И где он теперь?

Если ты не понял, то переведу: это был сарказм по поводу того, что лишняя нагрузка математикой и излишний ввод-вывод свойственны софтовым рейдам, к которым относятся и некоторые типы пулов ZFS, а вовсе не хардварным.

Твоя клоунада утомляет.

Ужасно. Ляг, поспи, и всё пройдёт.

Вперед, великий типамышь, пользуйся LVM с bcache на hardware RAID. Это - твой уровень. :)

Спасибо, о великий гуру, что указал мне путь!

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

А тебе - успехов в истользовании ZFS-on-Linux, который Trim использовать не умеет даже в таком виде. ;-)

Если ты не понял, то переведу: это был сарказм по поводу того, что лишняя нагрузка математикой и излишний ввод-вывод свойственны софтовым рейдам, к которым относятся и некоторые типы пулов ZFS, а вовсе не хардварным.

Боже, какая страшная нагрузка... XOR блоков данных, DMA transfers и ещё пару вещей по-мелочи. Всё, сляжет система, это неподъёмно. И лишь hardware RAID на базе крутого 300Mhz RISC способен справиться с такой нереальной задачей.

А тебе - успехов в истользовании ZFS-on-Linux, который Trim использовать не умеет даже в таком виде. ;-)

Спасибо, я предпочитаю ZFS на других OS. Он там всё что нужно умеет. :)

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

Удачи! :)

Боже, какая страшная нагрузка... XOR блоков данных, DMA transfers и ещё пару вещей по-мелочи.

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

И лишь hardware RAID на базе крутого 300Mhz RISC способен справиться с такой нереальной задачей.

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

Спасибо, я предпочитаю ZFS на других OS. Он там всё что нужно умеет. :)

Не беспокойся, на фряхе ему точно альтернативы нет, там я его тоже во всю гоняю.

Удачи! :)

Иногда она требуется, да.

кистате тут фороникс свежие тесты подогнал zfs-0.6.2 vs ext4 vs btrfs

http://www.phoronix.com/scan.php?page=article&item=zfs_linux_062&num=2

Похороникс в своём репертуаре: что показывает ZFS на единственном SSD с неназванными опциями «по умолчанию» против ext4 c data=ordered,relatime?

Даже с криптографической контрольной суммой каждого блока и атомарным CoW делает ext4 без контроля целостности в два раза на Intel IOMeter File Server Access.

Почему они бояться провести тест хотя бы на четырех дисках с raidz1/raid5? Почему бояться показать опции пула и датасета? Почему не используют опцию ashift при создании пула, когда применяемый в тестах ssd врет про 512 байт блоки? Почему не включат журналирование данных на ext4? ;)

Почему
Почему
Почему
Похороникс в своём репертуаре

Ты же ответил уже :)
Сделай тест сам ^___^

они тестируют на среднедесктопной конфигурации, много ты на десктопах видел рейды из ссд?

Сделай тест сам ^___^

Я ведь уже говорил, она у меня и в продакшене, и дома. ^_-

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

они тестируют на среднедесктопной конфигурации

У меня вокруг средний десктоп имеет от трех шпинделей и выше. Сейчас пишу с

  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0h22m with 0 errors on Fri Aug  2 03:26:44 2013
config:

        NAME            STATE     READ WRITE CKSUM
        zroot           ONLINE       0     0     0
          raidz1-0      ONLINE       0     0     0
            gpt/zpool0  ONLINE       0     0     0
            gpt/zpool1  ONLINE       0     0     0
            gpt/zpool2  ONLINE       0     0     0
            gpt/zpool3  ONLINE       0     0     0

errors: No known data errors

Дада, хорошо.

taz@think:~/.config/awesome$ sudo zfs list
NAME                USED  AVAIL  REFER  MOUNTPOINT
rpool               208G  10,6G    31K  /rpool
rpool/ROOT          198G  10,6G    31K  /rpool/ROOT
rpool/ROOT/ubuntu   198G  10,6G   159G  /
rpool/swap         9,20G  12,7G  2,04G  -

Так я о другом же говорю. Сделай сам тест и напиши об этом большой пост.

Рояль в кустах.

Сейчас сын ковырял зачем-то старый ПК на Athlon X2 4200+, nForce MCP61, 4Gb RAM, SuSe. Достали с полки три списанных ST31000340NS.

# modprobe raid5
# mdadm --create /dev/md0 --level=5 --raid-devices=3 --assume-clean /dev/sd[bcd]1
… всякая дичь с pvcreate, vgcreate, lvcreate, mkfs
… наконец …
$ dbench -D . 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
20 of 20 processes prepared for launch   0 sec
…
Throughput 20.4609 MB/sec  20 clients  20 procs  max_latency=3094.496 ms

Привели всё в исходное

# zpool create -o ashift=12 tank raidz sdb1 sdc1 sdd1
# zfs create -o mountpoint=/tmp/test tank/test
… и наконец …
$ dbench -D . 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
20 of 20 processes prepared for launch   0 sec
…
Throughput 104.309 MB/sec  20 clients  20 procs  max_latency=2779.481 ms

Как-то так. Ребенок в восторге обнимается с кошкой.

PS. Кстати, на таком RAID5 ext4 работает медленнее, чем на сыром диске: 20.5 MB/s против 27 MB/s.

Можно уточнить, размер блока ext4 выровнен по размеру страйпа?

Это же на одной тачке все, да? И одних винчах?

Можно уточнить, размер блока ext4 выровнен по размеру страйпа?

Да.

Линейное чтение/запись получаются примерно по 70 MB/s, плюс-минус.

Это же на одной тачке все, да? И одних винчах?

Естественно.

Тогда да, серьёзный аргумент. Если я правильно понял, ZFS выигрывает за счёт знания структуры массива и оптимизации потоков ввода-вывода по разным дискам. Раз уж смог выдать скорость в полтора раза выше линейной.

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

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

Под задачи её надо тюнить специфичные, попробуй конечно из коробки, но врядли это даст объективность.

Если я правильно понял, ZFS выигрывает за счёт знания структуры массива и оптимизации потоков ввода-вывода по разным дискам.

Именно. Кстати, на 10 клиентах выигрыш уже поменьше:

Throughput 74.1109 MB/sec  10 clients  10 procs  max_latency=1462.987 ms

я начал с того, что отключил ZIL и atime, а там буду читать дальше :)

Зато латенси еще меньше ;)

Зато латенси еще меньше ;)

А это в dbench «max_latency», которая ни о чем не говорит. Если взглянуть подробно:

Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX    1416395     0.044    23.170
 Close        1040614     0.005     5.073
 Rename         59974     0.124    15.386
 Unlink        285898     0.078    18.163
 Deltree           40     4.214    11.168
 Mkdir             20     0.008     0.010
 Qpathinfo    1283727     0.024    43.400
 Qfileinfo     225133     0.003     2.370
 Qfsinfo       235343     0.008     1.955
 Sfileinfo     115420     0.034     3.732
 Find          496332     0.072    20.300
 WriteX        706991     0.049    70.308
 ReadX        2220037     0.011    17.684
 LockX           4610     0.006     0.370
 UnlockX         4610     0.005     0.447
 Flush          99306    57.649  1462.974

Throughput 74.1109 MB/sec  10 clients  10 procs  max_latency=1462.987 ms

отключил ZIL

не надо так делать

А nosql у тебя что именно было?

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

Чья бы корова мычала.

Так что пока сходи лучше обсушись после лужи, в которую ты с с таким плеском сел.

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

Раз ты сам понять не можешь, придется тебе продемонстрировать.

1. Ты утверждаешь, что в ZFS есть понятие «танк». Тебе было сказано не единожды, что такого понятия нет, перечислены существующие понятия, рассматриваемые в документации. Ты продолжаешь стоять на своем. Отлично! Бремя доказывания лежит на утверждающем. Приведи ссылку на документацию Delphix/Joyent/Nexenta/Oracle или любой другой компании или разработчика, занимающихся развитием ZFS, в которых вводится понятие «танк».

2. Я высказал следующее утверждение:

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

На что ты якобы усадил меня в лужу, заявив:

«Не могут. Корневой DSL-каталог пула жёстко привязан к имени пула.»

Тебе был сделан намек, что ты неправ, со ссылкой на spa_rename(), однако ты продолжил стоять на своем:

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

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

Я нигде не утверждал, что spa_rename() применяется для переименования корневого датасета. Так что твое заявление наглядно демонстрирует проблемы с пониманием написанного русским по белому. Вот так ты оказался в луже в третий раз.

Из моего утверждения и комментария со ссылкой на spa_rename() следует, что spa_rename() относится к ситуации, в которой пул и корневой датасет могут иметь разные имена. Поскольку бремя доказывания лежит на утверждающем, придется продемонстрировать тебе на наглядном примере:

> ::spa
ADDR         STATE NAME                           
08beb000    ACTIVE ztest_tmp                      
>
> 08beb000::print spa_t spa_dsl_pool->dp_root_dir->dd_myname
spa_dsl_pool->dp_root_dir->dd_myname = [ "ztest" ]
>
> 08beb000::print spa_t spa_name
spa_name = [ "ztest_tmp" ]
>

Как видишь, имя пула отличается от имени корневого датасета, что и требовалось доказать. Если ты сейчас кинешься утверждать, что это я все нарисовал, то сядешь в лужу в четвертый раз, ибо я могу показать, как такой результат можно получить. В принципе, если бестолковка не совсем бестолковка и твое зявление «документацию я читал с разбором ZFS до байта» есть правда, у тебя есть шанс догадаться самостоятельно, взяв в руки исходный код и начав плясать от spa_rename().

На практике администратору с помощью команды zpool или zfs такого результата получить нельзя. Впрочем, я иного и не утверждал.

У тебя еще есть возможность вылезти из одной лужи, приведя ссылку на документацию по ZFS, где вводится понятие «танк». Дерзай!

отключил ZIL

не надо так делать

Ну зачем же так безапелляционно. Если приложению начхать на консистентность данных, то вполне можно его вынести в отдельную файловую систему и установить свойство «sync» в значение «disabled».

Ну зачем же так безапелляционно.

уж лучше так, чем потом читать нытьё о том, какая zfs плохая и теряет/портит данные. - а что делал? - да ничего, zil отключил. - опупеть... )

Дядь, на всякий случай, если ещё возможно, повтори тест без создания lvm на md0.

Вот тут один зевает: http://www.opennet.ru/openforum/vsluhforumID3/91397.html#86

Удиви его, чтоб он рот держал всё время открытым.

Тестируем разное: MongoDB, Cassandra, couchbase

А чем это мне грозит, кроме потери данных в кэше, неуспевших записаться на диск при внезапном отключении питания?

если ещё возможно, повтори тест без создания lvm на md0

Уже поздно. Но ты ведь понимаешь, там какие-то доли процента скорее всего. Зато без менеджера томов сравнивать возможности уже не получится. ZFS в тесте тоже с гандикапом была: на разделах, а не дисках целиком.

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