Мяо Се (Miao Xie), известный своей работой (http://www.opennet.me/opennews/art.shtml?num=33132) по оптимизации Btrfs, опубликовал (http://www.spinics.net/lists/linux-btrfs/msg19182.html) в списке рассылки разработчиков файловой системы Btrfs набор патчей с реализацией системы кэширования буфера экстентов, позволяющий существенно сократить время поиска в дереве b+ и уменьшить продолжительность пребывания буфера экстентов в состоянии блокировки, благодаря повторному использованию результатов прошлого поиска. Итогом использования патчей является общее увеличение производительности операций с метаданными. Например, в тесте на создание 100 тыс файлов в 10 параллельных потоков наблюдается ускорение на 20%.URL: http://www.spinics.net/lists/linux-btrfs/msg19182.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34973
хм... начиная читать думал там цифра будет не 20, а 200%, начало было куда более оптимистичным..
А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.
"Сперва добейся" - это убербаян. В следующий раз попытайтесь быть пооригинальнее.
Еще несколько "заплюсовавших" "ценителей" чужого труда поддерживают вашу точку зрения. Поздравляю, только громче кричите "убербаян", а то разумные мнения все еще слышны.
Не нужно быть поваром, чтобы оценить яичницу, - обтекайте
> Не нужно быть поваром, чтобы оценить яичницу, - обтекайтеНужно. Потому что не-повара могут высказать мнение, которое лично мне не нравится. Это весомый аргумент, я полагаю?
вот это бред
>Нужно. Потому что не-повара могут высказать мнение, которое лично мне не нравится. Это весомый аргумент, я полагаю?Даа, "повар лучше знает", "продавец лучше знает" и т.д и т.п. - попахивает классическим совковым маразмом
> Не нужно быть поваром, чтобы оценить яичницу, - обтекайтеИ не нужно быть баянистом, чтобы оценивать игру на рваном баяне.
> , -Да, вот это я понимаю, обтекание. В русском языке нет такого синтаксиса.
На самом деле, есть. Эпик.
> На самом деле, есть. Эпик.Epic fail вы хотели сказать? :)
> Не нужно быть поваром, чтобы оценить яичницу, - обтекайтеВ соседней ветке новый ролик от создателей blender оценили, как "графан слабоват".
И правда, в мстителях графан покруче.
И зачем вникать, что бюджеты этих двух проектов астрономически различаются?
>> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте
> В соседней ветке новый ролик от создателей blender оценили, как "графан слабоват".
> И правда, в мстителях графан покруче.
> И зачем вникать, что бюджеты этих двух проектов астрономически различаются?Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, и для кого "графан слабоват" буду отвечать в вашем же стиле "а вы на бюджет посмотрите" =)
> Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю,
> и для кого "графан слабоват" буду отвечать в вашем же стиле
> "а вы на бюджет посмотрите" =)Точку любой аноним поставить может.
Почему-то никто не хочет смотреть на соотношение выхлопа к затратам.
> Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю,А я бесплатно могу, так что вы неэффективный просаживатель бабла. А вот например нанесение вполне себе сложного граффити на стену - дается уже немногим.
будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности.ЗЫ я не кометентен в оптимизациях, но компетентен в решении конфликтов: срач ты слил можешь заворачиваться в пижамку.
> будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности.В вопросе баянов я вполне компетентен, как и любой интернет-пользователь.
> я не кометентен в оптимизациях
ЧИТД
> ЗЫ я не кометентен в оптимизациях,Былинный отказ :)
> "Сперва добейся" - это убербаян.Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать.
> Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать.Да, говорить правду легко и приятно.
> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет право утверждать "а король-то голый"?
> А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет
> право утверждать "а король-то голый"?Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть он и не авторитет в этой области, а лишь толстый тролль. Ну что ж, с мнением Анонима нужно считаться.
> Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть
> он и не авторитет в этой области, а лишь толстый тролль.
> Ну что ж, с мнением Анонима нужно считаться.Если истинность этого мнения очевидна - то почему бы и нет?
Не важно, _кто_ говорит. Важно, _что_ говорит.
>> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.
> А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет
> право утверждать "а король-то голый"?нет но эксперт по голым людям, очевидно же!
> нет но эксперт по голым людям, очевидно же!Значит, если люди видят, что король голый - это ничего не значит, пока не придет дипломированный эксперт по голым людям (видимо, патологоанатом) и не вынесет экспертное суждение?
> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.Бесспорно, достойный результат, но... вообще-то это выигрыш в одном конкретном тесте. Причем, видать, в таком, который показывает наиболее выигрышный результат. Не очень часто массированно приходится делать такое - "создание 100 тыс файлов в 10 параллельных потоков". Почему не приведены результаты еще каких-то тестов? Вдруг в каких-то вариантах использования и регресс может наблюдаться?
> Не очень часто массированно приходится делать такое - "создание 100 тыс файлов в 10
> параллельных потоков".Загрузка фоток пользователями?)
Просто изначально нужно писать правильно. А точнее не писать, а для начала разработать.
Просто наиболее явные места уже заоптимизировали. Так что находить места, где доработка алгоритма дает большой выигрыш, становится все труднее.Ваш К.О.
P.S. Если верить рассылке, то эту самую оптимизацию в свою очередь тоже уже оптимизировали. :)
> уже оптимизировали. :)Оптимизация оптимизации оптимизаци... wait, oh sh--!
когда дело касается файловых систем. +20% к производительности, это просто огромный прирост.
не просто +20% к производительност -- а именно "в тесте на создание 100 тыс файлов в 10 параллельных потоков"а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-)
Ты под досом до сих пор сидишь?
> а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-)Их даже почти наверняка не будет т.к. как правило большую часть времени ФС вообще ничего не делает. А 20% от нуля - и так и эдак ноль.
> Их даже почти наверняка не будет т.к. как правило большую часть времени
> ФС вообще ничего не делает. А 20% от нуля - и
> так и эдак ноль.Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно.
Вы случайно не Джеф Бонвик?
> Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно.Я всего лишь подшучиваю над теми кто полагает что оптимизации не требуются и/или будут не видны.
> Вы случайно не Джеф Бонвик?
Да что уж там, Шишкиным сразу называйте. Я тогда спецом для вас сделаю том из одних метаданных и буду вопить про то как btrfs отстоен. Ведь на reiser можно запихнуть в два раза больше пустых файлов :)
зато когда потоков будет уже 100 - можно заиметь провал в производительности.. Но видимо это "оптимизаторов" не отпугивает :)
> зато когда потоков будет уже 100 - можно заиметь провал в производительности..А где бенчи на 100 потоков?
ну там и 2000% мало будет. Пока, увы, еле ворочается, по крайней мере, на декстопе :)
Хотели _полный_ аналог ZFS? Получите и распишитесь.
Осталось только жрач памяти допилить, а то отстает ведь.
>Хотели _полный_ аналог ZFS?А фоновое шифрование когда будет?
А "фоновое шифрование" - это как?По идее, если возникла необходимость в шифровке данных, то их шифровать надо сразу же при сбросе на диск, а не надеяться, что часиков через надцать их какой-нибудь фоновый процесс таки зашифрует и тогда данные точно будут в безопасности.
Или я все не так понял?
Конечно неправильно, все данные попадают на диск уже зашифрованными)
> А фоновое шифрование когда будет?Когда выйдет проприетарная версия.
> Когда выйдет проприетарная версия.Проприетарная версия GPLнутого кода? Это как? :)
А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?
у мня есть raid6, могу поставить btrfs, только зачем мне там еще raid5?
> А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?А как насчет trim и нормальных экстентных аллокаторов? :)
>> А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?
> А как насчет trim и нормальных экстентных аллокаторов? :)В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.
Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят: http://svnweb.freebsd.org/base?view=revision&revision=240868
> В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.В btrfs они есть изначально :)
А ZFS даже экстентов нет, так что она сoсет не нагибаясь.
> Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят:Да, таскать "кривые ненужные костыли из линyпса" любой дурак может.
А вот утащить фоновое шифрование из проприетарной солярки - слабо.
> В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да.Там то они как раз есть.
> Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux
Вот это я и называю ZFSLoL :)
> принят: http://svnweb.freebsd.org/base?view=revision&revision=240868
Ну так и сабжевый патч принят. И чего?
>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принятА говорил не нужно, да. Оказалось просто запилить было некому.
>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят
> А говорил не нужно, да. Оказалось просто запилить было некому.Давай яснее определю свою позицию по поводу TRIM.
Для задач, которым важен большой размер блока ФС, совпадающий с размером блока SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен.
Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки ФС поменьше (128k), TRIM ускорит операции записи.
>>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят
>> А говорил не нужно, да. Оказалось просто запилить было некому.
> Давай яснее определю свою позицию по поводу TRIM.
> Для задач, которым важен большой размер блока ФС, совпадающий с размером блока
> SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен.
> Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки
> ФС поменьше (128k), TRIM ускорит операции записи.Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС не реализует элементарную функцию, это жестоко.
> Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС
> не реализует элементарную функцию, это жестоко.Это изен и это далеко не самый мощный маразм который он может выдать :)
>>>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят
>>> А говорил не нужно, да. Оказалось просто запилить было некому.
>> Давай яснее определю свою позицию по поводу TRIM.
>> Для задач, которым важен большой размер блока ФС, совпадающий с размером блока
>> SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен.
>> Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки
>> ФС поменьше (128k), TRIM ускорит операции записи.
> Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС
> не реализует элементарную функцию, это жестоко.На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование больших блоков ФС скорее благо, чем из ряда вон выходящее явление. Среди линуксовых ФС, пожалуй, только XFS заточена под такое [целевое] использование.
> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.Напоминаю, TRIM это для SSD. =)
>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.
> Напоминаю, TRIM это для SSD. =)SSD не используется для видеомонтажа? Странно. Не знал.
>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.
>> Напоминаю, TRIM это для SSD. =)
> SSD не используется для видеомонтажа? Странно. Не знал.ZFS годится только для видеомонтажа, буду знать.
>>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
>>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.
>>> Напоминаю, TRIM это для SSD. =)
>> SSD не используется для видеомонтажа? Странно. Не знал.
> ZFS годится только для видеомонтажа, буду знать.И под файлопомойку тоже — отметьте там у себя.
>>>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
>>>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.
>>>> Напоминаю, TRIM это для SSD. =)
>>> SSD не используется для видеомонтажа? Странно. Не знал.
>> ZFS годится только для видеомонтажа, буду знать.
> И под файлопомойку тоже — отметьте там у себя.Для помойки что она даёт эксклюзивного? Дедупликацию и RAID5.
С дедупликацией те же вилы, что и с отсутствием TRIM. Если используем нормальный размер блока, получаем терабайт сожранной RAM и тормоза, если используем дикий полумегабайтный блок(на файлопомойке! =), то не получаем никакой экономии от дедупликации.
Рейд-Z встроенный это конечно удобно, но учитывая, что жрёт ресурсов на объёмах в десятки терабайт ZFS в разы больше, чем MD+((LVM+ext4)|btrfs), а производительность и надёжность настолько же ниже, то возникает резонный влпрос: зачем?
Короче тот же вывод, что и с видеомонтажом: использовать конечно можно, но однозначных преимуществ над нормальными FS нет, а недостатки перевешивают.
ZFS можно порекомендовать только неосилившим MD, dm-crypt и LVM, потому что ZFS-хранилище поднять и админить сможет и макака. При условии, конечно, что нет ограничений на выбор железа. И только для названных специфичных юзкейсов.
>>>>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование
>>>>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление.
>>>>> Напоминаю, TRIM это для SSD. =)
>>>> SSD не используется для видеомонтажа? Странно. Не знал.
>>> ZFS годится только для видеомонтажа, буду знать.
>> И под файлопомойку тоже — отметьте там у себя.
> Для помойки что она даёт эксклюзивного?Надёжность и самоверифицируемость хранимых данных. Если какой-то носитель в избыточном массиве начинает "сыпаться", то ZFS на лету исправляет ошибки. Когда такой носитель совсем помирает, то ZFS сигнализирует о потере бойца, но не данных.
> Дедупликацию и RAID5.
Не только, а всё что угодно, согласно свойствам этой замечательной ФС.
> С дедупликацией те же вилы, что и с отсутствием TRIM. Если используем
> нормальный размер блока, получаем терабайт сожранной RAMСтранно. Мне несколько гигабайт ОЗУ хватает для трёх пулов.
> и тормоза, если используем
> дикий полумегабайтный блок(на файлопомойке! =), то не получаем никакой экономии от
> дедупликации.Дедупликация нужна если в отдельных ФС пула содержаться одни и те же данные. Например, на хосте с виртуальными машинами это бы пригодилось. Но зачем это файлопомойке? Наверно на случай слишком забывчивого администратора, который всё время забывает, какие файлы и где у него лежат. Так выходит, что пул у него "резиновый". :))
> Рейд-Z встроенный это конечно удобно, но учитывая, что жрёт ресурсов на объёмах
> в десятки терабайт ZFS в разы больше, чем MD+((LVM+ext4)|btrfs), а производительность
> и надёжность настолько же ниже, то возникает резонный влпрос: зачем?Потребление памяти в ZFS не зависит от размера пула, а зависит от объёма востребованных данных. Про надёжность зря сморозили. Очень зря.
> Короче тот же вывод, что и с видеомонтажом: использовать конечно можно, но
> однозначных преимуществ над нормальными FS нет, а недостатки перевешивают.Вывод из ошибочных посылок впечатляет.
> ZFS можно порекомендовать только неосилившим MD, dm-crypt и LVM,
А для осиливших GEOM можно порекомендовать? :)) Спасибо.
> потому что ZFS-хранилище поднять и админить сможет и макака.
Как-то против сделанного вывода. Но да ладно — макаки за компьютером как-то не прижились. Или вы их видели среди клиентов Oracle?
> Среди линуксовых ФС, пожалуй, только XFS заточена под такое [целевое] использование.XFS - разновидность обычного экстентного аллокатора. Просто оптимизанутая на многопоточность и многодисковые конфиги за счет allocation groups. А на однодисковой конфиге - оно сравнимо с иными экстентными по свойствам, тем же ext4 например. Ну с точностью до разницы в ряде алгоритмов/метаданных.
Понимаешь, экстентом можно сразу заказать 100500 килобайтов. А не блоками. Особенно хорошо если есть такой непрерывный блок свободного места. Может прямо 1 операцией и заадресоваться, тогда как блочник будет дрюкаться с пометкой кучи блоков как занятых. На чем и протормозит. Теперь ты понимаешь почему экстенты - это суперсет блоков переменного размера? :)
> Давай яснее определю свою позицию по поводу TRIM.Да кужа уж яснее? Она болтается как флажок на ветру:
- Если реализации фичи не предвидится в ближайшем будущем - "это не нyжно, понты и навороты!"
- Если фичу вот-вот сделают - "все у кого нет этой фичи - лох!"Куда уж проще и понятнее, стандартная логика пионерии от бсд :)
> Пока, увы, еле ворочается, по крайней
> мере, на декстопе :)у вас чистый 4.2 ..
..оно вполне быстрое, по крайней мере на десктопах.
>> Пока, увы, еле ворочается, по крайней
>> мере, на декстопе :)
> у вас чистый 4.2 ..
> ..оно вполне быстрое, по крайней мере на десктопах.У меня тоже, может это из-за lzo компрессии
Использую на ноутбуке несколько месяцев. Выводы противоположные вашим. Сжатие LZO включено (в первую очередь, ради производительности: сокращается объем дискового ввода/вывода).
Косынку раскладываем, по тырнетам лазим? Или может транк GCC компиляем, клонируем, сравниваем по каталогам (> 2 GB исходников). Для косынки любая ФС быстрая.
Разработка, иногда звукозапись (через внешний многоканальный интерфейс). Ноутбук относительно слабый (B940). Я специально измерением и сравнением производительности не занимался. Могу только сказать, что переход с ext4 на btrfs проблем не вызвал и производительность субъективно не ухудшилась.
> и производительность субъективно не ухудшилась.А оно местами выигрывает, местами проигрывает, так что впечатления от задач сильно зависят. Например интенсивные многопоточные записи
> Например интенсивные многопоточные записи...btrfs лю. А остальные - нет.
У меня тоже с выводами было, как у вас :) пока я не заметил, что кубунта обновляется 25 мин, а рядом стоящая кубунта на ext4 - 2 минуты.
Все правильно. При обновлении fsync на fsync`е сидит и fsync`ом погоняет. И для "обычной" FS это правильное поведение. Чем чаще fsync, тем чище попа ;)BTRFS же fsync`и не любит, предпочитая, если ничего не путаю, сбрасывать кеши на диск раз в 30 секунд. Вроде как, есть плагин к апдейтеру по имени eatmydata, который резко увеличивает скорость апдейта на btrfs, путем полного игнора запросов на fsync`и от апдейтера.
P.S. Еще уязвимая точка btrfs - файлы виртуалок. У меня виртуальная 5ая центось около 25 минут грузилась по сравнению с 10 секундами на ext4. Правда, сие было года 2 назад и я больше такого эксперимента не повторял.
Утверждают, что сейчас подобное поведение немного поправили.
Для образов виртуальных машин в btrfs следует отключать режим COW (chattr +C).
Ага, лишившись всех остальных плюшек в процессе. Почему-то zfs замечательно хостит образы виртуалок в режиме COW (а других там нет - видимо, из-за этого нормально отпимизировали), поддерживает при этом снапшоты и тд.
> Ага, лишившись всех остальных плюшек в процессе.Зачем вам снапшоты снапшотов, сэр? :)
> Зачем вам снапшоты снапшотов, сэр? :)Чтоб было, очевидно же.
В конце концов, в слояровских виртуалках с этим похреновее, чем в линуксовых, вот и приходится изворачиваться.
> Чтоб было, очевидно же.Ну тогда смиритесь с тем что одна и та же работа многократно размножается. Цена наложения двух CoW друг на друга.
> В конце концов, в слояровских виртуалках с этим похреновее, чем в линуксовых,
> вот и приходится изворачиваться.Да не надо изворачиваться, надо просто научиться не забивать гвозди микроскопом. Не все технологии удачно сочетаются между собой во всех вариантах. Никто же не жалуется что плавиковая кислота хреново хранится в железной канистре, правда? :)
верно, но на январь-май (период моих игр и тестов) проблема сохранялась и советы потюнить мало что дали, и я вернулся к тёплой родной ext, т.к. это не единственная проблема - на огромном количестве файлов сжатие чудит :)
> BTRFS же fsync`и не любит, предпочитая, если ничего не путаю, сбрасывать кеши
> на диск раз в 30 секунд.У нее sync медленный. Но там оно не сильно то и надо: там раз в 30 секунд автоснапшот делается. В случае факапа оно просто отмотает на этот автоснапшот. По сути напрашивается иная семантика доступа к ФС, с учетом того что ФС способна честно журналировать да еще делает это в виде множественных автоснапшотов.
> Вроде как, есть плагин к апдейтеру по имени eatmydata,
Какому именно апдейтеру?
> который резко увеличивает скорость апдейта на btrfs, путем полного игнора
> запросов на fsync`и от апдейтера.Вообще, в случае btrfs умной идеей было бы сделать на автомате чекпойнт до начала апдейтов -> вкатить все асинхронно и без fsync -> готово. В случае факапа просто откат на чекпойнт. Ну может еще раздестроить чекпойнт чтобы место не жралось. Все. Fsync там вообще для ФС типа ext4 и подобных, которые честно не журналят так что половина журнальной логики сбагрена на апликухи получается.
> P.S. Еще уязвимая точка btrfs - файлы виртуалок. У меня виртуальная 5ая
> центось около 25 минут грузиласьА чего ради так много? Может, логика снапшотирования подралась с CoW логикой? Они делают одно и то же и когда виртуалка CoW-ает свой диск и ФС cow-ает все эти запросы, получается дец в квадрате. Можно попробовать отключить CoW для файлов виртуалки, т.к. большая часть виртуализаторов сами его делают в рамках 1 файла.
>Какому именно апдейтеру?Ну, изначально речь про убунту шла. У нее apt-get кажись? А вообще, если верить манам, то eatmydata с любой прогой пашет, так что без разницы.
>Вообще, в случае btrfs умной идеей было бы сделать на автомате чекпойнт до начала апдейтов -> вкатить все асинхронно и без fsync -> готово. В случае факапа просто откат на чекпойнт. Ну может еще раздестроить чекпойнт чтобы место не жралось. Все. Fsync там вообще для ФС типа ext4 и подобных, которые честно не журналят так что половина журнальной логики сбагрена на апликухи получается.Не уверен на 100%, но в федоре вроде именно так все и делается. К yum`у спец-плагин под это дело примотан в случае работы с btrfs. Я не вникал - обновление работало шустро и надежно, что на ноуте с btrfs, что на серваках/десктопах с ext4. А пока оно нормально работает - о логике той работы особо не задумываешься :)
>А чего ради так много? Может, логика снапшотирования подралась с CoW логикой? Они делают одно и то же и когда виртуалка CoW-ает свой диск и ФС cow-ает все эти запросы, получается дец в квадрате. Можно попробовать отключить CoW для файлов виртуалки, т.к. большая часть виртуализаторов сами его делают в рамках 1 файла.
Не, там чего-то глубже. Если ничего не путаю, то надо было с режимами кеширования еще играться (но это я уже потом узнал). А так, интересу ради, подсовывал виртуалке вместо qcow2-формата чистый raw. Тормоза все равно оставались гигантские.
> Ну, изначально речь про убунту шла. У нее apt-get кажись?Правильно. Правда давать советы даже не зная что за программа - это забавно :)
> пока оно нормально работает - о логике той работы особо не задумываешься :)
Зато в случае факапа будет интересно, если не знаешь как вернуть в вид как было или не понимаешь что реверт снапшота откатит ВСЕ файлы :)
> Не, там чего-то глубже. Если ничего не путаю, то надо было с
> режимами кеширования еще играться (но это я уже потом узнал).Так qcow2 и так тормозит в дефолтном режиме. Known "feature". Надо буферизацию включать. Особенно хорошо с unsafe, но это только с UPS по очевидной причине.
>Правильно. Правда давать советы даже не зная что за программа - это забавно :)Кхм, я разве строил из себя гуру и давал 100% правильные советы? Я всего лишь указал - в какую сторону копать. А кому это действительно необходимо, прочтет маны и сделает все по правилам. ;)
>Зато в случае факапа будет интересно, если не знаешь как вернуть в вид как было или не понимаешь что реверт снапшота откатит ВСЕ файлы :)
Нифига. Во-первых, откат пройдет на состояние до запуска yum`а, то есть теряем результаты, максимум пары минут работы. Во-вторых, все реально ценные файлы лежат в сетевом хранилище. То есть их откат снапшота вообще не коснется.
В-последних, в случае факапа, я просто переброшу виртуалки на другую ноду и не напрягаясь буду решать проблему (например, тупо залью сервак с нуля минут за 20-30, попивая чай).>Так qcow2 и так тормозит в дефолтном режиме. Known "feature". Надо буферизацию включать. Особенно хорошо с unsafe, но это только с UPS по очевидной причине.
Не знаю, на ext4 тот же qcow2 обеспечивал запись/чтение порядка 30-40Мб/сек. При абсолютно таком же конфиге, но с томом под btrfs скорость иногда падала до 80-100 КИЛОбайт/секунду. Именно поэтому я пока отказался от btrfs для решения своих задач.
> Кхм, я разве строил из себя гуру и давал 100% правильные советы?
> Я всего лишь указал - в какую сторону копать. А кому это действительно
> необходимо, прочтет маны и сделает все по правилам. ;)Резонно. Вот вам плюсик за здравый смысл.
> Нифига. Во-первых, откат пройдет на состояние до запуска yum`а, то есть теряем
> результаты, максимум пары минут работы.Ну да. Но теряем, так что если клювом клац-клац и не осознать этот факт - можно и обломаться немного :)
> Во-вторых, все реально ценные файлы лежат в сетевом хранилище.
Ну это у вас лежат. А у остальных не обязаны.
> В-последних, в случае факапа, я просто переброшу виртуалки на другую ноду и
> не напрягаясь буду решать проблему (например, тупо залью сервак с нуля
> минут за 20-30, попивая чай).Ну дык. Для серваков это нормально. А для десктопа? :)
> Не знаю, на ext4 тот же qcow2 обеспечивал запись/чтение порядка 30-40Мб/сек. При
> абсолютно таком же конфиге,Там еще в ext4 помнится одно время был чит с delayed allocation и прочая, достаточно чреватый в случае факапов.
> но с томом под btrfs скорость иногда падала до 80-100 КИЛОбайт/секунду.
> Именно поэтому я пока отказался от btrfs для решения своих задач.Подозреваю что дело в CoW который журналил CoW + медленном sync у этой ФС. Первое чинится отключением CoW для файла. Со вторым помнится недавно активно боролись.
вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая.
> вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая.Опять тут граждане с батхертом. Да, по большинству бенчей ZFS не показывает ничего интересного. Что не удивительно т.к. там какой-то странный аллокатор. Вроде уже не совсем примитивно блочный, но еще не полноценный экстентный. Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет. А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать иногда аж в разы. Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше. На таких тестах продвинутые классики типа ext4/xfs/... рвут всех на британский флаг.
> Да, по большинству бенчей ZFS не показывает ничего интересного.(задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное говно" svn обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5 минуты. zfs в продакшене молотит и не жужжит, а btrfs вон у товарисча как замечательно отрабатывает. как-то даже и сравниваться страшно, вот точно у кого-то баттхёрт будет.
> Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет.
да отлично оно живёт.
> А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать иногда аж в разы.
как показывает практика полный треш и угар имеет свои корни.
> Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше.
точно! надо челу срочно объяснить что у него с btrfs крайне редкие проблемы! в целом по больнице картина просто замечательная!
> (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное гoвно" svn обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5 минуты.Да, а еще теплое тяжелее мягкого.
> zfs в продакшене молотит и не жужжит, а btrfs вон у товарисча как замечательно отрабатывает
Так btrfs тоже в продакшене молотит и не жужжит, а zfs вон у [кого-то там] замечательно отрабатывает.
Использованные вами "критерии" растяжимы, как презерватив, и поэтому их можно без проблем натянуть практически на все, что угодно.
> точно! надо челу срочно объяснить что у него с btrfs крайне редкие проблемы! в целом по больнице картина просто замечательная!
Мне давеча адепты ZFS то же самое про свою любимую лечили.
> (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное гoвно" svn
> обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за
> 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5
> минуты. zfs в продакшене молотит и не жужжит, а btrfs вон
> у товарисча как замечательно отрабатывает. как-то даже и сравниваться страшно, вот
> точно у кого-то баттхёрт будет.А тут все просто. Достаточно быть бсдшником и тогда любая окаменелая какашка мамонта превращается в мегарулез. Синдром "свое не пахнет" - во весь рост.
Во первых, вы не удосужились даже просто взять одинаковый набор файлов...
Во вторых, git - система контроля версий а не файлокачалка. Он качает всю историю изменений, как минимум по дефолту. Нормально, сравнили дельтаплан с боингом. А ничего что у них функционал разный? Если сравнивать workflow типичный для системы контроля версий - так SVN затрахаешься использовать. По прямому назначению ака отмотать туда-сюда версии файлов.
В третьих, ни звука не сказано про конфигурацию ремотных серверов и нагрузку на оные. Мало ли, может у одних там первопень скрипит диском а вторые отбабахали 16-процессорный монстр с 256 гиг оперативы?
В четвертых, может так оказаться что ваша бсда неуловимый джо и там просто мало изменений, например. А в той же генте их может оказаться в 100500 раз больше. И почему они при таком раскладе не должны дольше синхронизироваться?
К чему это я? Да к тому что для начала сравнение надо делать в идентичной конфигурации. С повторимыми условиями. Чтобы отсеять лишние факторы. И наверное надо использовать инструменты по назначению. Хотя извращенцам делающим из системы контроля версий файлопомойку наверное сложно понять что система контроля версий должна быть удобна разработчикам, а не файловарезокачателям.
> да отлично оно живёт.
Только почему-то бенчмарки это не подтверждают. Хотя если 100500Гб оперативки вбить - ну а чо, рамдиски они быстрые. И то - там где ext4 даст гиг в секунду, zfs спасибо если 300Мб/сек. Отлично от других - это да. Дефрага нет? Не беда! Не умеет trim - и красный чертик с ним! И вот как-то так у бсдшников везде.
Вывод: freebsd - отличная система. Если очень аккуратно подбирать задачи под систему. А не систему под задачи, как это делают все нормальные люди :)
>> А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать
>> иногда аж в разы.
> как показывает практика полный треш и угар имеет свои корни.Да, но бсдшники почему-то склонны замечать только чужой трэш и угар, упорно игнорируя все бревна в своих глазах и все сильные стороны конкурентов. Ну бывает, да.
>> Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше.
> точно! надо челу срочно объяснить что у него с btrfs крайне редкие
> проблемы! в целом по больнице картина просто замечательная!Ну а кто виноват что оно как-то так и есть? Под большинством нагрузок btrfs выглядит весьма культурно и является сильным соперником. А так вон zfs на ряде бенчмарков сливается. Давайте ее за никакой TPS в одном из тестов фороникса польем? А что, тоже нишевой случай как раз :)
> Ну а кто виноват что оно как-то так и есть? Под большинством
> нагрузок btrfs выглядит весьма культурно и является сильным соперником. А так
> вон zfs на ряде бенчмарков сливается. Давайте ее за никакой TPS
> в одном из тестов фороникса польем? А что, тоже нишевой случай
> как раз :)Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты. Иди вон туда: http://www.youtube.com/watch?v=1mGzCmcKThU и популярно объясни парням-насостроителям, что ZFS не нужна и сливает по характеристикам горячо любимой Btrfs и даже Ext4. Может они проникнутся и поставят себе GNU/Linux с последними патчами Btrfs вместо убогой FreeBSD.
> Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты. Иди вон
> туда: http://www.youtube.com/watch?v=1mGzCmcKThU и популярно объясни парням-насостроителям,
> что ZFS не нужна и сливает по характеристикам горячо любимой Btrfs
> и даже Ext4. Может они проникнутся и поставят себе GNU/Linux с
> последними патчами Btrfs вместо убогой FreeBSD.Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекций.
> Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекций.тут главное не бежать в каноникл. а то воткнут тот самый зонд в голову, да не помыв, и будешь анонимом на опеннете скитаться, всех кто растопырки в голове хаять
> тут главное не бежать в каноникл. а то воткнут тот самый зонд
> в голову, да не помыв, и будешь анонимом на опеннете скитаться,
> всех кто растопырки в голове хаятьВот уж не подумал бы что каноникал воткнул зонд izen-у и прочим nagual-ам. Но судя по описанию чертовски похоже.
> Вот уж не подумал бы что каноникал воткнул зонд izen-у и прочим
> nagual-ам. Но судя по описанию чертовски похоже.они бегают анонимом по опеннету? да... похожесть для всех такая разная...
> они бегают анонимом по опеннету?Не знаю.
> да... похожесть для всех такая разная...
По описальнику подходят - несут ламерский буллшит с умным видом, а заодно меняют точку зрения на 180 градусов узнав о том что в ZFS из линуксного (sic!) варианта портирован trim.
> А тут все просто. Достаточно быть бсдшникомКакой сочный баттхёрт.
> Во первых, вы не удосужились даже просто взять одинаковый набор файлов...
С какого перепугу? Я взял совершенно одинаковые задачи в системах одного типа (source based).
svn up /usr/src && portsnap fetch update
eix-syncи сравнил. Да, канал - одинаковый, а машинки сильно разные, фря на слабой.
> Во вторых, git - система контроля версий а не файлокачалка.да мне как-то пофиг. пока портежи не перевёл на git было ещё медленнее.
> Он качает всю историю изменений, как минимум по дефолту.
с таким баттхёртом в тему FreeBSD переходит на svn. Там вы шизофренично будете спорить с теми, кто говорит что git удобнее.
> Нормально, сравнили дельтаплан с боингом. А ничего что у них функционал разный?
да мне как-то параллельно. я по svn/git забираю исходники/портежи.
> В третьих, ни звука не сказано про конфигурацию ремотных серверов и нагрузку на оные.
бсдшник естественно любит говно мамонта, наивно даже предположить, что у них стоит что-то современнее 8086. Были 80286, но их забрали проприетарщики, когда приходили вытирать о бсдшников ноги. да и всем убунтоидам известно, что фря на другом и не запускается. опять же тормозная ZFS.
> Мало ли, может у одних там первопень скрипит диском а вторые отбабахали 16-процессорный монстр с 256 гиг оперативы?
у линуксоидов? естественно. и btrfs!
> В четвертых, может так оказаться что ваша бсда неуловимый джо и там просто мало изменений, например.
странно, что такая простая отмазка не пришла сразу. но только она не катит: порты с портежами вполне сравнимы, ядро линуксовое прилетает тарболом. так что изменения в мире, ядре, портах > чем в портежах. увы и ах.
> К чему это я? Да к тому что для начала сравнение надо делать в идентичной конфигурации. С повторимыми условиями.
Ступай в фороникс, там будешь городить условия какие захочешь. Я выполняю штатные сходные задачи штатными методами.
> Только почему-то бенчмарки это не подтверждают.Мне на них не работать.
> И вот как-то так у бсдшников везде.
Ну это да. Только глубокое личное знание вызвало к жизни сии сентенции, вовсе не попаболь, нет.
> А не систему под задачи, как это делают все нормальные люди :)
Стесняюсь спросить, вы можете назвать задачи, для которых лично вы выберете FreeBSD, или даже после потыкивания носиком в преимущества будете утверждать, что Линукс лучше во всём?
> Да, но бсдшники почему-то склонны замечать только чужой трэш и угар,
вообще-то я не о том говорил. и вообще-то бсдшники крайне разные. но наличие "чужого треша и угара" вы зафиксировали, да. уже неплохо.
> упорно игнорируя все бревна в своих глазах и все сильные стороны конкурентов.
отнюдь. причём достаточно взглянуть на грызню фанатов разных дистров, чтобы понять. что бсдшники тут просто дилетанты.
>> проблемы! в целом по больнице картина просто замечательная!
> Ну а кто виноват что оно как-то так и есть?вот действительно. фс на десктопе это крайне нишевый случай. 1 на миллион.
> Под большинством нагрузок btrfs выглядит весьма культурно и является сильным соперником. А так вон zfs на ряде бенчмарков сливается.дык я про то же. неясно так получается. в жизни всё отлично в бенчах как-то не очень. а btrfs - как-то наоборот ;)
> Какой сочный бaттхёрт.Считать обычный капитанинг батхертом - оригинально! Видимо, реально батхерт.
>> Во первых, вы не удосужились даже просто взять одинаковый набор файлов...
> С какого перепугу? Я взял совершенно одинаковые задачи в системах одного типаНу да, "выкoпать траншею" - одинаковая задача. Правда одни роют беломорканал а вторые - канавку между грядками. Да подумаешь, разница. Ламерствовать так уж по полной?
> и сравнил. Да, канал - одинаковый, а машинки сильно разные, фря на слабой.
Да, сравнение хрен знает чего и в фиг каких условиях, с покладанием на объективность и воспроизводимость результата - характерная черта BSDшников. Поэтому у них получается очень крутая система. Сферическая, в вакууме. А если взять одну и ту же задачу на одном и том же оборудовании, на что ума хватает даже у фороникса - начинаются визги :)
>> Во вторых, git - система контроля версий а не файлокачалка.
> да мне как-то пофиг. пока портежи не перевёл на git было ещё медленнее.А мне как-то тем более пофиг. У меня то все быстро. Люблю когда ничего не тормозит. Пусть лучше компьютеры меня ждут а не я - их.
> с таким баттхёртом в тему FreeBSD переходит на svn. Там вы шизoфренично
> будете спорить с теми, кто говорит что git удобнее.Так гит удобнее. Для разработчиков, собственно.
>> Нормально, сравнили дельтаплан с боингом. А ничего что у них функционал разный?
> да мне как-то параллельно. я по svn/git забираю исходники/портежи.А мне тем более параллельны проблемы извращенцев перепутавших систему контроля версий с файлопомойкой и полагающих что работа файлопомойкой - главное что требуется от хорошей VCS.
>> В третьих, ни звука не сказано про конфигурацию ремотных серверов и нагрузку на оные.
> бсдшник естественно любит гoвно мамонта, наивно даже предположить, что у них стоит
> что-то современнее 8086.А что, они настолько некроманты что даже изгaльнулись как-то обойтись без MMU? Да, на что только не пойдешь ради любимого ремесла :)
> Были 80286, но их забрали проприетарщики, когда приходили вытирать о бcдшников
> ноги. да и всем yбyнтоидам известно, что фря на другом и не запускается.Ну извините, при попытке загрузить допустим desktop bsd на реальном оборудовании оно валится в черный экран и там и остается. Forever. А пингвины на раз подцепляют все железо.
> опять же тормозная ZFS.
Ну так это один из самых первых дизайнов такого типа. Логично что последовавшие за ним постараются учесть пролеты оного и избежать их. У btrfs более-менее получилось. Некоторые слабые стороны есть и у него но он сильно проседает под куда меньшим числом нагрузок + настройки есть которые позволяют адаптировать поведение к нагрузке. Типа выборочного отключения CoW и прочая.
>> 16-процессорный монстр с 256 гиг оперативы?
> у линуксоидов? естественно. и btrfs!Почему-то когда тот же фороникс сравнивает на одинаковом оборудовании и одинаковых бенчах - начинаются вопли о том что они дескать криворуки. Зато вам с замерами неизвестно чего и как - предлагается верить. Как школьники подгоняющие решение под ответ.
>> В четвертых, может так оказаться что ваша бсда неуловимый джо и там просто мало изменений, например.
> странно, что такая простая отмазка не пришла сразу. но только она не
> катит: порты с портежами вполне сравнимы,Знаем мы ваши сравнения - если долго подгонять под ответ, иногда это даже получается.
> ядро линуксовое прилетает тарболом. так что изменения в мире,
> ядре, портах > чем в портежах. увы и ах.А померяно точным инструментом "на глазок"? При том если бы это был не бcдшник а гентушник, инструмент выдал бы ровно противоположный результат, да? :)
> Ступай в фороникс, там будешь городить условия какие захочешь. Я выполняю штатные
> сходные задачи штатными методами.Фороникс делает не в пример менее ламерские бенчи если сравнить с тем шытом который вы привели в качестве "аргументов".
>> Только почему-то бенчмарки это не подтверждают.
> Мне на них не работать.Свое не пахнет, кто бы сомневался. Поэтому объективные бенчи в одинаковых условиях мы отбросим и лучше померяем на глазок фиг знает что и фиг знает как. Какая-то задача являющаяся по сути техническим оверхедом - это у нас краеугольный камень. Смысл существования системы. Сферические кони в вакууме - они такие!
>> И вот как-то так у бсдшников везде.
> Ну это да. Только глубокое личное знание вызвало к жизни сии сeнтеeции,
> вовсе не пoпaболь, нет.Всего лишь капитанинг и легкий стеб над любителями сферических коней в вакууме, которые даже бенчи честно проводить не хотят - боятся. Предпочитая подгонять решения под ответ. Правда вот незадача: такой результат не имеет практической ценности в этом мире. Совсем. Никому не интересно как вы там под ответ подгоните. Представляете себе допустим конструктора моста который рассчеты под ответ подгоняет? А вы думаете что вам почему-то можно. Но для всего остального мира это выглядит как жалкая клоунада и попытка прикрыть свой окорок.
> Стесняюсь спросить, вы можете назвать задачи, для которых лично вы выберете FreeBSD,
> или даже после потыкивания носиком в преимущества будете утверждать, что Линукс
> лучше во всём?Естественно лучше. То что вы привели как пример - не real-world задача. Это заморочки конкретных систем на их же собственный майнтенанс. На выходе оно не привносит вообще ничего нового и полезного, являясь внутренним техническим действом. Это действо самоцелью не является. Более того, в binary-based вообще отсутствует фаза компиляции. По поводу чего они в плане обновлений удобнее и быстрее. По поводу чего их и юзают поголовно в продакшнах нынче все кроме особо упертых крaснoглазиков.
>> Да, но бсдшники почему-то склонны замечать только чужой трэш и угар,
> вообще-то я не о том говорил. и вообще-то бсдшники крайне разные. но
> наличие "чужого треша и угара" вы зафиксировали, да. уже неплохо.Вы этому немало способствовали. Сравнивать ежа с ужом и получить из этого сравнеия результат "а svn/zfs лучше" может только настоящий адепт сферических коней в вакууме.
>> упорно игнорируя все бревна в своих глазах и все сильные стороны конкурентов.
> отнюдь. причём достаточно взглянуть на грызню фанатов разных дистров, чтобы понять. что
> бcдшники тут просто дилетанты.Я даже как-то затруднюсь вспомнить хоть 1 фаната линуксных дистров который бы переламерил вашу "методику" "сравнений".
>> Ну а кто виноват что оно как-то так и есть?
> вот действительно. фс на десктопе это крайне нишевый случай. 1 на миллион.Простите, а где вы предлагали честно бенчмаркать ФС на типовых для десктопов сценариях? То что тягать SVNом кучу сорцов на скорость без использования контроля версий по назначению надо раз на миллион - я и не сомневаюсь. Эталонный сферический конь в вакууме.
> дык я про то же. неясно так получается. в жизни всё отлично
> в бенчах как-то не очень. а btrfs - как-то наоборот ;)А мне наоборот предельно ясно: синдром "свое не пахнет" в полный рост. Подгон решения под ответ. Самый обычный.
> Видимо, реально батхерт.Истинно. Капитанинг и рядом не стоял.
> Ну да, "выкoпать траншею" - одинаковая задача. Правда одни роют беломорканал а
> вторые - канавку между грядками.сырцы ядра, мира, порты vs портежи. расскажи мне друг любезный, что именно тут беломорканал и что именно канавка между грядками и почему.
> Да подумаешь, разница. Ламерствовать так уж по полной?
Ну так просвети, не дай ламерком подохнуть, где ж ты разнуцу узрел, о премудрейший?
> Да, сравнение хрен знает чего и в фиг каких условиях,
абсолютно правомочное сравнение.
> на объективность и воспроизводимость результата - характерная черта BSDшников.
чувак я ещё и линуксоид, так что все дефекты линуксоидов вдобавок. так что - держись.
> оборудовании, на что ума хватает даже у фороникса - начинаются визги
если ты про мой пример, то по железу фря даёт фору. если конкретно про фороникс - я тут уже писал. Сравнивать свежевышедшее ядро линуха и 8.2 фряху (релиз трёхлетней давности) да ещё разлива PC-BSD - это да. объективность на марше, держите кепки.
> А мне как-то тем более пофиг.
(торопливо записывает в блокнот)
то, что крутой git в итоге работает медленнее тормозного svn линуксоидам пофиг.> Так гит удобнее. Для разработчиков, собственно.
так разработчики бсд сочли достаточным удобство для себя, а юзерям в итоге удобен и svn. и да, с 3.3.x по 3.5.4 поломаная поддержка вебкамер - это болт на пользователях. зато удобный разработчикам git - туда-сюда по ревижнам, туда-сюда. так красиво и удобно, что забывают нафиг что где работает. и ядра выходят сто версий на дню, скоро хрома с фф переплюнут.
> А мне тем более параллельны проблемы извращенцев перепутавших систему контроля версий с
> файлопомойкой и полагающих что работа файлопомойкой - главное что требуется от
> хорошей VCS.Остап Бендер, кажется, говорил, что если человек идиот - то это надолго. А может и не он. Не суть важно. Важно что некий аноним считает что порты и сырцы - это файлопомойка. И это - надолго.
> Ну извините, при попытке загрузить допустим desktop bsd
Опять вспоминается фраза незабвенного турецкоподданного. DesktopBSD мертва уж года три-четыре. Но пока была жива, на реальном оборудовании как раз всё отлично работало. Из линуксов в то время на том же железе не имел проблем только MOPS, Fedora Core (тогда ещё) да Kanotics. Причём правильно держать рефреш сумели только DesktopBSD и MOPS (ныне - Agilia, если не крякнули).
> А пингвины на раз подцепляют все железо.
убунты облажались.
> Почему-то когда тот же фороникс сравнивает на одинаковом оборудовании и одинаковых бенчах - начинаются вопли о том что они дескать криворуки.
потому что сравнивают ядра, отрелизившиеся N месяцев назад с 8.2 трёхлетней давности и потому что стоически выбирают некое pc-bsd, ну и самое главное - не пытаются разобраться ПОЧЕМУ. И последняя претензия собственно вообще к BSD не имеет отношения - это плохо в любом случае. Те же тесты на ixbt обязательно выкатывают объяснение, почему то или иное железо проигрывает или выигрывает в той или иной ситуации.
> вам с замерами неизвестно чего и как - предлагается верить.
да мне как-то параллельно, верит мне анонимус или нет. ткнули в факт: btrfs на рабочей станции тормозливее, чем ext4. Можно пройти мимо. Можно проверить и разобраться. Но веселее всего, конечно, закричать "у меня всё работает!" и сослаться на бог весть сколько лет как почившую DBSD.
> Знаем мы ваши сравнения - если долго подгонять под ответ, иногда это даже получается.
т.е. аргументов нет, а ПРЕДубеждение есть. Собственно, никто и не сомневался.
> А померяно точным инструментом "на глазок"? При том если бы это был
> не бcдшник а гентушник, инструмент выдал бы ровно противоположный результат, да?
> :)На беду я и бсдшник и гентушник. И ещё пару дистров люблю и уважаю. Всё, что я отметил - это то, что не надо ныть про "древние некрутые инструменты". с умом приложенные, они дают результат лучше, чем бестолково используемые "крутые современные".
>> Мне на них не работать.
> Свое не пахнет, кто бы сомневался.Своё проверяется на эффективность и если не устраивает - ищется более эффективный инструмент.
> Всего лишь капитанингЖалкие оправдания порезал, извини.
>> Стесняюсь спросить, вы можете назвать задачи, для которых лично вы выберете FreeBSD,
>> или даже после потыкивания носиком в преимущества будете утверждать, что Линукс
>> лучше во всём?
> Естественно лучше. То что вы привели как пример - не real-world задача.У меня немного другое мнение, но спорить поэтому я не собираюсь. Прошу обратить внимание на вот что. Подход BSD: рассчитываем, взвешиваем, разбираемся, делаем план, работаем. Подход Linux: срочно делаем своё, "принципиально лучшее". Попутно ломаем "неважные" вещи. Попутно выясняем что всё надо переделывать. Попутно херим толковые вещи. И всё бы ничего, но в погоне за новыми велосипедами начинается усиленное гажение на тех, кто действует по-другому. Достаётся BSD, slackware, gentoo. Собственно всем, кто по сути хоть как-то использует исходники. На выходе юзерь, который сырцов не видел, не знает, использует бинари и плотно зависит от корпораций, засевших на разработку. Исключения, естественно есть, но общий подход слабо отличается от вендового. Отсюда на форумах уютной убунты 90% советов - "переставь" и "обновись".
> Это заморочки конкретных систем на их же собственный майнтенанс.
Да. как и сравнение yum VS apt-get.
> Более того, в binary-based вообще отсутствует фаза компиляции.
это когда плюс, когда минус. для меня, например, возможность поставить софт ровно с теми либами, что действительно нужны и не тащить крап - это плюс. цена - время на сборку - невысока.
Опять-таки чистых SB нет, все они имеют возможность ставить и бинари - почему нет. А вот в чистых BB установка из сырцов это аццкий ад.
> Вы этому немало способствовали. Сравнивать ежа с ужом и получить из этого
> сравнеия результат "а svn/zfs лучше" может только настоящий адепт сферических коней
> в вакууме.я бы спросил точную цитату, но ответ знаю заранее. нет, я говорил не это и не так, сейчас вы разговариваете с собственными тараканами.
> Я даже как-то затруднюсь вспомнить хоть 1 фаната линуксных дистров который бы
> переламерил вашу "методику" "сравнений".очень хорошая методика.
>>> Ну а кто виноват что оно как-то так и есть?
>> вот действительно. фс на десктопе это крайне нишевый случай. 1 на миллион.
> Простите, а где вы предлагали честно бенчмаркать ФСнигде. и совсем не предлагал и не предложу. ибо это просто бессмысленно - вместо признания и лечения проблемы городить тесты _с целью доказать что всё хорошо_. могу предложить товарисчу, у которого проблемы с btrfs попробовать разобраться, на чём именно проседает. и потюнить (или отписать багрепорт). но честно говоря ожидал подобного предложения от оппонента, т.е. вас. дождался только упрямого мотания головой "в DBSD экран чёрный", "фороникс тесты делает годные", "а ты дурак", "бсдшники по ночам жрут христианских детей". хотя неясно, какое отношение поломанная поддержка вебкамов, тормозящая на обычном десктопе btrfs имеет к бсдшникам вообще и несколько лет как брошенному дистру в частности.
С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то делают иначе, либо что-то исправили в btrfs.(Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/...
> С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то
> делают иначе, либо что-то исправили в btrfs.
> (Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/...OpenSuse тоже себя так ведёт. Проблема не в вендоре :)
Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков, то результата увеличения производительности можно и вовсе не заметить. Особенно в стандартных юзкейсах btrfs.
Удаление файлов тоже должно ускориться по идее.
> Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков,Как бы ситуация с параллельным доступом к файлам - совершенно нормальна для многозадачек. Поэтому хуже явно никому не станет. А вот лучше - кому-нибудь станет.
кэши! надо больше кэшей! чего там иноды, надо уже и данные засовывать в кэши!
> данные засовывать в кэши!Давно реализовано - системный кэш именно это и делает. Тем паче что в пингвине он может по дефолту юзать почти всю свободную оперативу, на лету урезая осетра по мере того как память становится нужна другим. Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.
Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)
> Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды?
> Ну да, не всем в этой жизни везет :)Я видел, как в Ubuntu (ещё в версии v.6.06) у меня на 4GB флэшку большой файл копировался в течение нескольких секунд. Правда, потом при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты. Во FreeBSD такого не происходит, но и флэшка не с опцией "sync" подмонтирована, скорость записи нормальная.
> при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты.О, еще один неандерталец открыл для себя дисковый буффер.
>Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)Тут у меня после зависания 2 с лишним гигабайта испарились. Но улетали они на диск дольше
>Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти своим г..ном и все начинает тормозить
> Тут у меня после зависанияЯ не считаю зависания системы нормальной ситуацией, для начала. Если система глюкавая и не работает корректно - там может быть что угодно. И потеря данных, и искажение, и марсианский десант. Мало ли чего.
> 2 с лишним гигабайта испарились. Но улетали они на диск дольше
Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает. Ну а так срубилась бы запись на середине файла. Какая нафиг разница - кэшированная запись не успеет дописать файл или некэшированная. С точки зрения порчи файла - одинаково. А вот ждать окончание копирования файла - не особо приятно. Да, надо понимать что такая операция без явного fsync - не является полностью завершенной, хоть и выглядит таковой. Багофича кеширования.
Ну, отключите кэши и получите то что хотите, если вам так больше нравится, кому хуже будет? :)
>>Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.
> И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти
> своим г..ном и все начинает тормозитьНу а тут уже или система или руки. Или торрент-клиент горбатый/недооптимизированный (при желании может сильно облегчить жизнь ФС). У меня почему-то активно пашущий торрент проблем не вызывает. И в принципе не может. Просто потому что скорость работы HDD на порядок превосходит скорость сети.
> Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает.
> Ну а так срубилась бы запись на середине файла. Какая нафиг
> разница - кэшированная запись не успеет дописать файл или некэшированная. С
> точки зрения порчи файла - одинаково. А вот ждать окончание копирования
> файла - не особо приятно. Да, надо понимать что такая операция
> без явного fsync - не является полностью завершенной, хоть и выглядит
> таковой. Багофича кеширования.И много у вас таких "багофич"? Для ZFS нет понятия "не до конца записался файл": он либо записался на диск весь целиком, либо не записался — третьего (промежуточного состояния) не дано, так как природа записи файла на ZFS транзакционна. Если на процессе записи отрубили электричество, то при последующем восстановлении ZFS отмотает лог транзакций на последнюю транзакцию, освободит пространство от мусора и будет целостной и непротиворечивой. Но это не значит, что открытые на запись файлы обнулятся (как в XFS или Ext4 в ранних версиях), а будут лежать те версии файлов, которые были ДО сбоя питания. То же самое с UFS2+SU(J), у которой fsck освобождает свободное пространство от мусора (вследствие незавешённых транзакций), фактически актуализируя последний снапшот перед сбоем ФС, в котором все транзакции подтверждены, а данные заморожены.
> И много у вас таких "багофич"? Для ZFS нет понятия "не до
> конца записался файл": он либо записался на диск весь целиком, либо
> не записался — третьего (промежуточного состояния) не даноГоворишь, нет кэширования на запись? Ну-ну.
> Говоришь, нет кэширования на запись? Ну-ну.Он просто еще не понял что в указанной им ситуаци на CoW-based ФС при этом файл вообще не будет существовать. Просто потому что дописаться не успел, а значит "его вообще не существовало".
> конца записался файл": он либо записался на диск весь целиком, либо
> не записался — третьего (промежуточного состояния) не дано,Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый. Ты доволен? :)
>> конца записался файл": он либо записался на диск весь целиком, либо
>> не записался — третьего (промежуточного состояния) не дано,
> Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый.
> Ты доволен? :)Тот, который писался с нуля и незавершилась транзакция по его записи? Испарился — прекрасно, так как не нужно разгребать весь тот бред, что записалось, а что нет.
Недописанный в транзакции файл будет оставаться в том состоянии, в котором его оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС?
> Недописанный в транзакции файл будет оставаться в том состоянии, в котором его
> оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС?Это даже не столько к ФС сколько к общему свойству CoW механики. Как-то сильно по другому это реализовывать просто нелогично.
> освободит пространство от мусора и будет целостной и непротиворечивой.Ты не поверишь, но btrfs делает примерно то же самое. Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а идея в целом - меняется мало.
>> освободит пространство от мусора и будет целостной и непротиворечивой.
> Ты не поверишь, но btrfs делает примерно то же самое.С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть ли не в каждом посте о достоинствах Btrfs приводите это как полезную фичу :) Заметьте, я не предлагаю повсеместно вырубать проверку чексумм на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) )
> Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а
> идея в целом - меняется мало.Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck. Включение журналирования всего и вся приводит к ощутимым тормозам. А вот в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение журналирования на томе с UFS2+SU позволяет привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись. Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.
> привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлисьА ведь еще когда предупреждали — не надо говорить за всю сеть.
> А ведь еще когда предупреждали — не надо говорить за всю сеть.Это изен. Тупо лажаться - его фирменный стиль :)
> С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть
> ли не в каждом посте о достоинствах Btrfs приводите это как
> полезную фичу :)Это полезная фича для очень нишевых применений. Которые сами себя журналят и потому клещатся с CoW.
> Заметьте, я не предлагаю повсеместно вырубать проверку чексумм
> на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) )Я думаю что на этом сильно много не выиграешь. Оно упирается в обсчет чексумм только на дистрофическом процессоре и очень высоких скоростях. В бенчах тоже никто CoW не отключает. Это точечная ситуационная мера для адресных применений когда логика CoW не стыкуется с логикой работы с журналируемой структурой типа БД.
> Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с
> помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck.Может и не вычиститься. Это на классике технически невозможно при случае когда крах случился в середине записи а журналинг был только для метаданных. Нет данных для докатывания транзакции до конца или откатывания. А полный журналинг тормозит т.к. 2 раза приходится все писать. В cow сделали финт ушами и обошли эту проблему сбоку. По сути сделав ФС одним большим журналом.
> Включение журналирования всего и вся приводит к ощутимым тормозам. А вот
> в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение
> журналирования на томе с UFS2+SU позволяет привести ФС и данные в
> непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются
> новые технологии от устаревших,К конкретно этому элементу UFS у меня особых претензий нет. А вот общая архаичность устройства дисковых структур и потому общая тормозливость дизайна - никуда не делась. Вот смотри: у меня десктоп подперт упсой. Ноут сам себе упс. Когда я видел в последний раз кернел паник - я и не помню даже. Несколько лет назад, очевидно. Т.е. в общем то крахов то как раз и не происходит. Неоткуда. Т.е. злободневность проблемы сильно снижена иными техническими мерами. А вот тормозливость файловой системы я могу видеть каждый день. Стоит ли говорить что при указанном раскладе я заинтересован еще и в скорости работы? Потому что надежность и так обеспечена. Не теми мерами так иными (роялит то в конце концов результат).
> а не скоростными режимами, которые нафик никому не впёрлись.
См. выше. Мне скоростные режимы вполне себе вперлись. Я не нанимался машины ждать. Пусть они меня ждут. Надежность - это хорошо. Еще 1 уровень страховки - тоже. Но если это приведет к 6мб/сек на шпиндель, мне такое решение и даром ни к чему. Т.к. меня не устраивают его параметры.
> Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.
А кто сказал что у меня с надежностью проблемы? За последние несколько лет я вообще никаких данных не терял по вине ФС. В принципе. Я не спорю что чексуммы - хорошо. Мало ли, вдруг там фирмвара сдуреет или помеха на кабеле? Там конечно свои слои ECC/чексумм, но есть маленькая но ненулевая вероятность что и они облажаются. По поводу чего еще слой поверх - это в принципе хорошо. Равно как и недеструктивная запись aka возможность передумать и вернуть в вид как было. Ну вот в btrfs все это есть. При этом оно не настолько убер-тормоз как ZFS. Чем и лучше, собственно.