The OpenNET Project / Index page

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

Набор патчей, заметно увеличивающих производительность работы с метаданными в Btrfs

30.09.2012 22:00

Мяо Се (Miao Xie), известный своей работой по оптимизации Btrfs, опубликовал в списке рассылки разработчиков файловой системы Btrfs набор патчей с реализацией системы кэширования буфера экстентов, позволяющий существенно сократить время поиска в дереве b+ и уменьшить продолжительность пребывания буфера экстентов в состоянии блокировки, благодаря повторному использованию результатов прошлого поиска. Итогом использования патчей является общее увеличение производительности операций с метаданными. Например, в тесте на создание 100 тыс файлов в 10 параллельных потоков наблюдается ускорение на 20%.

  1. Главная ссылка к новости (http://www.spinics.net/lists/l...)
  2. OpenNews: Из Oracle ушел создатель и основной разработчик Btrfs
  3. OpenNews: Для будущего ядра Linux 3.4 представлена большая серия изменений в Btrfs
  4. OpenNews: Представлены патчи для Btrfs с поддержкой алгоритма сжатия LZ4 и реализация утилиты btrfsck
  5. OpenNews: Патч, увеличивающий производительность Btrfs на 5-10%
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/34973-btrfs
Ключевые слова: btrfs, patch, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (122) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:13, 30/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    хм... начиная читать думал там цифра будет не 20, а 200%, начало было куда более оптимистичным..
     
     
  • 2.4, Аноним (-), 22:40, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.
     
     
  • 3.6, Аноним (-), 22:55, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    "Сперва добейся" - это убербаян. В следующий раз попытайтесь быть пооригинальнее.
     
     
  • 4.13, Аноним (-), 01:03, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Еще несколько "заплюсовавших" "ценителей" чужого труда поддерживают вашу точку зрения. Поздравляю, только громче кричите "убербаян", а то разумные мнения все еще слышны.
     
     
  • 5.29, z (??), 12:38, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно быть поваром, чтобы оценить яичницу, - обтекайте
     
     
  • 6.55, Аноним (-), 15:22, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не нужно быть поваром, чтобы оценить яичницу, - обтекайте

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

     
     
  • 7.69, Аноним (-), 19:40, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот это бред
     
  • 7.107, z (??), 14:05, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Нужно. Потому что не-повара могут высказать мнение, которое лично мне не нравится. Это весомый аргумент, я полагаю?

    Даа, "повар лучше знает", "продавец лучше знает" и т.д и т.п. - попахивает классическим совковым маразмом

     
  • 6.56, Аноним (-), 15:23, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не нужно быть поваром, чтобы оценить яичницу, - обтекайте

    И не нужно быть баянистом, чтобы оценивать игру на рваном баяне.

     
  • 6.57, Аноним (-), 15:47, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > , -

    Да, вот это я понимаю, обтекание. В русском языке нет такого синтаксиса.

     
     
  • 7.64, Аноним (-), 16:42, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На самом деле, есть. Эпик.
     
     
  • 8.91, Аноним (-), 02:06, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Epic fail вы хотели сказать ... текст свёрнут, показать
     
  • 6.89, XoRe (ok), 01:48, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не нужно быть поваром, чтобы оценить яичницу, - обтекайте

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

     
     
  • 7.108, z (??), 14:09, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте
    > В соседней ветке новый ролик от создателей blender оценили, как "графан слабоват".
    > И правда, в мстителях графан покруче.
    > И зачем вникать, что бюджеты этих двух проектов астрономически различаются?

    Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, и для кого "графан слабоват" буду отвечать в вашем же стиле "а вы на бюджет посмотрите" =)


     
     
  • 8.113, XoRe (ok), 17:03, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Точку любой аноним поставить может Почему-то никто не хочет смотреть на соотнош... текст свёрнут, показать
     
  • 8.118, Аноним (-), 21:45, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А я бесплатно могу, так что вы неэффективный просаживатель бабла А вот например... текст свёрнут, показать
     
  • 4.18, Аноним (-), 03:03, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности.

    ЗЫ я не кометентен в оптимизациях, но компетентен в решении конфликтов: срач ты слил можешь заворачиваться в пижамку.

     
     
  • 5.49, Аноним (-), 15:09, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности.

    В вопросе баянов я вполне компетентен, как и любой интернет-пользователь.

    > я не кометентен в оптимизациях

    ЧИТД

     
  • 5.58, Аноним (-), 15:48, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ЗЫ я не кометентен в оптимизациях,

    Былинный отказ :)

     
  • 4.36, Аноним (-), 14:18, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > "Сперва добейся" - это убербаян.

    Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать.

     
     
  • 5.48, Аноним (-), 15:08, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать.

    Да, говорить правду легко и приятно.

     
  • 3.7, Аноним (-), 22:56, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.

    А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет право утверждать "а король-то голый"?

     
     
  • 4.14, Аноним (-), 01:07, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет
    > право утверждать "а король-то голый"?

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


     
     
  • 5.50, Аноним (-), 15:11, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть
    > он и не авторитет в этой области, а лишь толстый тролль.
    > Ну что ж, с мнением Анонима нужно считаться.

    Если истинность этого мнения очевидна - то почему бы и нет?
    Не важно, _кто_ говорит. Важно, _что_ говорит.

     
  • 4.19, Аноним (-), 03:04, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.
    > А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет
    > право утверждать "а король-то голый"?

    нет но эксперт по голым людям, очевидно же!

     
     
  • 5.47, Аноним (-), 15:07, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > нет но эксперт по голым людям, очевидно же!

    Значит, если люди видят, что король голый - это ничего не значит, пока не придет дипломированный эксперт по голым людям (видимо, патологоанатом) и не вынесет экспертное суждение?

     
  • 3.31, другой аноним (?), 13:25, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.

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

     
     
  • 4.90, XoRe (ok), 01:50, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не очень часто массированно приходится делать такое - "создание 100 тыс файлов в 10
    > параллельных потоков".

    Загрузка фоток пользователями?)

     
  • 3.114, BratSinot (?), 18:33, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Просто изначально нужно писать правильно. А точнее не писать, а для начала разработать.
     
  • 2.5, dalco (ok), 22:45, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Просто наиболее явные места уже заоптимизировали. Так что находить места, где доработка алгоритма дает большой выигрыш, становится все труднее.

    Ваш К.О.

    P.S. Если верить рассылке, то эту самую оптимизацию в свою очередь тоже уже оптимизировали. :)

     
     
  • 3.37, Аноним (-), 14:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > уже оптимизировали. :)

    Оптимизация оптимизации оптимизаци... wait, oh sh--!

     
  • 2.8, jedie (?), 23:07, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    когда дело касается файловых систем. +20% к производительности, это просто огромный прирост.
     
     
  • 3.9, Xasd (ok), 00:10, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не просто +20% к производительност -- а именно "в тесте на создание 100 тыс файлов в 10 параллельных потоков"

    а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-)

     
     
  • 4.15, Аноним (-), 01:27, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ты под досом до сих пор сидишь?
     
  • 4.39, Аноним (-), 14:21, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-)

    Их даже почти наверняка не будет т.к. как правило большую часть времени ФС вообще ничего не делает. А 20% от нуля - и так и эдак ноль.

     
     
  • 5.54, Аноним (-), 15:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Их даже почти наверняка не будет т.к. как правило большую часть времени
    > ФС вообще ничего не делает. А 20% от нуля - и
    > так и эдак ноль.

    Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно.
    Вы случайно не Джеф Бонвик?

     
     
  • 6.59, Аноним (-), 15:52, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно.

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

    > Вы случайно не Джеф Бонвик?

    Да что уж там, Шишкиным сразу называйте. Я тогда спецом для вас сделаю том из одних метаданных и буду вопить про то как btrfs отстоен. Ведь на reiser можно запихнуть в два раза больше пустых файлов :)

     
  • 4.83, Аноним (-), 22:25, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    зато когда потоков будет уже 100 - можно заиметь провал в производительности.. Но видимо это "оптимизаторов"  не отпугивает :)
     
     
  • 5.99, Аноним (-), 03:46, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > зато когда потоков будет уже 100 - можно заиметь провал в производительности..

    А где бенчи на 100 потоков?

     

  • 1.2, pro100master (ok), 22:25, 30/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну там и 2000% мало будет. Пока, увы, еле ворочается, по крайней мере, на декстопе :)
     
     
  • 2.3, Аноним (-), 22:28, 30/09/2012 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Хотели _полный_ аналог ZFS? Получите и распишитесь.
    Осталось только жрач памяти допилить, а то отстает ведь.
     
     
  • 3.11, mylefthand (?), 00:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Хотели _полный_ аналог ZFS?

    А фоновое шифрование когда будет?

     
     
  • 4.25, dalco (ok), 09:52, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А "фоновое шифрование" - это как?

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

    Или я все не так понял?

     
     
  • 5.74, ааноним (?), 20:17, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно неправильно, все данные попадают на диск уже зашифрованными)
     
  • 4.53, Аноним (-), 15:19, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А фоновое шифрование когда будет?

    Когда выйдет проприетарная версия.

     
     
  • 5.70, Аноним (-), 19:59, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда выйдет проприетарная версия.

    Проприетарная версия GPLнутого кода? Это как? :)

     
  • 3.24, iZEN (ok), 09:34, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?
     
     
  • 4.38, ха (?), 14:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    у мня есть raid6, могу поставить btrfs, только зачем мне там еще raid5?
     
  • 4.40, Аноним (-), 14:22, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?

    А как насчет trim и нормальных экстентных аллокаторов? :)

     
     
  • 5.42, iZEN (ok), 14:41, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?
    > А как насчет trim и нормальных экстентных аллокаторов? :)

    В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.

    Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят: http://svnweb.freebsd.org/base?view=revision&revision=240868

     
     
  • 6.51, Аноним (-), 15:13, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.

    В btrfs они есть изначально :)
    А ZFS даже экстентов нет, так что она сoсет не нагибаясь.

     
  • 6.52, Аноним (-), 15:14, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят:

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

     
  • 6.60, Аноним (-), 15:54, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.

    Там то они как раз есть.

    > Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux

    Вот это я и называю ZFSLoL :)

    > принят: http://svnweb.freebsd.org/base?view=revision&revision=240868

    Ну так и сабжевый патч принят. И чего?

     
  • 6.86, filosofem (ok), 23:11, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят

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

     
     
  • 7.87, iZEN (ok), 23:26, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят
    > А говорил не нужно, да. Оказалось просто запилить было некому.

    Давай яснее определю свою позицию по поводу TRIM.
    Для задач, которым важен большой размер блока ФС, совпадающий с размером блока SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен.
    Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки ФС поменьше (128k), TRIM ускорит операции записи.


     
     
  • 8.88, filosofem (ok), 23:44, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Скажу тебе как Капитан Капитану использовать блок 512к только потому что ФС не ... текст свёрнут, показать
     
     
  • 9.93, Аноним (-), 02:19, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это изен и это далеко не самый мощный маразм который он может выдать ... текст свёрнут, показать
     
  • 9.103, iZEN (ok), 11:59, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки NA... большой текст свёрнут, показать
     
     
  • 10.109, filosofem (ok), 14:22, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Напоминаю, TRIM это для SSD ... текст свёрнут, показать
     
     
  • 11.110, iZEN (ok), 14:49, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    SSD не используется для видеомонтажа Странно Не знал ... текст свёрнут, показать
     
     
  • 12.111, filosofem (ok), 16:01, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ZFS годится только для видеомонтажа, буду знать ... текст свёрнут, показать
     
     
  • 13.112, iZEN (ok), 16:23, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И под файлопомойку тоже 8212 отметьте там у себя ... текст свёрнут, показать
     
     
  • 14.115, filosofem (ok), 09:41, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для помойки что она даёт эксклюзивного Дедупликацию и RAID5 С дедупликацией те... большой текст свёрнут, показать
     
     
  • 15.117, iZEN (ok), 20:29, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Надёжность и самоверифицируемость хранимых данных Если какой-то носитель в избы... большой текст свёрнут, показать
     
  • 10.119, Аноним (-), 21:49, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    XFS - разновидность обычного экстентного аллокатора Просто оптимизанутая на мно... текст свёрнут, показать
     
  • 8.92, Аноним (-), 02:10, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да кужа уж яснее Она болтается как флажок на ветру - Если реализации фичи не п... текст свёрнут, показать
     
  • 2.10, Xasd (ok), 00:11, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока, увы, еле ворочается, по крайней
    > мере, на декстопе :)

    у вас чистый 4.2 ..

    ..оно вполне быстрое, по крайней мере на десктопах.

     
     
  • 3.12, mylefthand (?), 00:21, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Пока, увы, еле ворочается, по крайней
    >> мере, на декстопе :)
    > у вас чистый 4.2 ..
    > ..оно вполне быстрое, по крайней мере на десктопах.

    У меня тоже, может это из-за lzo компрессии

     
  • 2.16, Tav (ok), 02:49, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Использую на ноутбуке несколько месяцев. Выводы противоположные вашим. Сжатие LZO включено (в первую очередь, ради производительности: сокращается объем дискового ввода/вывода).
     
     
  • 3.17, Аноним (-), 02:57, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Косынку раскладываем, по тырнетам лазим? Или может транк GCC компиляем, клонируем, сравниваем по каталогам (> 2 GB исходников). Для косынки любая ФС быстрая.
     
     
  • 4.20, Tav (ok), 03:12, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Разработка, иногда звукозапись (через внешний многоканальный интерфейс). Ноутбук относительно слабый (B940). Я специально измерением и сравнением производительности не занимался. Могу только сказать, что переход с ext4 на btrfs проблем не вызвал и производительность субъективно не ухудшилась.
     
     
  • 5.41, Аноним (-), 14:36, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > и производительность субъективно не ухудшилась.

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

     
     
  • 6.61, Аноним (-), 15:55, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Например интенсивные многопоточные записи

    ...btrfs лю. А остальные - нет.

     
  • 3.23, pro100master (ok), 09:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У меня тоже с выводами было, как у вас :) пока я не заметил, что кубунта обновляется 25 мин, а рядом стоящая кубунта на ext4 - 2 минуты.
     
     
  • 4.26, dalco (ok), 11:12, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Все правильно. При обновлении fsync на fsync'е сидит и fsync'ом погоняет. И для "обычной" FS это правильное поведение. Чем чаще fsync, тем чище попа ;)

    BTRFS же fsync'и не любит, предпочитая, если ничего не путаю, сбрасывать кеши на диск раз в 30 секунд. Вроде как, есть плагин к апдейтеру по имени eatmydata, который резко увеличивает скорость апдейта на btrfs, путем полного игнора запросов на fsync'и от апдейтера.

    P.S. Еще уязвимая точка btrfs - файлы виртуалок. У меня виртуальная 5ая центось около 25 минут грузилась по сравнению с 10 секундами на ext4. Правда, сие было года 2 назад и я больше такого эксперимента не повторял.

    Утверждают, что сейчас подобное поведение немного поправили.

     
     
  • 5.32, Tav (ok), 13:27, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Для образов виртуальных машин в btrfs следует отключать режим COW (chattr +C).
     
     
  • 6.35, Stax (ok), 14:08, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, лишившись всех остальных плюшек в процессе. Почему-то zfs замечательно хостит образы виртуалок в режиме COW (а других там нет - видимо, из-за этого нормально отпимизировали), поддерживает при этом снапшоты и тд.
     
     
  • 7.62, Аноним (-), 15:56, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага, лишившись всех остальных плюшек в процессе.

    Зачем вам снапшоты снапшотов, сэр? :)

     
     
  • 8.65, Аноним (-), 16:43, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Чтоб было, очевидно же В конце концов, в слояровских виртуалках с этим похренов... текст свёрнут, показать
     
     
  • 9.71, Аноним (-), 20:02, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда смиритесь с тем что одна и та же работа многократно размножается Цена ... текст свёрнут, показать
     
  • 5.33, pro100master (ok), 13:42, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    верно, но на январь-май (период моих игр и тестов) проблема сохранялась и советы потюнить мало что дали, и я вернулся к тёплой родной ext, т.к. это не единственная проблема - на огромном количестве файлов сжатие чудит :)
     
  • 5.43, Аноним (-), 14:54, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    У нее sync медленный Но там оно не сильно то и надо там раз в 30 секунд автосн... большой текст свёрнут, показать
     
     
  • 6.66, dalco (ok), 17:01, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Какому именно апдейтеру?

    Ну, изначально речь про убунту шла. У нее apt-get кажись? А вообще, если верить манам, то eatmydata с любой прогой пашет, так что без разницы.


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

    Не уверен на 100%, но в федоре вроде именно так все и делается. К yum'у спец-плагин под это дело примотан в случае работы с btrfs. Я не вникал - обновление работало шустро и надежно, что на ноуте с btrfs, что на серваках/десктопах с ext4. А пока оно нормально работает - о логике той работы особо не задумываешься :)

    >А чего ради так много? Может, логика снапшотирования подралась с CoW логикой? Они делают одно и то же и когда виртуалка CoW-ает свой диск и ФС cow-ает все эти запросы, получается дец в квадрате. Можно попробовать отключить CoW для файлов виртуалки, т.к. большая часть виртуализаторов сами его делают в рамках 1 файла.

    Не, там чего-то глубже. Если ничего не путаю, то надо было с режимами кеширования еще играться (но это я уже потом узнал). А так, интересу ради, подсовывал виртуалке вместо qcow2-формата чистый raw. Тормоза все равно оставались гигантские.

     
     
  • 7.72, Аноним (-), 20:05, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, изначально речь про убунту шла. У нее apt-get кажись?

    Правильно. Правда давать советы даже не зная что за программа - это забавно :)

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

    Зато в случае факапа будет интересно, если не знаешь как вернуть в вид как было или не понимаешь что реверт снапшота откатит ВСЕ файлы :)

    > Не, там чего-то глубже. Если ничего не путаю, то надо было с
    > режимами кеширования еще играться (но это я уже потом узнал).

    Так qcow2 и так тормозит в дефолтном режиме. Known "feature". Надо буферизацию включать. Особенно хорошо с unsafe, но это только с UPS по очевидной причине.

     
     
  • 8.100, dalco (ok), 06:55, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кхм, я разве строил из себя гуру и давал 100 правильные советы Я всего лишь ук... текст свёрнут, показать
     
     
  • 9.102, Аноним (-), 11:23, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Резонно Вот вам плюсик за здравый смысл Ну да Но теряем, так что если клювом ... большой текст свёрнут, показать
     
  • 4.28, Клыкастый (ok), 12:33, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая.
     
     
  • 5.44, Аноним (-), 14:57, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая.

    Опять тут граждане с батхертом. Да, по большинству бенчей ZFS не показывает ничего интересного. Что не удивительно т.к. там какой-то странный аллокатор. Вроде уже не совсем примитивно блочный, но еще не полноценный экстентный. Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет. А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать иногда аж в разы. Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше. На таких тестах продвинутые классики типа ext4/xfs/... рвут всех на британский флаг.

     
     
  • 6.68, Клыкастый (ok), 19:31, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, по большинству бенчей ZFS не показывает ничего интересного.

    (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное говно" svn обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5 минуты. zfs в продакшене молотит и не жужжит, а btrfs вон у товарисча как замечательно отрабатывает. как-то даже и сравниваться страшно, вот точно у кого-то баттхёрт будет.

    > Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет.

    да отлично оно живёт.

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

    как показывает практика полный треш и угар имеет свои корни.

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

    точно! надо челу срочно объяснить что у него с btrfs крайне редкие проблемы! в целом по больнице картина просто замечательная!


     
     
  • 7.73, Аноним (-), 20:17, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, а еще теплое тяжелее мягкого Так btrfs тоже в продакшене молотит и не жужжи... большой текст свёрнут, показать
     
  • 7.75, Аноним (-), 20:29, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А тут все просто Достаточно быть бсдшником и тогда любая окаменелая какашка мам... большой текст свёрнут, показать
     
     
  • 8.79, iZEN (ok), 21:30, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты Иди вон туда http w... текст свёрнут, показать
     
     
  • 9.81, Аноним (-), 22:18, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекц... текст свёрнут, показать
     
     
  • 10.85, Клыкастый (ok), 23:02, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    тут главное не бежать в каноникл а то воткнут тот самый зонд в голову, да не по... текст свёрнут, показать
     
     
  • 11.94, Аноним (-), 02:24, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот уж не подумал бы что каноникал воткнул зонд izen-у и прочим nagual-ам Но су... текст свёрнут, показать
     
     
  • 12.101, Клыкастый (ok), 11:08, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    они бегают анонимом по опеннету да похожесть для всех такая разная ... текст свёрнут, показать
     
     
  • 13.123, Аноним (-), 22:22, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю По описальнику подходят - несут ламерский буллшит с умным видом, а зао... текст свёрнут, показать
     
  • 8.84, Клыкастый (ok), 22:55, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой сочный баттхёрт С какого перепугу Я взял совершенно одинаковые задачи в ... большой текст свёрнут, показать
     
     
  • 9.95, Аноним (-), 03:32, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Считать обычный капитанинг батхертом - оригинально Видимо, реально батхерт Ну ... большой текст свёрнут, показать
     
     
  • 10.106, Клыкастый (ok), 13:53, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Истинно Капитанинг и рядом не стоял сырцы ядра, мира, порты vs портежи расска... большой текст свёрнут, показать
     
  • 4.30, Tav (ok), 13:24, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то делают иначе, либо что-то исправили в btrfs.

    (Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/comments/62

     
     
  • 5.34, pro100master (ok), 13:45, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то
    > делают иначе, либо что-то исправили в btrfs.
    > (Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/comments/62

    OpenSuse тоже себя так ведёт. Проблема не в вендоре :)

     

  • 1.21, deadless (ok), 08:07, 01/10/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков, то результата увеличения производительности можно и вовсе не заметить. Особенно в стандартных юзкейсах btrfs.
     
     
  • 2.27, filosofem (ok), 11:24, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Удаление файлов тоже должно ускориться по идее.
     
  • 2.45, Аноним (-), 14:59, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков,

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

     

  • 1.22, Аноним (-), 08:11, 01/10/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кэши! надо больше кэшей! чего там иноды, надо уже и данные засовывать в кэши!
     
     
  • 2.46, Аноним (-), 15:01, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > данные засовывать в кэши!

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

    Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)

     
     
  • 3.63, iZEN (ok), 16:17, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды?
    > Ну да, не всем в этой жизни везет :)

    Я видел, как в Ubuntu (ещё в версии v.6.06) у меня на 4GB флэшку большой файл копировался в течение нескольких секунд. Правда, потом при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты. Во FreeBSD такого не происходит, но и флэшка не с опцией "sync" подмонтирована, скорость записи нормальная.


     
     
  • 4.77, Аноним (-), 20:41, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты.

    О, еще один неандерталец открыл для себя дисковый буффер.

     
  • 3.67, Аноним (-), 17:44, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)

    Тут у меня после зависания 2 с лишним гигабайта испарились. Но улетали они на диск дольше
    >Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.

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

     
     
  • 4.76, Аноним (-), 20:39, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я не считаю зависания системы нормальной ситуацией, для начала Если система глю... большой текст свёрнут, показать
     
     
  • 5.80, iZEN (ok), 21:40, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает.
    > Ну а так срубилась бы запись на середине файла. Какая нафиг
    > разница - кэшированная запись не успеет дописать файл или некэшированная. С
    > точки зрения порчи файла - одинаково. А вот ждать окончание копирования
    > файла - не особо приятно. Да, надо понимать что такая операция
    > без явного fsync - не является полностью завершенной, хоть и выглядит
    > таковой. Багофича кеширования.

    И много у вас таких "багофич"? Для ZFS нет понятия "не до конца записался файл": он либо записался на диск весь целиком, либо не записался — третьего (промежуточного состояния) не дано, так как природа записи файла на ZFS транзакционна. Если на процессе записи отрубили электричество, то при последующем восстановлении ZFS отмотает лог транзакций на последнюю транзакцию, освободит пространство от мусора и будет целостной и непротиворечивой. Но это не значит, что открытые на запись файлы обнулятся (как в XFS или Ext4 в ранних версиях), а будут лежать те версии файлов, которые были ДО сбоя питания. То же самое с UFS2+SU(J), у которой fsck освобождает свободное пространство от мусора (вследствие незавешённых транзакций), фактически актуализируя последний снапшот перед сбоем ФС, в котором все транзакции подтверждены, а данные заморожены.

     
     
  • 6.82, Аноним (-), 22:20, 01/10/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И много у вас таких "багофич"? Для ZFS нет понятия "не до
    > конца записался файл": он либо записался на диск весь целиком, либо
    > не записался — третьего (промежуточного состояния) не дано

    Говоришь, нет кэширования на запись? Ну-ну.

     
     
  • 7.97, Аноним (-), 03:43, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Говоришь, нет кэширования на запись? Ну-ну.

    Он просто еще не понял что в указанной им ситуаци на CoW-based ФС при этом файл вообще не будет существовать. Просто потому что дописаться не успел, а значит "его вообще не существовало".

     
  • 6.96, Аноним (-), 03:42, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > конца записался файл": он либо записался на диск весь целиком, либо
    > не записался — третьего (промежуточного состояния) не дано,

    Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый. Ты доволен? :)

     
     
  • 7.104, iZEN (ok), 12:04, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> конца записался файл": он либо записался на диск весь целиком, либо
    >> не записался — третьего (промежуточного состояния) не дано,
    > Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый.
    > Ты доволен? :)

    Тот, который писался с нуля и незавершилась транзакция по его записи? Испарился — прекрасно, так как не нужно разгребать весь тот бред, что записалось, а что нет.
    Недописанный в транзакции файл будет оставаться в том состоянии, в котором его оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС?


     
     
  • 8.120, Аноним (-), 21:54, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это даже не столько к ФС сколько к общему свойству CoW механики Как-то сильно п... текст свёрнут, показать
     
  • 6.98, Аноним (-), 03:45, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > освободит пространство от мусора и будет целостной и непротиворечивой.

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

     
     
  • 7.105, iZEN (ok), 12:17, 02/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> освободит пространство от мусора и будет целостной и непротиворечивой.
    > Ты не поверишь, но btrfs делает примерно то же самое.

    С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть ли не в каждом посте о достоинствах Btrfs приводите это как полезную фичу :) Заметьте, я не предлагаю повсеместно вырубать проверку чексумм на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) )

    > Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а
    > идея в целом - меняется мало.

    Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck. Включение журналирования всего и вся приводит к ощутимым тормозам. А вот в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение журналирования на томе с UFS2+SU позволяет привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись. Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.


     
     
  • 8.116, qux (ok), 14:20, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А ведь еще когда предупреждали 8212 не надо говорить за всю сеть ... текст свёрнут, показать
     
     
  • 9.122, Аноним (-), 22:16, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это изен Тупо лажаться - его фирменный стиль ... текст свёрнут, показать
     
  • 8.121, Аноним (-), 22:13, 03/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это полезная фича для очень нишевых применений Которые сами себя журналят и пот... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру