forum.opennet.ru

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

Оглавление

Набор патчей, заметно увеличивающих производительность работ..., opennews (??), 30-Сен-12, (0) [смотреть все]

хм начиная читать думал там цифра будет не 20, а 200 , начало было куда более, Аноним (-), 22:13 , 30-Сен-12, (1) +2 //

А ты сам оптимизни хоть какую ФС на 20 и порассуждай потом , Аноним (-), 22:40 , 30-Сен-12, (4) +1 //

Сперва добейся - это убербаян В следующий раз попытайтесь быть пооригинальнее, Аноним (-), 22:55 , 30-Сен-12, (6) //

Еще несколько заплюсовавших ценителей чужого труда поддерживают вашу точку з, Аноним (-), 01:03 , 01-Окт-12, (13) +1

Не нужно быть поваром, чтобы оценить яичницу, - обтекайте, z (??), 12:38 , 01-Окт-12, (29)

Нужно Потому что не-повара могут высказать мнение, которое лично мне не нравитс, Аноним (-), 15:22 , 01-Окт-12, (55) +1

вот это бред, Аноним (-), 19:40 , 01-Окт-12, (69) –1
Даа, повар лучше знает , продавец лучше знает и т д и т п - попахивает класс, z (??), 14:05 , 02-Окт-12, (107)

И не нужно быть баянистом, чтобы оценивать игру на рваном баяне , Аноним (-), 15:23 , 01-Окт-12, (56)
Да, вот это я понимаю, обтекание В русском языке нет такого синтаксиса , Аноним (-), 15:47 , 01-Окт-12, (57)

На самом деле, есть Эпик , Аноним (-), 16:42 , 01-Окт-12, (64) –1

Epic fail вы хотели сказать , Аноним (-), 02:06 , 02-Окт-12, (91)

В соседней ветке новый ролик от создателей blender оценили, как графан слабоват, XoRe (ok), 01:48 , 02-Окт-12, (89) +1

Офигеть логика Давайте я за 1 копейку на стене точку поставлю, и для кого гр, z (??), 14:09 , 02-Окт-12, (108)

Точку любой аноним поставить может Почему-то никто не хочет смотреть на соотноше, XoRe (ok), 17:03 , 02-Окт-12, (113)
А я бесплатно могу, так что вы неэффективный просаживатель бабла А вот например, Аноним (-), 21:45 , 03-Окт-12, (118)

будь компетентен в обсуждаемом вопросе а уже потом говори об оригинальности ЗЫ , Аноним (-), 03:03 , 01-Окт-12, (18) –4

В вопросе баянов я вполне компетентен, как и любой интернет-пользователь ЧИТД, Аноним (-), 15:09 , 01-Окт-12, (49)
Былинный отказ , Аноним (-), 15:48 , 01-Окт-12, (58)

Это не сперва добейся а прозрачный намек что языком пиндеть - не мешки ворочать , Аноним (-), 14:18 , 01-Окт-12, (36)

Да, говорить правду легко и приятно , Аноним (-), 15:08 , 01-Окт-12, (48)

А вы тоже придерживаетесь мнения, что только эксперт по мужской одежде имеет пра, Аноним (-), 22:56 , 30-Сен-12, (7) //

Аноним говорит что ваш пост глупый и не достоин внимания публики, хоть он и не а, Аноним (-), 01:07 , 01-Окт-12, (14)

Если истинность этого мнения очевидна - то почему бы и нет Не важно, _кто_ говор, Аноним (-), 15:11 , 01-Окт-12, (50)

нет но эксперт по голым людям, очевидно же , Аноним (-), 03:04 , 01-Окт-12, (19)

Значит, если люди видят, что король голый - это ничего не значит, пока не придет, Аноним (-), 15:07 , 01-Окт-12, (47) +1

Бесспорно, достойный результат, но вообще-то это выигрыш в одном конкретном т, другой аноним (?), 13:25 , 01-Окт-12, (31) //

Загрузка фоток пользователями , XoRe (ok), 01:50 , 02-Окт-12, (90)

Просто изначально нужно писать правильно А точнее не писать, а для начала разра, BratSinot (?), 18:33 , 02-Окт-12, (114)

Просто наиболее явные места уже заоптимизировали Так что находить места, где до, dalco (ok), 22:45 , 30-Сен-12, (5) +2 //

Оптимизация оптимизации оптимизаци wait, oh sh-- , Аноним (-), 14:20 , 01-Окт-12, (37)

когда дело касается файловых систем 20 к производительности, это просто огром, jedie (?), 23:07 , 30-Сен-12, (8) +3 //

не просто 20 к производительност -- а именно в тесте на создание 100 тыс файл, Xasd (ok), 00:10 , 01-Окт-12, (9) +1 //

Ты под досом до сих пор сидишь , Аноним (-), 01:27 , 01-Окт-12, (15) –3
Их даже почти наверняка не будет т к как правило большую часть времени ФС вообщ, Аноним (-), 14:21 , 01-Окт-12, (39)

Вас послушать, так можно вообще ничего не оптимизировать, все равно бесполезно В, Аноним (-), 15:20 , 01-Окт-12, (54)

Я всего лишь подшучиваю над теми кто полагает что оптимизации не требуются и или, Аноним (-), 15:52 , 01-Окт-12, (59)

зато когда потоков будет уже 100 - можно заиметь провал в производительности Н, Аноним (-), 22:25 , 01-Окт-12, (83) –1

А где бенчи на 100 потоков , Аноним (-), 03:46 , 02-Окт-12, (99)

ну там и 2000 мало будет Пока, увы, еле ворочается, по крайней мере, на дексто, pro100master (ok), 22:25 , 30-Сен-12, (2) //

Хотели _полный_ аналог ZFS Получите и распишитесь Осталось только жрач памяти д, Аноним (-), 22:28 , 30-Сен-12, (3) +7 //

А фоновое шифрование когда будет , mylefthand (?), 00:20 , 01-Окт-12, (11) //

А фоновое шифрование - это как По идее, если возникла необходимость в шифровк, dalco (ok), 09:52 , 01-Окт-12, (25)

Конечно неправильно, все данные попадают на диск уже зашифрованными , ааноним (?), 20:17 , 01-Окт-12, (74)

Когда выйдет проприетарная версия , Аноним (-), 15:19 , 01-Окт-12, (53)

Проприетарная версия GPLнутого кода Это как , Аноним (-), 19:59 , 01-Окт-12, (70)

А RAID-5 не говоря уж о RAID-6 и дедупликации в Btrfs когда будет , iZEN (ok), 09:34 , 01-Окт-12, (24) //

у мня есть raid6, могу поставить btrfs, только зачем мне там еще raid5 , ха (?), 14:20 , 01-Окт-12, (38) +2
А как насчет trim и нормальных экстентных аллокаторов , Аноним (-), 14:22 , 01-Окт-12, (40) +5

В Btrfs нет TRIM и экстентного аллокатора Это печально, да Вон, в ZFS код для , iZEN (ok), 14:41 , 01-Окт-12, (42) –2

В btrfs они есть изначально А ZFS даже экстентов нет, так что она сoсет не наг, Аноним (-), 15:13 , 01-Окт-12, (51) +3
Да, таскать кривые ненужные костыли из линyпса любой дурак может А вот утащить, Аноним (-), 15:14 , 01-Окт-12, (52) +1
Там то они как раз есть Вот это я и называю ZFSLoL Ну так и сабжевый патч прин, Аноним (-), 15:54 , 01-Окт-12, (60) +2
А говорил не нужно, да Оказалось просто запилить было некому , filosofem (ok), 23:11 , 01-Окт-12, (86) +1

Давай яснее определю свою позицию по поводу TRIM Для задач, которым важен большо, iZEN (ok), 23:26 , 01-Окт-12, (87)

Скажу тебе как Капитан Капитану использовать блок 512к только потому что ФС не , filosofem (ok), 23:44 , 01-Окт-12, (88)

Это изен и это далеко не самый мощный маразм который он может выдать , Аноним (-), 02:19 , 02-Окт-12, (93) –1
На многогигабайтных видеофайлах и даже на flac-файлах мультимедиа-библиотеки NA, iZEN (ok), 11:59 , 02-Окт-12, (103)

Напоминаю, TRIM это для SSD , filosofem (ok), 14:22 , 02-Окт-12, (109)

SSD не используется для видеомонтажа Странно Не знал , iZEN (ok), 14:49 , 02-Окт-12, (110)

ZFS годится только для видеомонтажа, буду знать , filosofem (ok), 16:01 , 02-Окт-12, (111) –1
И под файлопомойку тоже 8212 отметьте там у себя , iZEN (ok), 16:23 , 02-Окт-12, (112)
Для помойки что она даёт эксклюзивного Дедупликацию и RAID5 С дедупликацией те , filosofem (ok), 09:41 , 03-Окт-12, (115)
Надёжность и самоверифицируемость хранимых данных Если какой-то носитель в избы, iZEN (ok), 20:29 , 03-Окт-12, (117)

XFS - разновидность обычного экстентного аллокатора Просто оптимизанутая на мно, Аноним (-), 21:49 , 03-Окт-12, (119)

Да кужа уж яснее Она болтается как флажок на ветру - Если реализации фичи не пр, Аноним (-), 02:10 , 02-Окт-12, (92) –2

у вас чистый 4 2 оно вполне быстрое, по крайней мере на десктопах , Xasd (ok), 00:11 , 01-Окт-12, (10) //

У меня тоже, может это из-за lzo компрессии, mylefthand (?), 00:21 , 01-Окт-12, (12)

Использую на ноутбуке несколько месяцев Выводы противоположные вашим Сжатие LZ, Tav (ok), 02:49 , 01-Окт-12, (16) //

Косынку раскладываем, по тырнетам лазим Или может транк GCC компиляем, клонируе, Аноним (-), 02:57 , 01-Окт-12, (17) //

Разработка, иногда звукозапись через внешний многоканальный интерфейс Ноутбук, Tav (ok), 03:12 , 01-Окт-12, (20)

А оно местами выигрывает, местами проигрывает, так что впечатления от задач силь, Аноним (-), 14:36 , 01-Окт-12, (41)

btrfs лю А остальные - нет , Аноним (-), 15:55 , 01-Окт-12, (61)

У меня тоже с выводами было, как у вас пока я не заметил, что кубунта обновля, pro100master (ok), 09:20 , 01-Окт-12, (23) //

Все правильно При обновлении fsync на fsync е сидит и fsync ом погоняет И для , dalco (ok), 11:12 , 01-Окт-12, (26)

Для образов виртуальных машин в btrfs следует отключать режим COW chattr C , Tav (ok), 13:27 , 01-Окт-12, (32)

Ага, лишившись всех остальных плюшек в процессе Почему-то zfs замечательно хост, Stax (ok), 14:08 , 01-Окт-12, (35)

Зачем вам снапшоты снапшотов, сэр , Аноним (-), 15:56 , 01-Окт-12, (62)

Чтоб было, очевидно же В конце концов, в слояровских виртуалках с этим похренове, Аноним (-), 16:43 , 01-Окт-12, (65)

Ну тогда смиритесь с тем что одна и та же работа многократно размножается Цена , Аноним (-), 20:02 , 01-Окт-12, (71)

верно, но на январь-май период моих игр и тестов проблема сохранялась и советы, pro100master (ok), 13:42 , 01-Окт-12, (33)
У нее sync медленный Но там оно не сильно то и надо там раз в 30 секунд автосн, Аноним (-), 14:54 , 01-Окт-12, (43)

Ну, изначально речь про убунту шла У нее apt-get кажись А вообще, если верить , dalco (ok), 17:01 , 01-Окт-12, (66)

Правильно Правда давать советы даже не зная что за программа - это забавно За, Аноним (-), 20:05 , 01-Окт-12, (72)

Кхм, я разве строил из себя гуру и давал 100 правильные советы Я всего лишь ук, dalco (ok), 06:55 , 02-Окт-12, (100) +1

Резонно Вот вам плюсик за здравый смысл Ну да Но теряем, так что если клювом к, Аноним (-), 11:23 , 02-Окт-12, (102)

вы это расскажите хейтерам zfs а то им фороникс сказал что btrfs самая быстрая , Клыкастый (ok), 12:33 , 01-Окт-12, (28)

Опять тут граждане с батхертом Да, по большинству бенчей ZFS не показывает ниче, Аноним (-), 14:57 , 01-Окт-12, (44)

задумчиво вот объясните мне пожалуйста, как так получается, что тормозное гов, Клыкастый (ok), 19:31 , 01-Окт-12, (68)

Да, а еще теплое тяжелее мягкого Так btrfs тоже в продакшене молотит и не жужжит, Аноним (-), 20:17 , 01-Окт-12, (73) +2
А тут все просто Достаточно быть бсдшником и тогда любая окаменелая какашка мам, Аноним (-), 20:29 , 01-Окт-12, (75) +3

Чего ты тут сидишь и рассусоливаешь про Btrfs и экстенты Иди вон туда http w, iZEN (ok), 21:30 , 01-Окт-12, (79)

Если им зонд из задницы выдернуть, они и так свалят, безо всяких популярных лекц, Аноним (-), 22:18 , 01-Окт-12, (81) +1

тут главное не бежать в каноникл а то воткнут тот самый зонд в голову, да не по, Клыкастый (ok), 23:02 , 01-Окт-12, (85)

Вот уж не подумал бы что каноникал воткнул зонд izen-у и прочим nagual-ам Но су, Аноним (-), 02:24 , 02-Окт-12, (94)

они бегают анонимом по опеннету да похожесть для всех такая разная , Клыкастый (ok), 11:08 , 02-Окт-12, (101)
Не знаю По описальнику подходят - несут ламерский буллшит с умным видом, а заод, Аноним (-), 22:22 , 03-Окт-12, (123)

Какой сочный баттхёрт С какого перепугу Я взял совершенно одинаковые задачи в с, Клыкастый (ok), 22:55 , 01-Окт-12, (84) –1

Считать обычный капитанинг батхертом - оригинально Видимо, реально батхерт Ну д, Аноним (-), 03:32 , 02-Окт-12, (95)

Истинно Капитанинг и рядом не стоял сырцы ядра, мира, порты vs портежи расскаж, Клыкастый (ok), 13:53 , 02-Окт-12, (106) +1

С обновлением Федоры ничего такого не заметил Либо yum и rpm что-то делают инач, Tav (ok), 13:24 , 01-Окт-12, (30)

OpenSuse тоже себя так ведёт Проблема не в вендоре , pro100master (ok), 13:45 , 01-Окт-12, (34)

Если нет задач постоянно создающих файлы сотнями тысяч в 10 потоков, то результа, deadless (ok), 08:07 , 01-Окт-12, (21) //

Удаление файлов тоже должно ускориться по идее , filosofem (ok), 11:24 , 01-Окт-12, (27) –1
Как бы ситуация с параллельным доступом к файлам - совершенно нормальна для мног, Аноним (-), 14:59 , 01-Окт-12, (45)

кэши надо больше кэшей чего там иноды, надо уже и данные засовывать в кэши , Аноним (-), 08:11 , 01-Окт-12, (22) //

Давно реализовано - системный кэш именно это и делает Тем паче что в пингвине о, Аноним (-), 15:01 , 01-Окт-12, (46) //

Я видел, как в Ubuntu ещё в версии v 6 06 у меня на 4GB флэшку большой файл ко, iZEN (ok), 16:17 , 01-Окт-12, (63) //

О, еще один неандерталец открыл для себя дисковый буффер , Аноним (-), 20:41 , 01-Окт-12, (77)

Тут у меня после зависания 2 с лишним гигабайта испарились Но улетали они на ди, Аноним (-), 17:44 , 01-Окт-12, (67) //

Я не считаю зависания системы нормальной ситуацией, для начала Если система глю, Аноним (-), 20:39 , 01-Окт-12, (76)

И много у вас таких багофич Для ZFS нет понятия не до конца записался файл , iZEN (ok), 21:40 , 01-Окт-12, (80)

Говоришь, нет кэширования на запись Ну-ну , Аноним (-), 22:20 , 01-Окт-12, (82) +1

Он просто еще не понял что в указанной им ситуаци на CoW-based ФС при этом файл , Аноним (-), 03:43 , 02-Окт-12, (97)

Ну хорошо, у тебя в этом состоянии испарится не полфайла а целый Ты доволен , Аноним (-), 03:42 , 02-Окт-12, (96)

Тот, который писался с нуля и незавершилась транзакция по его записи Испарился , iZEN (ok), 12:04 , 02-Окт-12, (104)

Это даже не столько к ФС сколько к общему свойству CoW механики Как-то сильно п, Аноним (-), 21:54 , 03-Окт-12, (120)

Ты не поверишь, но btrfs делает примерно то же самое Просто потому что это обыч, Аноним (-), 03:45 , 02-Окт-12, (98)

С чего бы вдруг Вы же намеренно отключаете CoW у Btrfs Чуть ли не в каждом по, iZEN (ok), 12:17 , 02-Окт-12, (105)

А ведь еще когда предупреждали 8212 не надо говорить за всю сеть , qux (ok), 14:20 , 03-Окт-12, (116)

Это изен Тупо лажаться - его фирменный стиль , Аноним (-), 22:16 , 03-Окт-12, (122)

Это полезная фича для очень нишевых применений Которые сами себя журналят и пот, Аноним (-), 22:13 , 03-Окт-12, (121)

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

46. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 01-Окт-12, 15:01

> данные засовывать в кэши!
Давно реализовано - системный кэш именно это и делает. Тем паче что в пингвине он может по дефолту юзать почти всю свободную оперативу, на лету урезая осетра по мере того как память становится нужна другим. Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.
Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)

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

63. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от iZEN (ok), 01-Окт-12, 16:17

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

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

77. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 01-Окт-12, 20:41

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

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

67. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 01-Окт-12, 17:44

>Никогда не видели как DVD-sized исоха улетает на диск за 3 секунды? Ну да, не всем в этой жизни везет :)
Тут у меня после зависания 2 с лишним гигабайта испарились. Но улетали они на диск дольше
>Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.
И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти своим г..ном и все начинает тормозить

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

76. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 01-Окт-12, 20:39

> Тут у меня после зависания
Я не считаю зависания системы нормальной ситуацией, для начала. Если система глюкавая и не работает корректно - там может быть что угодно. И потеря данных, и искажение, и марсианский десант. Мало ли чего.
> 2 с лишним гигабайта испарились. Но улетали они на диск дольше
Логично что при внеплановом ребуте кэш не успеет записаться. Чудес не бывает. Ну а так срубилась бы запись на середине файла. Какая нафиг разница - кэшированная запись не успеет дописать файл или некэшированная. С точки зрения порчи файла - одинаково. А вот ждать окончание копирования файла - не особо приятно. Да, надо понимать что такая операция без явного fsync - не является полностью завершенной, хоть и выглядит таковой. Багофича кеширования.
Ну, отключите кэши и получите то что хотите, если вам так больше нравится, кому хуже будет? :)

>>Все это очень положительно влияет на работу дисковой подсистемы вообще независимо от ФС.
> И это хорошо. Вот только какой нибудь торрент вытесняет кэш из памяти
> своим г..ном и все начинает тормозить
Ну а тут уже или система или руки. Или торрент-клиент горбатый/недооптимизированный (при желании может сильно облегчить жизнь ФС). У меня почему-то активно пашущий торрент проблем не вызывает. И в принципе не может. Просто потому что скорость работы HDD на порядок превосходит скорость сети.

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

80. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от iZEN (ok), 01-Окт-12, 21:40

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

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

82. "Набор патчей, заметно увеличивающих производительность работ..." +1 +/–

Сообщение от Аноним (-), 01-Окт-12, 22:20

> И много у вас таких "багофич"? Для ZFS нет понятия "не до
> конца записался файл": он либо записался на диск весь целиком, либо
> не записался — третьего (промежуточного состояния) не дано
Говоришь, нет кэширования на запись? Ну-ну.

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

97. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 02-Окт-12, 03:43

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

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

96. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 02-Окт-12, 03:42

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

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

104. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от iZEN (ok), 02-Окт-12, 12:04

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

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

120. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 03-Окт-12, 21:54

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

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

98. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 02-Окт-12, 03:45

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

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

105. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от iZEN (ok), 02-Окт-12, 12:17

>> освободит пространство от мусора и будет целостной и непротиворечивой.
> Ты не поверишь, но btrfs делает примерно то же самое.
С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть ли не в каждом посте о достоинствах Btrfs приводите это как полезную фичу :) Заметьте, я не предлагаю повсеместно вырубать проверку чексумм на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) )
> Просто потому что это обычный подход к крашрекавери для cow. Детали отличаются а
> идея в целом - меняется мало.
Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck. Включение журналирования всего и вся приводит к ощутимым тормозам. А вот в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение журналирования на томе с UFS2+SU позволяет привести ФС и данные в непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются новые технологии от устаревших, а не скоростными режимами, которые нафик никому не впёрлись. Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.

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

116. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от qux (ok), 03-Окт-12, 14:20

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

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

122. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 03-Окт-12, 22:16

> А ведь еще когда предупреждали — не надо говорить за всю сеть.
Это изен. Тупо лажаться - его фирменный стиль :)

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

121. "Набор патчей, заметно увеличивающих производительность работ..." +/–

Сообщение от Аноним (-), 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


	121. "Набор патчей, заметно увеличивающих производительность работ..."	+/–
	Сообщение от Аноним (-), 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ообщить модератору