форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Набор патчей, заметно увеличивающих производительность работ..."	+/–
Сообщение от opennews (??) on 30-Сен-12, 22:13
Мяо Се (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Набор патчей, заметно увеличивающих производительность работ..."	+2 +/–
Сообщение от Аноним (??) on 30-Сен-12, 22:13
хм... начиная читать думал там цифра будет не 20, а 200%, начало было куда более оптимистичным..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 30-Сен-12, 22:40
	А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 22:55
	"Сперва добейся" - это убербаян. В следующий раз попытайтесь быть пооригинальнее.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 01:03
	Еще несколько "заплюсовавших" "ценителей" чужого труда поддерживают вашу точку зрения. Поздравляю, только громче кричите "убербаян", а то разумные мнения все еще слышны.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	29. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от z (??) on 01-Окт-12, 12:38
	Не нужно быть поваром, чтобы оценить яичницу, - обтекайте
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	55. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:22
	> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте Нужно. Потому что не-повара могут высказать мнение, которое лично мне не нравится. Это весомый аргумент, я полагаю?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	69. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 19:40
	вот это бред
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	107. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от z (??) on 02-Окт-12, 14:05
	>Нужно. Потому что не-повара могут высказать мнение, которое лично мне не нравится. Это весомый аргумент, я полагаю? Даа, "повар лучше знает", "продавец лучше знает" и т.д и т.п. - попахивает классическим совковым маразмом
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	56. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:23
	> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте И не нужно быть баянистом, чтобы оценивать игру на рваном баяне.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	57. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:47
	> , - Да, вот это я понимаю, обтекание. В русском языке нет такого синтаксиса.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	64. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 16:42
	На самом деле, есть. Эпик.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	91. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 02:06
	> На самом деле, есть. Эпик. Epic fail вы хотели сказать? :)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	89. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от XoRe (ok) on 02-Окт-12, 01:48
	> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте В соседней ветке новый ролик от создателей blender оценили, как "графан слабоват". И правда, в мстителях графан покруче. И зачем вникать, что бюджеты этих двух проектов астрономически различаются?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	108. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от z (??) on 02-Окт-12, 14:09
	>> Не нужно быть поваром, чтобы оценить яичницу, - обтекайте > В соседней ветке новый ролик от создателей blender оценили, как "графан слабоват". > И правда, в мстителях графан покруче. > И зачем вникать, что бюджеты этих двух проектов астрономически различаются? Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, и для кого "графан слабоват" буду отвечать в вашем же стиле "а вы на бюджет посмотрите" =)
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	113. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от XoRe (ok) on 02-Окт-12, 17:03
	> Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, > и для кого "графан слабоват" буду отвечать в вашем же стиле > "а вы на бюджет посмотрите" =) Точку любой аноним поставить может. Почему-то никто не хочет смотреть на соотношение выхлопа к затратам.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	118. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 21:45
	> Офигеть логика =) Давайте я за 1 копейку на стене точку поставлю, А я бесплатно могу, так что вы неэффективный просаживатель бабла. А вот например нанесение вполне себе сложного граффити на стену - дается уже немногим.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	18. "Набор патчей, заметно увеличивающих производительность работ..."	–4 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 03:03
	будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности. ЗЫ я не кометентен в оптимизациях, но компетентен в решении конфликтов: срач ты слил можешь заворачиваться в пижамку.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	49. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:09
	> будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности. В вопросе баянов я вполне компетентен, как и любой интернет-пользователь. > я не кометентен в оптимизациях ЧИТД
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	58. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:48
	> ЗЫ я не кометентен в оптимизациях, Былинный отказ :)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	36. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:18
	> "Сперва добейся" - это убербаян. Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	48. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:08
	> Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать. Да, говорить правду легко и приятно.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	7. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 30-Сен-12, 22:56
	> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом. А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет право утверждать "а король-то голый"?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 01:07
	> А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет > право утверждать "а король-то голый"? Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть он и не авторитет в этой области, а лишь толстый тролль. Ну что ж, с мнением Анонима нужно считаться.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	50. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:11
	> Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть > он и не авторитет в этой области, а лишь толстый тролль. > Ну что ж, с мнением Анонима нужно считаться. Если истинность этого мнения очевидна - то почему бы и нет? Не важно, _кто_ говорит. Важно, _что_ говорит.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	19. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 03:04
	>> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом. > А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет > право утверждать "а король-то голый"? нет но эксперт по голым людям, очевидно же!
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	47. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:07
	> нет но эксперт по голым людям, очевидно же! Значит, если люди видят, что король голый - это ничего не значит, пока не придет дипломированный эксперт по голым людям (видимо, патологоанатом) и не вынесет экспертное суждение?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	31. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от другой аноним on 01-Окт-12, 13:25
	> А ты сам оптимизни хоть какую ФС на 20% и порассуждай потом. Бесспорно, достойный результат, но... вообще-то это выигрыш в одном конкретном тесте. Причем, видать, в таком, который показывает наиболее выигрышный результат. Не очень часто массированно приходится делать такое - "создание 100 тыс файлов в 10 параллельных потоков". Почему не приведены результаты еще каких-то тестов? Вдруг в каких-то вариантах использования и регресс может наблюдаться?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	90. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от XoRe (ok) on 02-Окт-12, 01:50
	> Не очень часто массированно приходится делать такое - "создание 100 тыс файлов в 10 > параллельных потоков". Загрузка фоток пользователями?)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	114. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от BratSinot on 02-Окт-12, 18:33
	Просто изначально нужно писать правильно. А точнее не писать, а для начала разработать.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	5. "Набор патчей, заметно увеличивающих производительность работ..."	+2 +/–
	Сообщение от dalco (ok) on 30-Сен-12, 22:45
	Просто наиболее явные места уже заоптимизировали. Так что находить места, где доработка алгоритма дает большой выигрыш, становится все труднее. Ваш К.О. P.S. Если верить рассылке, то эту самую оптимизацию в свою очередь тоже уже оптимизировали. :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	37. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:20
	> уже оптимизировали. :) Оптимизация оптимизации оптимизаци... wait, oh sh--!
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Набор патчей, заметно увеличивающих производительность работ..."	+3 +/–
	Сообщение от jedie on 30-Сен-12, 23:07
	когда дело касается файловых систем. +20% к производительности, это просто огромный прирост.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Xasd (ok) on 01-Окт-12, 00:10
	не просто +20% к производительност -- а именно "в тесте на создание 100 тыс файлов в 10 параллельных потоков" а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Набор патчей, заметно увеличивающих производительность работ..."	–3 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 01:27
	Ты под досом до сих пор сидишь?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	39. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:21
	> а во время обычной работы с файловой системой -- может быть этих +20% и не будет :-) Их даже почти наверняка не будет т.к. как правило большую часть времени ФС вообще ничего не делает. А 20% от нуля - и так и эдак ноль.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	54. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:20
	> Их даже почти наверняка не будет т.к. как правило большую часть времени > ФС вообще ничего не делает. А 20% от нуля - и > так и эдак ноль. Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно. Вы случайно не Джеф Бонвик?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	59. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:52
	> Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно. Я всего лишь подшучиваю над теми кто полагает что оптимизации не требуются и/или будут не видны. > Вы случайно не Джеф Бонвик? Да что уж там, Шишкиным сразу называйте. Я тогда спецом для вас сделаю том из одних метаданных и буду вопить про то как btrfs отстоен. Ведь на reiser можно запихнуть в два раза больше пустых файлов :)
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	83. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 22:25
	зато когда потоков будет уже 100 - можно заиметь провал в производительности.. Но видимо это "оптимизаторов"  не отпугивает :)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	99. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 03:46
	> зато когда потоков будет уже 100 - можно заиметь провал в производительности.. А где бенчи на 100 потоков?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

2. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
Сообщение от pro100master (ok) on 30-Сен-12, 22:25
ну там и 2000% мало будет. Пока, увы, еле ворочается, по крайней мере, на декстопе :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Набор патчей, заметно увеличивающих производительность работ..."	+7 +/–
	Сообщение от Аноним (??) on 30-Сен-12, 22:28
	Хотели _полный_ аналог ZFS? Получите и распишитесь. Осталось только жрач памяти допилить, а то отстает ведь.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	11. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от mylefthand on 01-Окт-12, 00:20
	>Хотели _полный_ аналог ZFS? А фоновое шифрование когда будет?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	25. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от dalco (ok) on 01-Окт-12, 09:52
	А "фоновое шифрование" - это как? По идее, если возникла необходимость в шифровке данных, то их шифровать надо сразу же при сбросе на диск, а не надеяться, что часиков через надцать их какой-нибудь фоновый процесс таки зашифрует и тогда данные точно будут в безопасности. Или я все не так понял?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	74. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от ааноним on 01-Окт-12, 20:17
	Конечно неправильно, все данные попадают на диск уже зашифрованными)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	53. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:19
	> А фоновое шифрование когда будет? Когда выйдет проприетарная версия.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	70. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 19:59
	> Когда выйдет проприетарная версия. Проприетарная версия GPLнутого кода? Это как? :)
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	24. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 09:34
	А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	38. "Набор патчей, заметно увеличивающих производительность работ..."	+2 +/–
	Сообщение от ха on 01-Окт-12, 14:20
	у мня есть raid6, могу поставить btrfs, только зачем мне там еще raid5?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	40. "Набор патчей, заметно увеличивающих производительность работ..."	+5 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:22
	> А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет? А как насчет trim и нормальных экстентных аллокаторов? :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	42. "Набор патчей, заметно увеличивающих производительность работ..."	–2 +/–
	Сообщение от iZEN (ok) on 01-Окт-12, 14:41
	>> А RAID-5 (не говоря уж о RAID-6 и дедупликации) в Btrfs когда будет? > А как насчет trim и нормальных экстентных аллокаторов? :) В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да. Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят: http://svnweb.freebsd.org/base?view=revision&revision=240868
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	51. "Набор патчей, заметно увеличивающих производительность работ..."	+3 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:13
	> В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да. В btrfs они есть изначально :) А ZFS даже экстентов нет, так что она сoсет не нагибаясь.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	52. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:14
	> Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят: Да, таскать "кривые ненужные костыли из линyпса" любой дурак может. А вот утащить фоновое шифрование из проприетарной солярки - слабо.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	60. "Набор патчей, заметно увеличивающих производительность работ..."	+2 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:54
	> В Btrfs нет TRIM и экстентного аллокатора?! Это печально, да. Там то они как раз есть. > Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux Вот это я и называю ZFSLoL :) > принят: http://svnweb.freebsd.org/base?view=revision&revision=240868 Ну так и сабжевый патч принят. И чего?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	86. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от filosofem (ok) on 01-Окт-12, 23:11
	>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят А говорил не нужно, да. Оказалось просто запилить было некому.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	87. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 23:26
	>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят > А говорил не нужно, да. Оказалось просто запилить было некому. Давай яснее определю свою позицию по поводу TRIM. Для задач, которым важен большой размер блока ФС, совпадающий с размером блока SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен. Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки ФС поменьше (128k), TRIM ускорит операции записи.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	88. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от filosofem (ok) on 01-Окт-12, 23:44
	>>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят >> А говорил не нужно, да. Оказалось просто запилить было некому. > Давай яснее определю свою позицию по поводу TRIM. > Для задач, которым важен большой размер блока ФС, совпадающий с размером блока > SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен. > Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки > ФС поменьше (128k), TRIM ускорит операции записи. Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС не реализует элементарную функцию, это жестоко.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	93. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от Аноним (??) on 02-Окт-12, 02:19
	> Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС > не реализует элементарную функцию, это жестоко. Это изен и это далеко не самый мощный маразм который он может выдать :)
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	103. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 11:59
	>>>>Вон, в ZFS код для TRIM уже в head из проекта zfsonlinux принят >>> А говорил не нужно, да. Оказалось просто запилить было некому. >> Давай яснее определю свою позицию по поводу TRIM. >> Для задач, которым важен большой размер блока ФС, совпадающий с размером блока >> SSD (=512k) или кратен ему (=1M*n), TRIM в принципе не нужен. >> Для задач, которые хорошо работают с небольшими файлами, соответственно, желательно блоки >> ФС поменьше (128k), TRIM ускорит операции записи. > Скажу тебе как Капитан Капитану: использовать блок 512к только потому что ФС > не реализует элементарную функцию, это жестоко. На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование больших блоков ФС скорее благо, чем из ряда вон выходящее явление. Среди линуксовых ФС, пожалуй, только XFS заточена под такое [целевое] использование.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	109. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от filosofem (ok) on 02-Окт-12, 14:22
	> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование > больших блоков ФС скорее благо, чем из ряда вон выходящее явление. Напоминаю, TRIM это для SSD. =)
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	110. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 14:49
	>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование >> больших блоков ФС скорее благо, чем из ряда вон выходящее явление. > Напоминаю, TRIM это для SSD. =) SSD не используется для видеомонтажа? Странно. Не знал.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	111. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от filosofem (ok) on 02-Окт-12, 16:01
	>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование >>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление. >> Напоминаю, TRIM это для SSD. =) > SSD не используется для видеомонтажа? Странно. Не знал. ZFS годится только для видеомонтажа, буду знать.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	112. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 16:23
	>>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование >>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление. >>> Напоминаю, TRIM это для SSD. =) >> SSD не используется для видеомонтажа? Странно. Не знал. > ZFS годится только для видеомонтажа, буду знать. И под файлопомойку тоже — отметьте там у себя.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	115. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от filosofem (ok) on 03-Окт-12, 09:41
	>>>>> На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки [NAS] использование >>>>> больших блоков ФС скорее благо, чем из ряда вон выходящее явление. >>>> Напоминаю, TRIM это для SSD. =) >>> SSD не используется для видеомонтажа? Странно. Не знал. >> ZFS годится только для видеомонтажа, буду знать. > И под файлопомойку тоже — отметьте там у себя. Для помойки что она даёт эксклюзивного? Дедупликацию и RAID5. С дедупликацией те же вилы, что и с отсутствием TRIM. Если используем нормальный размер блока, получаем терабайт сожранной RAM и тормоза, если используем дикий полумегабайтный блок(на файлопомойке! =), то не получаем никакой экономии от дедупликации. Рейд-Z встроенный это конечно удобно, но учитывая, что жрёт ресурсов на объёмах в десятки терабайт ZFS в разы больше, чем MD+((LVM+ext4)|btrfs), а производительность и надёжность настолько же ниже, то возникает резонный влпрос: зачем? Короче тот же вывод, что и с видеомонтажом: использовать конечно можно, но однозначных преимуществ над нормальными FS нет, а недостатки перевешивают. ZFS можно порекомендовать только неосилившим MD, dm-crypt и LVM, потому что ZFS-хранилище поднять и админить сможет и макака. При условии, конечно, что нет ограничений на выбор железа. И только для названных специфичных юзкейсов.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	117. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 03-Окт-12, 20:29
	>>>>>> На многогигабайтных видеофайлах и даже на 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?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	119. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 21:49
	> Среди линуксовых ФС, пожалуй, только XFS заточена под такое [целевое] использование. XFS - разновидность обычного экстентного аллокатора. Просто оптимизанутая на многопоточность и многодисковые конфиги за счет allocation groups. А на однодисковой конфиге - оно сравнимо с иными экстентными по свойствам, тем же ext4 например. Ну с точностью до разницы в ряде алгоритмов/метаданных. Понимаешь, экстентом можно сразу заказать 100500 килобайтов. А не блоками. Особенно хорошо если есть такой непрерывный блок свободного места. Может прямо 1 операцией и заадресоваться, тогда как блочник будет дрюкаться с пометкой кучи блоков как занятых. На чем и протормозит. Теперь ты понимаешь почему экстенты - это суперсет блоков переменного размера? :)
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	92. "Набор патчей, заметно увеличивающих производительность работ..."	–2 +/–
	Сообщение от Аноним (??) on 02-Окт-12, 02:10
	> Давай яснее определю свою позицию по поводу TRIM. Да кужа уж яснее? Она болтается как флажок на ветру: - Если реализации фичи не предвидится в ближайшем будущем - "это не нyжно, понты и навороты!" - Если фичу вот-вот сделают - "все у кого нет этой фичи - лох!" Куда уж проще и понятнее, стандартная логика пионерии от бсд :)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	10. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Xasd (ok) on 01-Окт-12, 00:11
	> Пока, увы, еле ворочается, по крайней > мере, на декстопе :) у вас чистый 4.2 .. ..оно вполне быстрое, по крайней мере на десктопах.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от mylefthand on 01-Окт-12, 00:21
	>> Пока, увы, еле ворочается, по крайней >> мере, на декстопе :) > у вас чистый 4.2 .. > ..оно вполне быстрое, по крайней мере на десктопах. У меня тоже, может это из-за lzo компрессии
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Tav (ok) on 01-Окт-12, 02:49
	Использую на ноутбуке несколько месяцев. Выводы противоположные вашим. Сжатие LZO включено (в первую очередь, ради производительности: сокращается объем дискового ввода/вывода).
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	17. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 02:57
	Косынку раскладываем, по тырнетам лазим? Или может транк GCC компиляем, клонируем, сравниваем по каталогам (> 2 GB исходников). Для косынки любая ФС быстрая.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Tav (ok) on 01-Окт-12, 03:12
	Разработка, иногда звукозапись (через внешний многоканальный интерфейс). Ноутбук относительно слабый (B940). Я специально измерением и сравнением производительности не занимался. Могу только сказать, что переход с ext4 на btrfs проблем не вызвал и производительность субъективно не ухудшилась.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	41. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:36
	> и производительность субъективно не ухудшилась. А оно местами выигрывает, местами проигрывает, так что впечатления от задач сильно зависят. Например интенсивные многопоточные записи
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	61. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:55
	> Например интенсивные многопоточные записи ...btrfs лю. А остальные - нет.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	23. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от pro100master (ok) on 01-Окт-12, 09:20
	У меня тоже с выводами было, как у вас :) пока я не заметил, что кубунта обновляется 25 мин, а рядом стоящая кубунта на ext4 - 2 минуты.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	26. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от dalco (ok) on 01-Окт-12, 11:12
	Все правильно. При обновлении fsync на fsync`е сидит и fsync`ом погоняет. И для "обычной" FS это правильное поведение. Чем чаще fsync, тем чище попа ;) BTRFS же fsync`и не любит, предпочитая, если ничего не путаю, сбрасывать кеши на диск раз в 30 секунд. Вроде как, есть плагин к апдейтеру по имени eatmydata, который резко увеличивает скорость апдейта на btrfs, путем полного игнора запросов на fsync`и от апдейтера. P.S. Еще уязвимая точка btrfs - файлы виртуалок. У меня виртуальная 5ая центось около 25 минут грузилась по сравнению с 10 секундами на ext4. Правда, сие было года 2 назад и я больше такого эксперимента не повторял. Утверждают, что сейчас подобное поведение немного поправили.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	32. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Tav (ok) on 01-Окт-12, 13:27
	Для образов виртуальных машин в btrfs следует отключать режим COW (chattr +C).
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	35. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Stax (ok) on 01-Окт-12, 14:08
	Ага, лишившись всех остальных плюшек в процессе. Почему-то zfs замечательно хостит образы виртуалок в режиме COW (а других там нет - видимо, из-за этого нормально отпимизировали), поддерживает при этом снапшоты и тд.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	62. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:56
	> Ага, лишившись всех остальных плюшек в процессе. Зачем вам снапшоты снапшотов, сэр? :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	65. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 16:43
	> Зачем вам снапшоты снапшотов, сэр? :) Чтоб было, очевидно же. В конце концов, в слояровских виртуалках с этим похреновее, чем в линуксовых, вот и приходится изворачиваться.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	71. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:02
	> Чтоб было, очевидно же. Ну тогда смиритесь с тем что одна и та же работа многократно размножается. Цена наложения двух CoW друг на друга. > В конце концов, в слояровских виртуалках с этим похреновее, чем в линуксовых, > вот и приходится изворачиваться. Да не надо изворачиваться, надо просто научиться не забивать гвозди микроскопом. Не все технологии удачно сочетаются между собой во всех вариантах. Никто же не жалуется что плавиковая кислота хреново хранится в железной канистре, правда? :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	33. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от pro100master (ok) on 01-Окт-12, 13:42
	верно, но на январь-май (период моих игр и тестов) проблема сохранялась и советы потюнить мало что дали, и я вернулся к тёплой родной ext, т.к. это не единственная проблема - на огромном количестве файлов сжатие чудит :)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	43. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:54
	> BTRFS же fsync`и не любит, предпочитая, если ничего не путаю, сбрасывать кеши > на диск раз в 30 секунд. У нее sync медленный. Но там оно не сильно то и надо: там раз в 30 секунд автоснапшот делается. В случае факапа оно просто отмотает на этот автоснапшот. По сути напрашивается иная семантика доступа к ФС, с учетом того что ФС способна честно журналировать да еще делает это в виде множественных автоснапшотов. > Вроде как, есть плагин к апдейтеру по имени eatmydata, Какому именно апдейтеру? > который резко увеличивает скорость апдейта на btrfs, путем полного игнора > запросов на fsync`и от апдейтера. Вообще, в случае btrfs умной идеей было бы сделать на автомате чекпойнт до начала апдейтов -> вкатить все асинхронно и без fsync -> готово. В случае факапа просто откат на чекпойнт. Ну может еще раздестроить чекпойнт чтобы место не жралось. Все. Fsync там вообще для ФС типа ext4 и подобных, которые честно не журналят так что половина журнальной логики сбагрена на апликухи получается. > P.S. Еще уязвимая точка btrfs - файлы виртуалок. У меня виртуальная 5ая > центось около 25 минут грузилась А чего ради так много? Может, логика снапшотирования подралась с CoW логикой? Они делают одно и то же и когда виртуалка CoW-ает свой диск и ФС cow-ает все эти запросы, получается дец в квадрате. Можно попробовать отключить CoW для файлов виртуалки, т.к. большая часть виртуализаторов сами его делают в рамках 1 файла.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	66. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от dalco (ok) on 01-Окт-12, 17:01
	>Какому именно апдейтеру? Ну, изначально речь про убунту шла. У нее apt-get кажись? А вообще, если верить манам, то eatmydata с любой прогой пашет, так что без разницы. >Вообще, в случае btrfs умной идеей было бы сделать на автомате чекпойнт до начала апдейтов -> вкатить все асинхронно и без fsync -> готово. В случае факапа просто откат на чекпойнт. Ну может еще раздестроить чекпойнт чтобы место не жралось. Все. Fsync там вообще для ФС типа ext4 и подобных, которые честно не журналят так что половина журнальной логики сбагрена на апликухи получается. Не уверен на 100%, но в федоре вроде именно так все и делается. К yum`у спец-плагин под это дело примотан в случае работы с btrfs. Я не вникал - обновление работало шустро и надежно, что на ноуте с btrfs, что на серваках/десктопах с ext4. А пока оно нормально работает - о логике той работы особо не задумываешься :) >А чего ради так много? Может, логика снапшотирования подралась с CoW логикой? Они делают одно и то же и когда виртуалка CoW-ает свой диск и ФС cow-ает все эти запросы, получается дец в квадрате. Можно попробовать отключить CoW для файлов виртуалки, т.к. большая часть виртуализаторов сами его делают в рамках 1 файла. Не, там чего-то глубже. Если ничего не путаю, то надо было с режимами кеширования еще играться (но это я уже потом узнал). А так, интересу ради, подсовывал виртуалке вместо qcow2-формата чистый raw. Тормоза все равно оставались гигантские.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	72. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:05
	> Ну, изначально речь про убунту шла. У нее apt-get кажись? Правильно. Правда давать советы даже не зная что за программа - это забавно :) > пока оно нормально работает - о логике той работы особо не задумываешься :) Зато в случае факапа будет интересно, если не знаешь как вернуть в вид как было или не понимаешь что реверт снапшота откатит ВСЕ файлы :) > Не, там чего-то глубже. Если ничего не путаю, то надо было с > режимами кеширования еще играться (но это я уже потом узнал). Так qcow2 и так тормозит в дефолтном режиме. Known "feature". Надо буферизацию включать. Особенно хорошо с unsafe, но это только с UPS по очевидной причине.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	100. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от dalco (ok) on 02-Окт-12, 06:55
	>Правильно. Правда давать советы даже не зная что за программа - это забавно :) Кхм, я разве строил из себя гуру и давал 100% правильные советы? Я всего лишь указал -  в какую сторону копать. А кому это действительно необходимо, прочтет маны и сделает все по правилам. ;) >Зато в случае факапа будет интересно, если не знаешь как вернуть в вид как было или не понимаешь что реверт снапшота откатит ВСЕ файлы :) Нифига. Во-первых, откат пройдет на состояние до запуска yum`а, то есть теряем результаты, максимум пары минут работы. Во-вторых, все реально ценные файлы лежат в сетевом хранилище. То есть их откат снапшота вообще не коснется. В-последних, в случае факапа, я просто переброшу виртуалки на другую ноду и не напрягаясь буду решать проблему (например, тупо залью сервак с нуля минут за 20-30, попивая чай). >Так qcow2 и так тормозит в дефолтном режиме. Known "feature". Надо буферизацию включать. Особенно хорошо с unsafe, но это только с UPS по очевидной причине. Не знаю, на ext4 тот же qcow2 обеспечивал запись/чтение порядка 30-40Мб/сек. При абсолютно таком же конфиге, но с томом под btrfs скорость иногда падала до 80-100 КИЛОбайт/секунду. Именно поэтому я пока отказался от btrfs для решения своих задач.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	102. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 11:23
	> Кхм, я разве строил из себя гуру и давал 100% правильные советы? > Я всего лишь указал -  в какую сторону копать. А кому это действительно > необходимо, прочтет маны и сделает все по правилам. ;) Резонно. Вот вам плюсик за здравый смысл. > Нифига. Во-первых, откат пройдет на состояние до запуска yum`а, то есть теряем > результаты, максимум пары минут работы. Ну да. Но теряем, так что если клювом клац-клац и не осознать этот факт - можно и обломаться немного :) > Во-вторых, все реально ценные файлы лежат в сетевом хранилище. Ну это у вас лежат. А у остальных не обязаны. > В-последних, в случае факапа, я просто переброшу виртуалки на другую ноду и > не напрягаясь буду решать проблему (например, тупо залью сервак с нуля > минут за 20-30, попивая чай). Ну дык. Для серваков это нормально. А для десктопа? :) > Не знаю, на ext4 тот же qcow2 обеспечивал запись/чтение порядка 30-40Мб/сек. При > абсолютно таком же конфиге, Там еще в ext4 помнится одно время был чит с delayed allocation и прочая, достаточно чреватый в случае факапов. > но с томом под btrfs скорость иногда падала до 80-100 КИЛОбайт/секунду. > Именно поэтому я пока отказался от btrfs для решения своих задач. Подозреваю что дело в CoW который журналил CoW + медленном sync у этой ФС. Первое чинится отключением CoW для файла. Со вторым помнится недавно активно боролись.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	28. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Клыкастый (ok) on 01-Окт-12, 12:33
	вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	44. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:57
	> вы это расскажите хейтерам zfs. а то им фороникс сказал что btrfs самая быстрая. Опять тут граждане с батхертом. Да, по большинству бенчей ZFS не показывает ничего интересного. Что не удивительно т.к. там какой-то странный аллокатор. Вроде уже не совсем примитивно блочный, но еще не полноценный экстентный. Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет. А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать иногда аж в разы. Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше. На таких тестах продвинутые классики типа ext4/xfs/... рвут всех на британский флаг.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	68. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Клыкастый (ok) on 01-Окт-12, 19:31
	> Да, по большинству бенчей ZFS не показывает ничего интересного. (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное говно" svn обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5 минуты. zfs в продакшене молотит и не жужжит, а btrfs вон у товарисча как замечательно отрабатывает. как-то даже и сравниваться страшно, вот точно у кого-то баттхёрт будет. > Ну и вполне резонные результаты бенчей вида "ни два ни полтора". Т.е. под нагрузками удобными для CoW оно как-то живет. да отлично оно живёт. > А на всем остальном валится в полный трэш и угар, так что btrfs может выигрывать иногда аж в разы. как показывает практика полный треш и угар имеет свои корни. > Впрочем для btrfs тоже есть свои неудобные нагрузки. Но сильно меньше. точно! надо челу срочно объяснить что у него с btrfs крайне редкие проблемы! в целом по больнице картина просто замечательная!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	73. "Набор патчей, заметно увеличивающих производительность работ..."	+2 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:17
	> (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное гoвно" svn обновляет дерево сырцов фряхи за 15-40 секунд. portsnap портов отрабатывает за 15-20 сек. а волшебный git со всеми компрессиями портежи за 3-3,5 минуты. Да, а еще теплое тяжелее мягкого. > zfs в продакшене молотит и не жужжит, а btrfs вон у товарисча как замечательно отрабатывает Так btrfs тоже в продакшене молотит и не жужжит, а zfs вон у [кого-то там] замечательно отрабатывает. Использованные вами "критерии" растяжимы, как презерватив, и поэтому их можно без проблем натянуть практически на все, что угодно. > точно! надо челу срочно объяснить что у него с btrfs крайне редкие проблемы! в целом по больнице картина просто замечательная! Мне давеча адепты ZFS то же самое про свою любимую лечили.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	75. "Набор патчей, заметно увеличивающих производительность работ..."	+3 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:29
	> (задумчиво) вот объясните мне пожалуйста, как так получается, что "тормозное г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 в одном из тестов фороникса польем? А что, тоже нишевой случай как раз :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	79. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 21:30
	> Ну а кто виноват что оно как-то так и есть? Под большинством > нагрузок btrfs выглядит весьма культурно и является сильным соперником. А так > вон zfs на ряде бенчмарков сливается. Давайте ее за никакой TPS > в одном из тестов фороникса польем? А что, тоже нишевой случай > как раз :) Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты. Иди вон туда: http://www.youtube.com/watch?v=1mGzCmcKThU и популярно объясни парням-насостроителям, что ZFS не нужна и сливает по характеристикам горячо любимой Btrfs и даже Ext4. Может они проникнутся и поставят себе GNU/Linux с последними патчами Btrfs вместо убогой FreeBSD.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	81. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 22:18
	> Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты. Иди вон > туда: http://www.youtube.com/watch?v=1mGzCmcKThU и популярно объясни парням-насостроителям, > что ZFS не нужна и сливает по характеристикам горячо любимой Btrfs > и даже Ext4. Может они проникнутся и поставят себе GNU/Linux с > последними патчами Btrfs вместо убогой FreeBSD. Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекций.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	85. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Клыкастый (ok) on 01-Окт-12, 23:02
	> Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекций. тут главное не бежать в каноникл. а то воткнут тот самый зонд в голову, да не помыв, и будешь анонимом на опеннете скитаться, всех кто растопырки в голове хаять
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	94. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 02:24
	> тут главное не бежать в каноникл. а то воткнут тот самый зонд > в голову, да не помыв, и будешь анонимом на опеннете скитаться, > всех кто растопырки в голове хаять Вот уж не подумал бы что каноникал воткнул зонд izen-у и прочим nagual-ам. Но судя по описанию чертовски похоже.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	101. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Клыкастый (ok) on 02-Окт-12, 11:08
	> Вот уж не подумал бы что каноникал воткнул зонд izen-у и прочим > nagual-ам. Но судя по описанию чертовски похоже. они бегают анонимом по опеннету? да... похожесть для всех такая разная...
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	123. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 22:22
	> они бегают анонимом по опеннету? Не знаю. > да... похожесть для всех такая разная... По описальнику подходят - несут ламерский буллшит с умным видом, а заодно меняют точку зрения на 180 градусов узнав о том что в ZFS из линуксного (sic!) варианта портирован trim.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	84. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от Клыкастый (ok) on 01-Окт-12, 22:55
	> А тут все просто. Достаточно быть бсдшником Какой сочный баттхёрт. > Во первых, вы не удосужились даже просто взять одинаковый набор файлов... С какого перепугу? Я взял совершенно одинаковые задачи в системах одного типа (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 - как-то наоборот ;)
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	95. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 03:32
	> Какой сочный б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 - как-то наоборот ;) А мне наоборот предельно ясно: синдром "свое не пахнет" в полный рост. Подгон решения под ответ. Самый обычный.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	106. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Клыкастый (ok) on 02-Окт-12, 13:53
	> Видимо, реально батхерт. Истинно. Капитанинг и рядом не стоял. > Ну да, "вык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 имеет к бсдшникам вообще и несколько лет как брошенному дистру в частности.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	30. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Tav (ok) on 01-Окт-12, 13:24
	С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то делают иначе, либо что-то исправили в btrfs. (Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от pro100master (ok) on 01-Окт-12, 13:45
	> С обновлением Федоры ничего такого не заметил. Либо yum и rpm что-то > делают иначе, либо что-то исправили в btrfs. > (Дополнение) Тут объяснили суть проблемы: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299/... OpenSuse тоже себя так ведёт. Проблема не в вендоре :)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

21. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
Сообщение от deadless (ok) on 01-Окт-12, 08:07
Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков, то результата увеличения производительности можно и вовсе не заметить. Особенно в стандартных юзкейсах btrfs.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Набор патчей, заметно увеличивающих производительность работ..."	–1 +/–
	Сообщение от filosofem (ok) on 01-Окт-12, 11:24
	Удаление файлов тоже должно ускориться по идее.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	45. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 14:59
	> Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков, Как бы ситуация с параллельным доступом к файлам - совершенно нормальна для многозадачек. Поэтому хуже явно никому не станет. А вот лучше - кому-нибудь станет.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

22. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
Сообщение от Аноним (??) on 01-Окт-12, 08:11
кэши! надо больше кэшей! чего там иноды, надо уже и данные засовывать в кэши!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	46. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 15:01
	> данные засовывать в кэши! Давно реализовано - системный кэш именно это и делает. Тем паче что в пингвине он может по дефолту юзать почти всю свободную оперативу, на лету урезая осетра по мере того как память становится нужна другим. Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС. Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	63. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 16:17
	> Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? > Ну да, не всем в этой жизни везет :) Я видел, как в Ubuntu (ещё в версии v.6.06) у меня на 4GB флэшку большой файл копировался в течение нескольких секунд. Правда, потом при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты. Во FreeBSD такого не происходит, но и флэшка не с опцией "sync" подмонтирована, скорость записи нормальная.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	77. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:41
	> при попытке отмонтирования процесс "отдачи" флэшки зависал на 2-3 минуты. О, еще один неандерталец открыл для себя дисковый буффер.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	67. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 17:44
	>Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :) Тут у меня после зависания 2 с лишним гигабайта испарились. Но улетали они на диск дольше >Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС. И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти своим г..ном и все начинает тормозить
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	76. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 01-Окт-12, 20:39
	> Тут у меня после зависания Я не считаю зависания системы нормальной ситуацией, для начала. Если система глюкавая и не работает корректно - там может быть что угодно. И потеря данных, и искажение, и марсианский десант. Мало ли чего. > 2 с лишним гигабайта испарились. Но улетали они на диск дольше Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает. Ну а так срубилась бы запись на середине файла. Какая нафиг разница - кэшированная запись не успеет дописать файл или некэшированная. С точки зрения порчи файла - одинаково. А вот ждать окончание копирования файла - не особо приятно. Да, надо понимать что такая операция без явного fsync - не является полностью завершенной, хоть и выглядит таковой. Багофича кеширования. Ну, отключите кэши и получите то что хотите, если вам так больше нравится, кому хуже будет? :) >>Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС. > И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти > своим г..ном и все начинает тормозить Ну а тут уже или система или руки. Или торрент-клиент горбатый/недооптимизированный (при желании может сильно облегчить жизнь ФС). У меня почему-то активно пашущий торрент проблем не вызывает. И в принципе не может. Просто потому что скорость работы HDD на порядок превосходит скорость сети.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	80. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 01-Окт-12, 21:40
	> Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает. > Ну а так срубилась бы запись на середине файла. Какая нафиг > разница - кэшированная запись не успеет дописать файл или некэшированная. С > точки зрения порчи файла - одинаково. А вот ждать окончание копирования > файла - не особо приятно. Да, надо понимать что такая операция > без явного fsync - не является полностью завершенной, хоть и выглядит > таковой. Багофича кеширования. И много у вас таких "багофич"? Для ZFS нет понятия "не до конца записался файл": он либо записался на диск весь целиком, либо не записался — третьего (промежуточного состояния) не дано, так как природа записи файла на ZFS транзакционна. Если на процессе записи отрубили электричество, то при последующем восстановлении ZFS отмотает лог транзакций на последнюю транзакцию, освободит пространство от мусора и будет целостной и непротиворечивой. Но это не значит, что открытые на запись файлы обнулятся (как в XFS или Ext4 в ранних версиях), а будут лежать те версии файлов, которые были ДО сбоя питания. То же самое с UFS2+SU(J), у которой fsck освобождает свободное пространство от мусора (вследствие незавешённых транзакций), фактически актуализируя последний снапшот перед сбоем ФС, в котором все транзакции подтверждены, а данные заморожены.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	82. "Набор патчей, заметно увеличивающих производительность работ..."	+1 +/–
	Сообщение от Аноним (??) on 01-Окт-12, 22:20
	> И много у вас таких "багофич"? Для ZFS нет понятия "не до > конца записался файл": он либо записался на диск весь целиком, либо > не записался — третьего (промежуточного состояния) не дано Говоришь, нет кэширования на запись? Ну-ну.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	97. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 03:43
	> Говоришь, нет кэширования на запись? Ну-ну. Он просто еще не понял что в указанной им ситуаци на CoW-based ФС при этом файл вообще не будет существовать. Просто потому что дописаться не успел, а значит "его вообще не существовало".
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	96. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 03:42
	> конца записался файл": он либо записался на диск весь целиком, либо > не записался — третьего (промежуточного состояния) не дано, Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый. Ты доволен? :)
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	104. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 12:04
	>> конца записался файл": он либо записался на диск весь целиком, либо >> не записался — третьего (промежуточного состояния) не дано, > Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый. > Ты доволен? :) Тот, который писался с нуля и незавершилась транзакция по его записи? Испарился — прекрасно, так как не нужно разгребать весь тот бред, что записалось, а что нет. Недописанный в транзакции файл будет оставаться в том состоянии, в котором его оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	120. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 21:54
	> Недописанный в транзакции файл будет оставаться в том состоянии, в котором его > оставили в предыдущей (завершённой) транзакции. Всё по-честноку. Есть ещё вопросы к ФС? Это даже не столько к ФС сколько к общему свойству CoW механики. Как-то сильно по другому это реализовывать просто нелогично.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	98. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-12, 03:45
	> освободит пространство от мусора и будет целостной и непротиворечивой. Ты не поверишь, но btrfs делает примерно то же самое. Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а идея в целом - меняется мало.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	105. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от iZEN (ok) on 02-Окт-12, 12:17
	>> освободит пространство от мусора и будет целостной и непротиворечивой. > Ты не поверишь, но btrfs делает примерно то же самое. С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть ли не в каждом посте о достоинствах Btrfs приводите это как полезную фичу :) Заметьте, я не предлагаю повсеместно вырубать проверку чексумм на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) ) > Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а > идея в целом - меняется мало. Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck. Включение журналирования всего и вся приводит к ощутимым тормозам. А вот в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение журналирования на томе с UFS2+SU позволяет привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись. Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	116. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от qux (ok) on 03-Окт-12, 14:20
	> привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись А ведь еще когда предупреждали — не надо говорить за всю сеть.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	122. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 22:16
	> А ведь еще когда предупреждали — не надо говорить за всю сеть. Это изен.  Тупо лажаться - его фирменный стиль :)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	121. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-12, 22:13
	> С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть > ли не в каждом посте о достоинствах Btrfs приводите это как > полезную фичу :) Это полезная фича для очень нишевых применений. Которые сами себя журналят и потому клещатся с CoW. > Заметьте, я не предлагаю повсеместно вырубать проверку чексумм > на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) ) Я думаю что на этом сильно много не выиграешь. Оно упирается в обсчет чексумм только на дистрофическом процессоре и очень высоких скоростях. В бенчах тоже никто CoW не отключает. Это точечная ситуационная мера для адресных применений когда логика CoW не стыкуется с логикой работы с журналируемой структурой типа БД. > Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с > помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck. Может и не вычиститься. Это на классике технически невозможно при случае когда крах случился в середине записи а журналинг был только для метаданных. Нет данных для докатывания транзакции до конца или откатывания. А полный журналинг тормозит т.к. 2 раза приходится все писать. В cow сделали финт ушами и обошли эту проблему сбоку. По сути сделав ФС одним большим журналом. > Включение журналирования всего и вся приводит к ощутимым тормозам. А вот > в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение > журналирования на томе с UFS2+SU позволяет привести ФС и данные в > непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются > новые технологии от устаревших, К конкретно этому элементу UFS у меня особых претензий нет. А вот общая архаичность устройства дисковых структур и потому общая тормозливость дизайна - никуда не делась. Вот смотри: у меня десктоп подперт упсой. Ноут сам себе упс. Когда я видел в последний раз кернел паник - я и не помню даже. Несколько лет назад, очевидно. Т.е. в общем то крахов то как раз и не происходит. Неоткуда. Т.е. злободневность проблемы сильно снижена иными техническими мерами. А вот тормозливость файловой системы я могу видеть каждый день. Стоит ли говорить что при указанном раскладе я заинтересован еще и в скорости работы? Потому что надежность и так обеспечена. Не теми мерами так иными (роялит то в конце концов результат). > а не скоростными режимами, которые нафик никому не впёрлись. См. выше. Мне скоростные режимы вполне себе вперлись. Я не нанимался машины ждать. Пусть они меня ждут. Надежность - это хорошо. Еще 1 уровень страховки - тоже. Но если это приведет к 6мб/сек на шпиндель, мне такое решение и даром ни к чему. Т.к. меня не устраивают его параметры. > Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу. А кто сказал что у меня с надежностью проблемы? За последние несколько лет я вообще никаких данных не терял по вине ФС. В принципе. Я не спорю что чексуммы - хорошо. Мало ли, вдруг там фирмвара сдуреет или помеха на кабеле? Там конечно свои слои ECC/чексумм, но есть маленькая но ненулевая вероятность что и они облажаются. По поводу чего еще слой поверх - это в принципе хорошо. Равно как и недеструктивная запись aka возможность передумать и вернуть в вид как было. Ну вот в btrfs все это есть. При этом оно не настолько убер-тормоз как ZFS. Чем и лучше, собственно.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема