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

Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..., opennews (?), 10-Янв-12, (0) [смотреть все] А как одновременно использовать noop и этот ваш fiops , ВКПб (?), 20:55 , 10-Янв-12, (1) // Или трусы или крестик Хотя назначить вон тому девайсу одно, а вот энтому другое, Аноним (-), 21:32 , 10-Янв-12, (4) +4 Можно cat sys class block sda queueschedulernoop cfq echo noop sys clas, Oleg (??), 10:26 , 11-Янв-12, (46) +1 // А можна на dev sda, для MySQL юзать CFQ, а для марьяжа noop для остальных на, pavlinux (ok), 17:15 , 11-Янв-12, (71) // Отправил ваши пожелания разработчикам Впредь, пожалуйста, делайте это самостоят, Ваня (??), 17:52 , 11-Янв-12, (76) +1 Ты бы подумал головой Планировщик IO на разделах одного блочного ус-ва не имеет, Аноним (-), 18:02 , 11-Янв-12, (78) +1 Ты бы подумал головой Чем раздел раздел блочного уст-ва отличаетсяот всего блоч, pavlinux (ok), 19:33 , 11-Янв-12, (94) +4 Ну так запатч сорц чтобы в зависимости от того чья запись юзался разный шедулер , Аноним (-), 18:03 , 11-Янв-12, (79) Ну если многое написанное это флудъ, то о динамической смене шедулера при просто, pavlinux (ok), 19:36 , 11-Янв-12, (98) Типа, шедулить ничегонеделание накопителя да еще динамически менять алгоритм нич, Аноним (-), 06:55 , 12-Янв-12, (123) Ну как критерий ничегонеделания, я предложил if iowait 5 Смысл переколбашив, pavlinux (ok), 23:42 , 12-Янв-12, (153) Может быть я конечно ошибаюсь, но разве сегодня кто-то вообще пытается делать оп, klalafuda (?), 21:10 , 10-Янв-12, (2) // время позиционирования практически линейно растёт с дистанцией перемещения голов, koct9i (?), 21:44 , 10-Янв-12, (5) +3 Man NCQ, хотя бы Относительно свежая технология, встраиванием которой не так да, Аноним (-), 21:50 , 10-Янв-12, (6) +2 // И насколько процентов увеличивается производительность совремнных винчестеров пр, iZEN (ok), 23:10 , 10-Янв-12, (8) –3 // Это одна из техник, вместе с прочими, такими, как в новости, прирост может быть , Аноним (-), 23:39 , 10-Янв-12, (12) +1 Это он видимо пытался как обычно сказать у меня нет, поэтому мне это не нужно , Аноним (-), 20:47 , 13-Янв-12, (164) 5-7 это лучше чем 0 И вообще, это весьма приличный прирост в определенных слу, Аноним (-), 05:17 , 11-Янв-12, (27) +1 Поэтому какойнить ext4 еще и реализует delayed allocation, в надежде нагрести по, Аноним (-), 07:10 , 11-Янв-12, (31) +2 NCQ работает с геометрией диска только внутри девайса, со стороны ОС это просто , all_glory_to_the_hypnotoad (ok), 00:18 , 11-Янв-12, (18) +1 // Другими словами, это интерфейс для оптимизации работы с данными , Аноним (-), 00:54 , 11-Янв-12, (21) –1 Неужели в Linux только сейчас начали избавляться от зависимости планирования дис, iZEN (ok), 23:07 , 10-Янв-12, (7) –2   // Судя по книжке Ой, Великий и Могучий BSDшнег Изен оказывается не читал исходник, ДашенькаАнонимочка (?), 23:17 , 10-Янв-12, (10) +4   // Не, в geom есть и продвинутый планировщик, с 2008 анонсирован кажись http re, uniman (?), 23:56 , 10-Янв-12, (13)   // Ага Только народ его в 9 ке увидел , iZEN (ok), 00:00 , 11-Янв-12, (16)   PSишшо с картинкамиhttp info iet unipi it luigi geom_sched , uniman (?), 23:59 , 10-Янв-12, (14)   Ну не читал - дык я и не припомню чтоб он заявлял де учавствует в разработке под, Anonymouse (?), 00:00 , 11-Янв-12, (15)   // При том это диагноз Гарантирующий на 99 9 что субъект никогда не сможет понять, Аноним (-), 21:56 , 11-Янв-12, (114) –2   Вообще полезно изучать иногда историю на предмет принятия того или иного ключево, iZEN (ok), 00:02 , 11-Янв-12, (17) +2   // В те поры не могли принимать решения для удобства ssd по причине отсутствия тако, Аноним (-), 07:50 , 11-Янв-12, (41)   2005 годhttp www freebsd org doc ru articles 5-roadmap major-issues html----GE, uniman (?), 00:37 , 11-Янв-12, (19)   // Так цель размазки не сделать ssd быстрее чем он есть, а разделить кашу между пол, Аноним (-), 07:49 , 11-Янв-12, (40) +1   Да, только заявлять, что его простота - это превосходство над Linux глупо И, кс, xxx (??), 10:28 , 11-Янв-12, (47)   Найдите хоть слово, где я написал о превосходство над ХХХ Неужели вы нашли в мо, uniman (?), 15:54 , 11-Янв-12, (62)   Это касалось iZen а и его любви везде упоминать FreeBSD как верх совершенства Ра, xxx (??), 19:34 , 11-Янв-12, (96)   Не, а че, товарищь в антитезу масссового упоминающим про верх совершенства систе, uniman (ok), 21:49 , 11-Янв-12, (112)   Нет, что ты, они технически аргументировано упоминают о проблемах GEOM А opennet, xxx (??), 08:57 , 12-Янв-12, (129)   О проблемах Ух как С каких пор математико-инженерные задачи по продумыванию и , uniman (ok), 00:30 , 13-Янв-12, (156)   Не вмешиваясь в выяснение благородных донов, отмечу, что по-аглицки задача в , Michael Shigorin (ok), 15:04 , 14-Янв-12, (168)   во-первых, мы не англицкие - годы совдепии изменили лингвистичекую картину насто, uniman (ok), 00:08 , 15-Янв-12, (169)   Разумеется А кто три язычен, тем можно заметить, что данный Вами ниже однозначны, Michael Shigorin (ok), 00:18 , 15-Янв-12, (170)   да нифига оригинального если в англиском это более трудная ситуация, выкрутитьс, uniman (ok), 00:30 , 15-Янв-12, (171)   Будьте добры, почитайте хотя бы http en academic ru dic nsf cide 139309 Prob, Michael Shigorin (ok), 00:57 , 15-Янв-12, (172)   Не буду У меня стоит dict локально Report in wake of phone hacking scandal say, uniman (ok), 01:29 , 15-Янв-12, (173)   155, Michael Shigorin (ok), 01:44 , 15-Янв-12, (174)   в GEOM намеренно отказались от учёта физических параметров Так вот почему дисков, Аноним (-), 00:53 , 11-Янв-12, (20) –1   // Тормозили в 2005-2007г г , когда был GIANT_LOCK Сейчас этого нет 8212 избави, iZEN (ok), 01:25 , 11-Янв-12, (22) –3   // и мне не понятно ни разу не попадался врёшь как троцкий на том железе, где возм, ананим (?), 02:30 , 11-Янв-12, (24)   Мне тоже Но изену же виднее Хоть он и видел линуксы только на картинке Тсс Не, Аноним (-), 07:46 , 11-Янв-12, (38) –2   А я вот его частенько ощущаю , savant (ok), 11:40 , 11-Янв-12, (48) +1   Притащили недавно восьмигиговую USB-флэшку, попросили занулить Оставил, вскоре, Michael Shigorin (ok), 16:06 , 11-Янв-12, (65) +1   ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться , savant (ok), 16:23 , 11-Янв-12, (68) +1   А я думал что она прилегает в основном потому что если процессу понадобились стр, Аноним (-), 18:08 , 11-Янв-12, (81)   Эта грабля появилась в Linux 2 1, стукнула по нам со всего размаху с перехода на, netch (ok), 20:17 , 23-Янв-12, (180)   А это вообще мало кому понятно Этот баг лезет далеко не везде, иначе его давно , Аноним (-), 07:45 , 11-Янв-12, (37) –1   Лехко, постоянно так делаю Ставишь приоритеты nice ionice в make conf и вперед , фтыш (?), 14:53 , 11-Янв-12, (60) +1   А если не ставить приоритеты Я не ставлю У меня на этот счёт нет никаких замо, iZEN (ok), 17:50 , 11-Янв-12, (75)   А если рельсу анекдот про японскую пилу vs суровые сибирские мужики , Аноним (-), 21:51 , 11-Янв-12, (113)   С равным уровнем оптимизации , Аноним (-), 11:15 , 17-Янв-12, (175)   Неумением понимать, что ценность изменённых dirty страниц в кэше диска значите, netch (ok), 20:22 , 23-Янв-12, (181)   Бздя - это новая файловая система в Linux Попробуйте использовать ее надлежащим , uniman (?), 16:01 , 11-Янв-12, (63) –2   Проще говоря, нормальный планировщик IO там написать так и не осилили , Аноним (-), 06:04 , 11-Янв-12, (30) +1   // Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол, э, Аноним (-), 07:40 , 11-Янв-12, (36)   // Для тех кто в танке http ivoras net freebsd freebsd9 htmlGeneric GEOM IO sched, uniman (?), 17:04 , 11-Янв-12, (70)   Да, он не планирует за для походы за продуктами в магазин Это несомненно недост, uniman (?), 16:04 , 11-Янв-12, (64) –2   // Не тот случай когда 1 размера хватает всем Поэтому у пингвиноидов их вон на выб, Аноним (-), 07:01 , 12-Янв-12, (125)   То есть критерии стратегирования файловой системы вы сформулировать не компетент, uniman (ok), 02:19 , 13-Янв-12, (157)   Угу Хотя-бы потому что не знаю какие еще в будущем будут накопители Ну вот нап, Аноним (-), 20:43 , 13-Янв-12, (161)   Те, в разработке интефейсов к которым вы примете горячее участие Впереди планеты, uniman (ok), 22:01 , 13-Янв-12, (167)   А в этом что-то есть Например, осознать что UFS всего лишь древний помет мамонт, Аноним (-), 16:43 , 01-Фев-12, (187)   Судя по тексту, вы в этом вопросе разобрались В каком месте код устарел и не от, uniman (ok), 18:05 , 01-Фев-12, (190)   Напротив, сделали планировщик специально для конкретного типа устройств хранения, Аноним (-), 07:18 , 11-Янв-12, (32) –1   // Гм, матчасть Вообще-то посылать TRIM - не дело слоя FS с бородатого года В ко, uniman (?), 16:22 , 11-Янв-12, (67) +2   // Что - матчасть ФС лучше всех остальных знает когда вон те данные на ФС уже ником, Аноним (-), 18:27 , 11-Янв-12, (83)   Иницировать - это да Может быть Блин Матчасть Никто не чистит блоки В ни, uniman (ok), 19:01 , 11-Янв-12, (86) –1   Ну я при случае залезу в сорц и посмотрю как они это делают Все-таки любопытно , Аноним (-), 21:42 , 11-Янв-12, (110)   Ну спасибо Теперь буду жить по другому Стану бриться и перестану ругаться мато, uniman (ok), 21:59 , 11-Янв-12, (115) –1   Подляна состоит в том что нативную механику флеша вывешивать как некий интерфейс, Аноним (-), 22:25 , 11-Янв-12, (116)   Ну так Мир несовершенен И я бы так сделал Или вы хотите лет пяток подождать д, uniman (ok), 23:06 , 11-Янв-12, (120)   Ну так А наша цель - этой механике подыграть Тому что по факту есть, а не тому, Аноним (-), 07:25 , 12-Янв-12, (126)   Тебя ждали , uniman (ok), 18:51 , 12-Янв-12, (142)   Круто , Аноним (-), 20:14 , 12-Янв-12, (144)   Да неужто А зачем Наверное, для того что бы в них можно было что-то записать М, uniman (ok), 22:26 , 11-Янв-12, (117)   Да Потому что в отличие от магнитного диска на флеше нельзя просто взять и пере, Аноним (-), 08:20 , 12-Янв-12, (127)   Батенька, вы еще не поняли что это издевка над вашим поучительством Стандарт CDR, uniman (ok), 18:43 , 12-Янв-12, (141)   Да ладно вам, не стесняйтесь, я тоже покушать люблю и вы оказались вполне п, Аноним (-), 20:26 , 13-Янв-12, (160)   А пока, вы, батенька, предлагагате прицепить флешь-накопители на soundblaster Ок, uniman (ok), 21:32 , 13-Янв-12, (165)   Прикольный вывод Дерзайте А, круто Теперь дизайньте контроллер под этот ин, Аноним (-), 20:45 , 17-Янв-12, (178)   Так вы обратились к кому-либо со своими перспективными идеями создать новый инте, uniman (ok), 20:53 , 17-Янв-12, (179)   Вообще-то про NOR все пишут, что оно тоже может байтами писаться Та же википеди, netch (ok), 21:56 , 23-Янв-12, (184)   Зависит от чипа Зачастую - натурально может под записью я имею в виду PROGRAM , Аноним (-), 17:07 , 01-Фев-12, (188)   Кроме того, это показывает, что если пересобирается новый комплект блоков, то мо, netch (ok), 21:48 , 23-Янв-12, (183)   gt оверквотинг удален PSСобственно, поскольку как-то указывать что за ху из ху, uniman (?), 16:52 , 11-Янв-12, (69)   Ему вообще-то не совсем по барабану Потому что если, например, для диска лифтов, netch (ok), 21:42 , 23-Янв-12, (182)   // BTW http lkml org lkml 2011 3 25 44, Michael Shigorin (ok), 01:00 , 25-Янв-12, (186)   FIOPS во многом подобен используемому ныне планировщику CFQ, также имеющему нес, Аноним (-), 23:12 , 10-Янв-12, (9) +1 // планировщику CFQ, также имеющему несколько оптимизаций для твердотельных ква, uniman (?), 23:18 , 10-Янв-12, (11) +5 // твёрдотельных параллелепипедов , Aleksey Salow (ok), 03:49 , 11-Янв-12, (25) +4 А винчестер - это вообще винтовка , Аноним (-), 07:19 , 11-Янв-12, (33) +1 // Винчестер - это многовариантное слово от фамилии названия компании до предмета , dRiZd (?), 12:56 , 11-Янв-12, (53) карабин , Аноним (-), 13:26 , 11-Янв-12, (55) +1 И как, есть какой-то прирост Вообще-то для ssd полезно использовать fs которые , Aleksey Salow (ok), 03:54 , 11-Янв-12, (26) –3 // Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывны, Аноним (-), 07:28 , 11-Янв-12, (34) +1 // Ну и жесть Как вообще можно что-то оптимизировать в такой ситуации, когда контр, Аноним (-), 09:14 , 11-Янв-12, (44) // Они оптимизируют разные вещи Напр блок управления карбюратором машины управляе, Ваня (??), 14:31 , 11-Янв-12, (57) В идеале можно попробовать подогнать смещение файловой системы под erase block и, Аноним (-), 18:34 , 11-Янв-12, (84) страница 2kb Запись идёт блоком из 64 страниц, а чтение действительно постранич, Aleksey Salow (ok), 18:52 , 11-Янв-12, (85) Разная у разных флех У мелких бывает и 1 кб У очень больших бывает 4 Или ты п, Аноним (-), 20:26 , 11-Янв-12, (103) Не в идеале , а для начала Иначе и SSD, и 4k-HDD, и RAID5 6 50 60 будут тор, Michael Shigorin (ok), 20:39 , 11-Янв-12, (105) Грабль состоит в том что для флеша это довольно сложно, поскольку истинную геоме, Аноним (-), 21:06 , 11-Янв-12, (107) Минимальный блок для записи - 128K вроде как Сколько там размер сектора 512b , Aleksey Salow (ok), 14:32 , 11-Янв-12, (58) –2 // В ZFS 8212 128k по умолчанию , в UFS2 8212 64k недавно увеличили , iZEN (ok), 17:45 , 11-Янв-12, (73) –1 В zfs под рейды точили походу, а на ufs2 gstripe я тоже делал 64k, страйп быст, Aleksey Salow (ok), 17:48 , 11-Янв-12, (74) Не только ZFS разрабатывали в том числе для использования с SSD Все эти кши, iZEN (ok), 18:00 , 11-Янв-12, (77) А ссылочку можно Мне конечно ssd во фряхе пока не грозит, но мало ли что случит, Aleksey Salow (ok), 18:04 , 11-Янв-12, (80) О перспективах ZFS и флэш-памяти http blogs oracle com jonathan_ru entry о_пе, iZEN (ok), 18:21 , 11-Янв-12, (82) –1 Ага, правда SSD в природе не было в момент дизайна ZFS, но изена такие мелочи не, Аноним (-), 19:34 , 11-Янв-12, (95) Там другое Например, группировка сбросов на диск по их рейтингк ttp constanti, uniman (ok), 21:43 , 11-Янв-12, (111) Если честно, я в этом спиче не вижу ни 1 звука про собственно саму оптимизацию з, Аноним (-), 09:50 , 12-Янв-12, (133) Не видите звуков Оригинально Попробуйте пощупать код на слух , uniman (ok), 18:04 , 12-Янв-12, (140) Тоже не слышно ничего Поэтому процитируйте плиз где там про оптимизацию процесс, Аноним (-), 20:36 , 12-Янв-12, (147) Вообще-то у ZFS сейчас идёт уже где-то 15-я минимум версия пула - это раз Флэшов, netch (ok), 22:04 , 23-Янв-12, (185) +1 А майкрософт на своем сайте так и вообще рассказывал что виндус сервер обгоняет , Аноним (-), 19:38 , 11-Янв-12, (99) Минимальный блок для записи у флеша - страница Обычно 1 4Кб у nand-флешек из , Аноним (-), 19:02 , 11-Янв-12, (87) User294, почему ты не логинишься под своим ником Тебе же сто раз объясняли, что, iZEN (ok), 17:16 , 11-Янв-12, (72) // Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты д, Аноним (-), 19:11 , 11-Янв-12, (89) Карта свободных блоков 8212 битмапы 8212 кэшируются в ОЗУ Для поддержки а, iZEN (ok), 20:18 , 11-Янв-12, (101) И что Это не отменяет нужды читать писать их на диск озу знаешь ли не энергоне, Аноним (-), 20:46 , 11-Янв-12, (106) Ваш генный код старее окаменелого говна мамонта И судя по вашему тексту, назват, uniman (ok), 22:49 , 11-Янв-12, (119) Мы существа одного вида, поэтому вам наверное недостатки видны не хуже меня, на , Аноним (-), 20:15 , 13-Янв-12, (159) Точно, реализация FS не относиться к SSD никак Кстати, о чем новость Перечитайт, uniman (ok), 20:46 , 13-Янв-12, (163) Не согласен Есть более удобные и менее удобные для ssd файловые системы, более , Аноним (-), 17:17 , 01-Фев-12, (189) А мне вот интересно вроде как во всех мануалах по оптимизации под SSD рекоменду, Аноним (-), 05:22 , 11-Янв-12, (28) // Да собственно работать будет с любым Вопрос в том насколько честно будет попиле, Аноним (-), 07:36 , 11-Янв-12, (35) // Понятно, спасибо Вообще, я под это дело аж 8 гигов памяти купил на ноут В итог, Аноним (-), 09:25 , 11-Янв-12, (45) // а почему не YAFFS или другие специализированные флешечковые файлухи , Анон (?), 15:38 , 11-Янв-12, (61) Потому что для флешки с собственным контроллером все это нахрен не нужно YAFFS , Аноним (-), 19:22 , 11-Янв-12, (90) Скажем так, не то что бы совсем не бывает по 512, но от модели к модели этот пар, Аноним (-), 00:54 , 12-Янв-12, (121) Найти NAND-флешку у которой именно 512-байтные страницы - на данном этапе эволюц, Аноним (-), 10:06 , 12-Янв-12, (135) Ну да, все так У арчеводов кстати вообще довольно много дельных статей на вике , Аноним (-), 19:30 , 11-Янв-12, (92) +1 Видел, сделал сразу Про много писать -- понимаю Просто привел пример с компел, Аноним (-), 01:00 , 12-Янв-12, (122) Кстати прогнал немного, у арчеводов только ссылка на статью, сама статья на друг, Аноним (-), 10:22 , 12-Янв-12, (136) Я часто пересобираю одну большую штуку из git, за разработкой которой внимательн, Аноним (-), 17:37 , 12-Янв-12, (138) Я тоже перекомпиливаю некоторые штуки, но не очень большие и на механическом дис, Аноним (-), 20:12 , 13-Янв-12, (158) CFQ совсем не дурак, он различает винчестеры и SSD sys block sdX queue rotatio, Stax (ok), 14:44 , 11-Янв-12, (59) +2 IMO noop или deadline , Michael Shigorin (ok), 16:12 , 11-Янв-12, (66) 1,2,7,9,26,28

Сообщения

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

7. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
Сообщение от iZEN (ok), 10-Янв-12, 23:07
Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный планировщик I/O, которому в общем-то по барабану, с каким накопилем он работает — с HDD или SSD.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+4 +/–
	Сообщение от ДашенькаАнонимочка (?), 10-Янв-12, 23:17
	Судя по книжке? Ой, Великий и Могучий BSDшнег Изен оказывается не читал исходников даже, раз "судя по книжке". А гонору то сколько постоянно, а на деле оказалось... тьфу
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 10-Янв-12, 23:56
	Не, в geom есть и "продвинутый" планировщик, с 2008 анонсирован кажись. http://retis.sssup.it/~fabio/freebsd/geom_sched/proto/ # man gsched NAME      gsched -- control utility for disk scheduler GEOM class SYNOPSIS      gsched create [-v] [-a algorithm] provider ...      gsched insert [-v] [-a algorithm] provider ...      gsched configure [-v] [-a algorithm] node ...      gsched destroy [-fv] node ...      gsched reset [-v] node ...      gsched { list | status | load | unload } DESCRIPTION      The gsched utility (also callable as geom sched ...) changes the schedul-      ing policy of the requests going to a provider. ... # geom disk list Geom name: ada0 Providers: 1. Name: ada0    Mediasize: 160041885696 (149G)    Sectorsize: 512    Mode: r6w6e23    descr: ST9160310AS    ident: (null)    fwsectors: 63    fwheads: 16 # kldload geom_sched # geom sched insert -a rr ada0 # geom disk list Geom name: ada0 Providers: 1. Name: ada0.sched.    Mediasize: 160041885696 (149G)    Sectorsize: 512    Mode: r6w6e23    descr: ST9160310AS    ident: (null)    fwsectors: 63    fwheads: 16 Все это только и на работающей системе. Как бэ все, шедулер вставлен. Провайдер - этот тот кто сверху и к нам ближе :) Тестировать с цифирями долго, нужно нескольк дисков, корректно нагрузить, надо думать о корректности измерений, не готов, оставляю пока на других. http://ivoras.net/freebsd/freebsd9.html Generic GEOM IO schedulers Status: Committed to -CURRENT Will appear in 9.0: sure Authors: Luigi Rizzo, Fabio Checconi Web: commit message The new framework, integrated with GEOM, allows for multiple disk IO schedulers to be used, if necessary, on different IO providers (e.g. drives). The usage of some IO schedulers can increase responsiveness in certain kinds of IO workloads, for example a mix of sequential and random IO. http://svnweb.FreeBSD.org/base?view=revision&revision=206497
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от iZEN (ok), 11-Янв-12, 00:00
	> Не, в geom есть и "продвинутый" планировщик, с 2008 анонсирован кажись. Ага. :) Только народ его в 9'ке увидел: > http://ivoras.net/freebsd/freebsd9.html > Generic GEOM IO schedulers > Status: Committed to -CURRENT > Will appear in 9.0: sure
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 10-Янв-12, 23:59
	PS ишшо с картинками http://info.iet.unipi.it/~luigi/geom_sched/
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	15. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Anonymouse (?), 11-Янв-12, 00:00
	Ну не читал - дык я и не припомню чтоб он заявлял де учавствует в разработке подсистемы хранения фряхи .... насколько я помню - он жабщик :)
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	114. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
	Сообщение от Аноним (-), 11-Янв-12, 21:56
	> - он жабщик :) При том это диагноз. Гарантирующий на 99.9% что субъект никогда не сможет понять как все это на самом деле работает и почему оно именно вот так. Особо клинические еще и умудряются гордиться своей тупостью, например считая указатели чем-то таким из ряда вон.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+2 +/–
	Сообщение от iZEN (ok), 11-Янв-12, 00:02
	> Судя по книжке? Вообще полезно изучать иногда историю на предмет принятия того или иного ключевого решения. Почему именно так, а не иначе сделали, чтобы ошибок не повторять.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	41. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 07:50
	> Вообще полезно изучать иногда историю на предмет принятия того или иного ключевого решения. В те поры не могли принимать решения для удобства ssd по причине отсутствия таковых :)
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 11-Янв-12, 00:37
	> Судя по книжке? Ой, Великий и Могучий BSDшнег Изен оказывается не читал > исходников даже, раз "судя по книжке". А гонору то сколько постоянно, > а на деле оказалось... тьфу 2005 год http://www.freebsd.org/doc/ru/articles/5-roadmap/major-issue... ---- GEOM: уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы ata(4) и aac(4) разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась. [ сейчас уже закончена ] Кроме того, в GEOM имеется опасность снижения производительности из-за обработки ею вышестоящих и нижестоящих потоков данных в потоках выполнения ядра. В решении этой проблемы может помочь улучшение и упрощение технологии переключения контекстов выполнения. ---- И iZen прав, планировщик geom_io действительно простой http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/ http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/geom_i... Заниматься физикой - не дело GEOM. Ниже его есть CAM - common access module, а уж он и обчаеться c ata/scsi. http://svnweb.FreeBSD.org/base/release/9.0.0/sys/cam/ И как ни планируй, все одно... если ssd накопитель занят, более они-с принять не могут и посылает драйвер нафик - то нафик так нафик. Можно как-то размазывать эту манную кашу порциями, дабы дикого тупизма всем и сразу не получилось, но ... шибко это пофик контролеру накопителя, он сам умный.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	40. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 07:49
	> Можно как-то размазывать эту манную кашу порциями, дабы дикого тупизма > всем и сразу не получилось, но ... шибко это пофик контролеру > накопителя, он сам умный. Так цель размазки не сделать ssd быстрее чем он есть, а разделить кашу между получателями относительно честным образом. А не так что один сожрал всю кастрюлю а остальные полдня голодными и злыми сидели.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от xxx (??), 11-Янв-12, 10:28
	> И iZen прав, планировщик geom_io действительно простой > http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/ > http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/geom_i... Да, только заявлять, что его простота - это превосходство над Linux глупо. И, кстати, его простота как раз приводит зачастую к тормозам, об этом уже не раз упоминалось в списках рассылки.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	62. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 11-Янв-12, 15:54
	>> И iZen прав, планировщик geom_io действительно простой >> http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/ >> http://svnweb.FreeBSD.org/base/release/9.0.0/sys/geom/geom_i... > Да, только заявлять, что его простота - это превосходство над Linux глупо. Найдите хоть слово, где я написал о "превосходство над ХХХ" Неужели вы нашли в моем тексте такой сферический идиотизм? > И, кстати, его простота как раз приводит зачастую к тормозам, об > этом уже не раз упоминалось в списках рассылки. Рассуждения о "торморзах" неплохо бы подкреплять аргументами. А то выглядит как путстая трепотня из пустого в порожнее.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от xxx (??), 11-Янв-12, 19:34
	> Найдите хоть слово, где я написал о "превосходство над ХХХ" > Неужели вы нашли в моем тексте такой сферический идиотизм? Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства. > Рассуждения о "торморзах" неплохо бы подкреплять аргументами. Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл). > А то выглядит как путстая трепотня из пустого в порожнее. Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не зная их архитектуры и устройства.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 11-Янв-12, 21:49
	>> Найдите хоть слово, где я написал о "превосходство над ХХХ" >> Неужели вы нашли в моем тексте такой сферический идиотизм? > Это касалось iZen'а и его любви везде упоминать FreeBSD как верх совершенства. Не, а че, товарищь в антитезу масссового упоминающим про верх совершенства систему XXX. >> Рассуждения о "торморзах" неплохо бы подкреплять аргументами. > Разработчики FreeBSD приводят аргументы, см. списки рассылки, BSDCan (гугл). Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые". >> А то выглядит как путстая трепотня из пустого в порожнее. > Пуствая трепотня - это рассуждать о планировщиках ввода-вывода Linux и GEOM, не > зная их архитектуры и устройства. 90% _это_ делают на форумах о сиcтеме XXX? И че? :)
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от xxx (??), 12-Янв-12, 08:57
	>Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые". Нет, что ты, они технически аргументировано упоминают о проблемах GEOM. >90% _это_ делают на форумах о сиcтеме XXX? И че? :) А opennet чем хуже?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 13-Янв-12, 00:30
	>>Угу. Так и пишут в отчетах и презентациях BSDCan - "тармаза ваще глюкавые". > Нет, что ты, они технически аргументировано упоминают о проблемах GEOM. О проблемах! Ух как! С каких пор математико-инженерные задачи по продумыванию и написанию логики стали проблемами? Ну если только нечем думать, тоды да - проблема :) Какое тусово? BSDCan 2005? Giant lock при SMP? Так уже переписали два раза. Или что-то иное? http://www.bsdcan.org/ PS Постарайтесь указывать на цитату, а то получается, слышали звон а вот где он. Кстати, спасибо - почитал материалы конференции 2011, есть интересные моменты.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 14-Янв-12, 15:04
	> С каких пор математико-инженерные задачи по продумыванию > и написанию логики стали проблемами? Не вмешиваясь в выяснение благородных донов, отмечу, что по-аглицки "задача" (в т.ч. математическая) и есть "problem". :)  Про инженерные зуб не дам, там и "task" проглядывает (ср. IETF).  Насколько понимаю, разница в смысле -- примерно вдоль "озарение" vs "докопать".
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 15-Янв-12, 00:08
	>> С каких пор математико-инженерные задачи по продумыванию >> и написанию логики стали проблемами? > Не вмешиваясь в выяснение благородных донов, отмечу, что по-аглицки "задача" (в т.ч. > математическая) и есть "problem". :) во-первых, мы не англицкие - годы совдепии изменили лингвистичекую картину настолько, что даже изначально эквивалентные понятия имеют теперь разные смыслы, а заимствованые слова также накладываются на чуждую понятийную систему и мутируют в понятии. примеров приводить не буду, их есть навалом, кто двуязычен, тот и так поймет, кто одноязычен - много надо  рассказывать. во-вторых, problem в переводе - это очень тяжело/трудно разрешимая ситуация. проблем процесс, как обычно, в голове.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 15-Янв-12, 00:18
	> во-первых, мы не англицкие Разумеется. > [...] кто двуязычен, тот и так поймет, кто одноязычен - много надо  рассказывать. А кто три+язычен, тем можно заметить, что данный Вами ниже однозначный перевод заведомо многозначного термина после объяснения семантической неэквивалентности понятийных баз смотрится особо оригинально? :) > во-вторых, problem в переводе - это очень тяжело/трудно разрешимая ситуация. Только в учебниках по математике (о которой упомянул) -- это задача и точка. PS: вспомнилось: "водка хороша, но мясо протухло".
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 15-Янв-12, 00:30
	>> во-первых, мы не англицкие > А кто три+язычен, тем можно заметить, что данный Вами ниже однозначный перевод > заведомо многозначного термина после объяснения семантической неэквивалентности понятийных > баз смотрится особо оригинально? :) да нифига оригинального. если в англиском это более трудная ситуация, выкрутиться из которой стоит много средств и усилий, то в русском - все, капец, неразрешимая, будем биться насмерть. будем и дальше умничать?
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 15-Янв-12, 00:57
	> будем и дальше умничать? Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/Problem Вы так трогательно апеллировали к первоисточникам в виде исходников, что я отказываюсь верить своим глазам, когда будучи посланы в словарь -- проявляете чудеса твердолобия.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	173. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 15-Янв-12, 01:29
	>> будем и дальше умничать? > Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/Problem Не буду. У меня стоит dict локально. Report in wake of phone hacking scandal says contact between officers and journalists has 'not been transparent enough' A too-close relationship between senior Metropolitan police officers and sections of the media compromises the ability of both to investigate each other, an independent report in the wake of phone hacking has concluded. ... Это Гардиан, Защитник (перевести попечитель - как-то...), одно из некоторых, которые пробегаю периодически что быть в курсе как и чем дышат в мире. Гардиан, к примеру, желтовата и санта-барбариста, но читать бывает интереснее. И я четко осознаю отличия говорящих "this is problem" и "это проблема", вплоть до придыхания и дальнейшего поведения. В том числе пишущей школо... молодых людей в форумах опеннет. Я их периодически изучаю, пофлеймить немножко, когда есть время. Будем дальше умничать? Или вы хотите оставить за собой последнее слово? Ок, оно за вами. PS https://www.opennet.ru/openforum/vsluhforumID3/82394.html#214 Попытался перевести молодому человеку заметку братьев Jolitz 92 года. Долго мучался как перевести uncumbered - в русскоязычном простанстве легаси-понятия вынесены напрочь, а для америкаца или брита они как дышать. Ответ, как в том анекдоте - "ба, а ше цэ таке було? - цэ море, сынку, море". "Мы гороховые зерна, ... вот мы вырастили смену"
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	174. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 15-Янв-12, 01:44
	>>> будем и дальше умничать? >> Будьте добры, почитайте (хотя бы) http://en.academic.ru/dic.nsf/cide/139309/Problem > Не буду. У меня стоит dict локально. #155
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	20. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 00:53
	в GEOM намеренно отказались от учёта физических параметров > винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный > планировщик I/O, которому в общем-то по барабану Так вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	22. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–3 +/–
	Сообщение от iZEN (ok), 11-Янв-12, 01:25
	> Так вот почему дисковые операции так аццки торбозят на бзде... Я думал это только FFS виновата, а оказывается еще и это. Тормозили в 2005-2007г.г., когда был GIANT_LOCK. Сейчас этого нет — избавились от глобальных блокировок в ряде ключевых мест. (Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно? Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом".) Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков? На Фре это легко и непринуждённо, так сказать, лагов не почувствуешь.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от ананим (?), 11-Янв-12, 02:30
	>Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно? и мне не понятно. ни разу не попадался. >Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, а в Linux десктоп весь "становится колом". врёшь как троцкий. на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся. драйверов нема.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
	Сообщение от Аноним (-), 11-Янв-12, 07:46
	> и мне не понятно. > ни разу не попадался. Мне тоже. Но изену же виднее. Хоть он и видел линуксы только на картинке. > врёшь как троцкий. > на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся. > драйверов нема. Тсс! Не мешай господам теоретикам обогащать лужи метаном!
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от savant (ok), 11-Янв-12, 11:40
	А я вот его частенько ощущаю.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	65. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 11-Янв-12, 16:06
	> А я вот его частенько ощущаю. Притащили недавно восьмигиговую USB-флэшку, попросили занулить.  Оставил, вскоре отошёл.  Прихожу -- даже мышиный курсор не шавелится.  Ну, думаю, ОНО.  Оставил ещё, благо время обеденное, что ли.  Прихожу -- прочухалось. Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает данные.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от savant (ok), 11-Янв-12, 16:23
	>> А я вот его частенько ощущаю. > Притащили недавно восьмигиговую USB-флэшку, попросили занулить.  Оставил, вскоре отошёл. >  Прихожу -- даже мышиный курсор не шавелится.  Ну, думаю, > ОНО.  Оставил ещё, благо время обеденное, что ли.  Прихожу > -- прочухалось. > Флэшка, как коллега и упоминала, навернулась и только делала вид, что принимает > данные. ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться в интернете. из-за iowait система вполне себе прилегает на "подумать" и это может продолжаться очень долго.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 18:08
	> ещё ощутить можно, если систему загнать в своппинг и пытаться например шариться > в интернете. из-за iowait система вполне себе прилегает на "подумать" и > это может продолжаться очень долго. А я думал что она прилегает в основном потому что если процессу понадобились страницы а они вдруг раз и в свопе как назло - процесс трапнется и будет стоять колом, до тех пор пока ядро ему из свопа страниц не выдернет и не пустит его работать дальше, сделав вид что никакого трапа на самом деле не было и вообще вот она, ваша память. Хинт: да, дисковая память на обычном магнитном диске - это очень медленный эмулятор оперативки. Грешно пользоваться оным и ругаться на то что он тормозит. By design.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от netch (ok), 23-Янв-12, 20:17
	> на том железе, где (возможно) есть "Linux BUG#12309" бздя вообще не заведётся. Эта грабля появилась в Linux 2.1, стукнула по нам со всего размаху с перехода на ядра 2.2 (с хостинга пришлось снять всё, что не было жизненно важно на localhost, включая mysql, и всё равно из-за этого в итоге потеряли половину тогдашних юзеров, пока не смогли проапгрейдить железо на значительно более толстое). В 2.4 она сохранялась в полный рост. В 2.6 её чуть-чуть подлечили, но не радикально. Сегодня я её наблюдал на 3.1, когда сделал zypper up в виртуалке - через несколько минут хост-система стала колом. Итого, её не могут вылечить более 10 лет. Ни у одной из опробованных BSD такого нет - у них грамотно расставленные приоритеты и dirty buffer вытесняется вперёд по отношению к working set живых процессов. Переход на Linux 2.0, где этого не было, разумеется, сейчас не пройдёт, да и незачем, если есть фряха. > врёшь как троцкий. ты - да. Трындишь не имея ни малейшего представления о фактах.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	37. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 07:45
	> (Мне вот до сих пор непонятна природа Linux BUG#12309. Чем он вызван, интересно? А это вообще мало кому понятно. Этот баг лезет далеко не везде, иначе его давно бы уже замочили. Более того, вполне вероятно что дуралеи навалили в багтрекер дюжину похожих по симптомам багов под один заголовок. Случается. Кое-какие идеи насчет улучшения латентности операций записи - были поюзаны разработчиками, см. недавние новости. Но совсем не факт что это именно фикс именно того бага и именно в понимании разных его обладателей. > Я, вот, когда копирую большой файл на Фре, не замечаю тормозов и лагов курсора мыши, > а в Linux десктоп весь "становится колом".) А у меня почему-то десктоп не становится колом. Странно. > Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять > компиляцию, допустим, LibreOffice в несколько потоков? На Фре это легко и > непринуждённо, так сказать, лагов не почувствуешь. Кто о чем, а вшивый про баню...
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	60. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от фтыш (?), 11-Янв-12, 14:53
	>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков? Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед. Только LO собирать это безумие, бинарный пакет нормально работает.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	75. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от iZEN (ok), 11-Янв-12, 17:50
	>>Ещё вопрос, можно ли в Gentoo безболезненно для воспроизведения MKV 720p осуществлять компиляцию, допустим, LibreOffice в несколько потоков? > Лехко, постоянно так делаю. Ставишь приоритеты nice/ionice в make.conf и вперед. А если не ставить приоритеты? (Я не ставлю.) > Только > LO собирать это безумие, бинарный пакет нормально работает. У меня на этот счёт нет никаких заморочек, поскольку привык собирать всё ПО из дерева портов. Системный Clang, кстати, компилирует ПО быстрее, чем GCC — так, десктопное окружение на Xfce (firefox, thunderbird, gedit, gnome-mplayer и т.д.) с нуля собирается примерно за 3 часа. С GCC на это тратиться 4-5 часов.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 21:51
	> А если не ставить приоритеты? (Я не ставлю.) "А если рельсу?!" (анекдот про японскую пилу vs суровые сибирские мужики)
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 17-Янв-12, 11:15
	>  Системный Clang, кстати, компилирует ПО быстрее, чем GCC С равным уровнем оптимизации?
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	181. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от netch (ok), 23-Янв-12, 20:22
	> Чем он вызван, интересно? Неумением понимать, что ценность изменённых (dirty) страниц в кэше диска значительно меньше страниц активных процессов. То есть грубый ляп дизайна MM (VM в терминах BSD). Появился в 2.1 (для ширнармасс - в 2.2). До этого или не было, или не проявлялся.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	63. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
	Сообщение от uniman (?), 11-Янв-12, 16:01
	> Так вот почему дисковые операции так аццки торбозят на бзде... Бздя - это новая файловая система в Linux? Попробуйте использовать ее надлежащим способом или обратиться за советом по использованию. >Я думал Интересное наблюдение :) > это только FFS виновата, а оказывается еще и это. С добрым утром! На дворе UFS2+journal & ZFS. Виноваты в глобальном потеплении теперь они.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	30. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 06:04
	> Во FreeBSD например, судя по книжке "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров винчестеров, таких, как время перемещения головки. Проще говоря, нормальный планировщик IO там написать так и не осилили.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	36. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 07:40
	> Проще говоря, нормальный планировщик IO там написать так и не осилили. Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол, это не мы бомжи, это так и задумано. И вообще, это такой дизайнерский изыск! Это сейчас так модно!
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 11-Янв-12, 17:04
	>> Проще говоря, нормальный планировщик IO там написать так и не осилили. > Проще говоря, изен как обычно пытается приподнести голожопость как фичу - мол, > это не мы бомжи, это так и задумано. И вообще, это > такой дизайнерский изыск! Это сейчас так модно! Для тех кто в танке. http://ivoras.net/freebsd/freebsd9.html Generic GEOM IO schedulers Status: Committed to -CURRENT Will appear in 9.0: sure Authors: Luigi Rizzo, Fabio Checconi Web: commit message The new framework, integrated with GEOM, allows for multiple disk IO schedulers to be used, if necessary, on different IO providers (e.g. drives). The usage of some IO schedulers can increase responsiveness in certain kinds of IO workloads, for example a mix of sequential and random IO. ---- You _can_ use multiple IO schedule. Пример со вставкой планировщика geom sched на лету уже приводил. #man gsched NAME      gsched -- control utility for disk scheduler GEOM class                                                                    Available algorithms                 include: rr, which implements anticipatory scheduling with                 round robin service among clients; as, which implements a sim-                 ple form of anticipatory scheduling with no per-client queue.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
	Сообщение от uniman (?), 11-Янв-12, 16:04
	> Проще говоря, нормальный планировщик IO там написать так и не осилили. Да, он не планирует за для походы за продуктами в магазин. Это несомненно недостаток. Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам?
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	125. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 07:01
	> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам? Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их вон на выбор есть, а будет еще больше.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 13-Янв-12, 02:19
	>> Вы не могли бы сформулировать критерии "нормального планировщика" и передать их разработчикам? > Не тот случай когда 1 размера хватает всем. Поэтому у пингвиноидов их > вон на выбор есть, а будет еще больше. То есть критерии стратегирования файловой системы вы сформулировать не компетентны. 1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости применения различных планировщиков дискового ввода-вывода? Ну хотя бы что эти планировщики планируют? Можно с указанием фрагментов исходных текстов. Я пойму. 2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?) что-то не получается в достижении трубуемого отклика и прочих технических параметров от файловых систем?
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 13-Янв-12, 20:43
	> То есть критерии стратегирования файловой системы вы сформулировать не компетентны. Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители. Ну вот например запускают в производство MRAM. Ты знаешь какие у него физические свойства и какие из-за этого будут требования по их учету к планировщику? Я вот пока слабо представляю себе свойства всего этого. > 1 Вам наверное будет нетрудно привести тогда хотя бы орг-технические аргументы необходимости > применения различных планировщиков дискового ввода-вывода? Да пожалуйста. Физические свойства флеша и вращающихся дисков настолько различны что крайне глупо шедулить их одним и тем же алгоритмом без учета их физических особенностей. Алгоритм для дисков - должен учитывать тормозной seek и стараться минимизировать перемещения голов и/или например "наказывать" тех кто много их гоняет, если допустим цель - относительно честно поделить доступ к диску между всеми. Алгоритм для флеша на seek внимание обращать не должен, а вот потенциальную тормознутость записи в некоторых ситуациях - очень даже неплохо бы учесть. Для каких-то еще типов накопителей оптимально учесть что-то еще. > Ну хотя бы что эти планировщики планируют? > Можно с указанием фрагментов исходных текстов. Я пойму. Все исходники есть на kernel.org. Для cfq вроде кто-то даже фрагмент постил - там где проверяется что это rotational media или нет. И алгоритм меняется, соответственно. > 2 Может у упомянутых вами пингвиноидов (кто это? разработчки ядра linux, люди-пингвины?) > что-то не получается в достижении трубуемого отклика и прочих технических параметров > от файловых систем? Да при чем тут файловые системы? Планировщик ввода-выводы делит ресурсы устройства на всех по некоей политике. В лине этому всему уделяют внимание например потому что стоит где-то хост с виртуалками. На нем орда юзеров, допустим. Будет нехорошо, если один юзер из своей виртуалки узурпирует все ресурсы железа, положив остальных на лопатки. Ну понятно что бсдельники далеки от этого (наверное потому что я как-то не видел бсд в роли host в продакшне крутящем кучи юзерских виртуалок за бабки).
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 13-Янв-12, 22:01
	>> То есть критерии стратегирования файловой системы вы сформулировать не компетентны. > Угу. Хотя-бы потому что не знаю какие еще в будущем будут накопители. Те, в разработке интефейсов к которым вы примете горячее участие. Впереди планеты всей. Не теряйте, батенька, времени. http://www.t10.org/intro.htm >> Ну хотя бы что эти планировщики планируют? >> Можно с указанием фрагментов исходных текстов. Я пойму. > Все исходники есть на kernel.org. Для cfq вроде кто-то ... ... где-то. Понятно. PS Универсальный алгоритм: - Ваш код гавно! - Но ты смотрел его? - Не смотрел, патамучно ваш код гавно! - Почему? - Ваш код гавно, а кто так не считает, те казлы! Opensource world. Next generation.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 01-Фев-12, 16:43
	> - Почему? > - Ваш код гaвно, а кто так не считает, те казлы! А в этом что-то есть. Например, осознать что UFS всего лишь древний помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом это не отменяет.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 01-Фев-12, 18:05
	>> - Почему? >> - Ваш код гaвно, а кто так не считает, те казлы! > А в этом что-то есть. Например, осознать что UFS всего лишь древний > помет мамонта с угребищной архитектурой можно просто окинув взглядом общую архитектуру > ФС. Читать целиком код этого ископаемого барахла - лишняя работа. Пусть > он хоть трижды замечательный на вкус, архитектурной угребищности ФС в целом > это не отменяет. Судя по тексту, вы в этом вопросе разобрались. В каком месте код устарел и не отвечает техническим требованиям? $ ls -l /usr/src/sys/ufs/ufs/ total 708 -rw-r--r--  1 root   wheel   3342 21 Jan  2010 README.acls -rw-r--r--  1 root   wheel   4549 21 Jan  2010 README.extattr -rw-r--r--  1 root   wheel   2105 23 Jul  2010 acl.h -rw-r--r--  1 root   wheel   8526  2 Jan 23:41 dinode.h -rw-r--r--  1 root   wheel   5848 21 Jan  2010 dir.h -rw-r--r--  1 root   wheel   5259 17 Oct 18:13 dirhash.h -rw-r--r--  1 root   wheel   6068 21 Jan  2010 extattr.h -rw-r--r--  1 root   wheel   1629 21 Jan  2010 gjournal.h -rw-r--r--  1 root   wheel   7516  2 Jan 23:41 inode.h -rw-r--r--  1 root   wheel   9510  2 Jan 23:41 quota.h -rw-r--r--  1 root   wheel  17313  2 Jan 23:41 ufs_acl.c -rw-r--r--  1 root   wheel  11060 21 Jan  2010 ufs_bmap.c -rw-r--r--  1 root   wheel  36965  2 Jan 23:41 ufs_dirhash.c -rw-r--r--  1 root   wheel  34990 17 Oct 18:13 ufs_extattr.c -rw-r--r--  1 root   wheel   5378  2 Jan 23:41 ufs_extern.h -rw-r--r--  1 root   wheel   3638  2 Jan 23:41 ufs_gjournal.c -rw-r--r--  1 root   wheel   6259  2 Jan 23:41 ufs_inode.c -rw-r--r--  1 root   wheel  41201  2 Jan 23:41 ufs_lookup.c -rw-r--r--  1 root   wheel  44124 15 Jan 19:56 ufs_quota.c -rw-r--r--  1 root   wheel   5194  2 Jan 23:41 ufs_vfsops.c -rw-r--r--  1 root   wheel  70254  2 Jan 23:41 ufs_vnops.c -rw-r--r--  1 root   wheel   6232  2 Jan 23:41 ufsmount.h PS Насколько понимаю, вы эксперт по файловым системам. Поэтому вам не составит труда указать.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 07:18
	> Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций > от аппаратных особенностей усройств хранения? Напротив, сделали планировщик специально для конкретного типа устройств хранения. > планировщик I/O, которому в общем-то по барабану, с каким накопилем он > работает — с HDD или SSD. Ага, только проблема в том что для ssd и hdd удобны довольно разные "стили" обмена данными. Например, у SSD нет особого penalty за seek через полдевайса в отличие от винча. Зато ему очень удобно если данные валятся большими блоками, по размеру erase-block флеша и смещение этих данных - по началу блока накопителя. Еще файловая система может подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего". Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу расчистить, чтобы потом по ней "с ветерком" шпарить.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	67. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+2 +/–
	Сообщение от uniman (?), 11-Янв-12, 16:22
	> Еще файловая система может > подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон > те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего". > Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы > по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу > расчистить, чтобы потом по ней "с ветерком" шпарить. Гм, матчасть... Вообще-то посылать TRIM - не дело слоя FS с бородатого года. В коде FS это вообще командо для контролеро как бы не обязано фигурировать. Дело FS - файло по блокам абстрактного массива распихивать. Вот другой вопрос - как, учитывая пару л-тройке логических слоев до реального физического массива. Насчет реализации TRIM ункутри FBSD. Да есть оно. Насчет как работает - сам не тестировал, все как-то накопители без этого попадаются. К примеру, кусочек кода, где меняется поведение очереди в зависимости от трям/не-трям контролера. http://svnweb.FreeBSD.org/base/release/9.0.0/sys/cam/ata/ata... /* * Actually translate the requested transfer into one the physical driver * can understand.  The transfer is described by a buf and will include * only one physical transfer. */ static void adastrategy(struct bio *bp) { .......             /*          * Place it in the queue of disk activities for this disk          */         if (bp->bio_cmd == BIO_DELETE &&             (softc->flags & ADA_FLAG_CAN_TRIM))                 bioq_disksort(&softc->trim_queue, bp);         else                 bioq_disksort(&softc->bio_queue, bp); ........ }
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 18:27
	>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу >> расчистить, чтобы потом по ней "с ветерком" шпарить. > Гм, матчасть... Что - матчасть? > Вообще-то посылать TRIM - не дело слоя FS с бородатого года. ФС лучше всех остальных знает когда вон те данные на ФС уже никому не нужны. Стало быть, ей и инициировать это дело. > В коде FS это вообще командо для контролеро как бы не обязано фигурировать. Если честно - я не смотрел сорцы как это организовано. Я знаю что как минимум ext4 и btrfs это умеют, как и мое оборудование, и это работает. Если мне попадет шлея под хвост - ну ок, я сунусь и посмотрю как это сделано. > Дело FS - файло по блокам абстрактного массива распихивать. Ну так в этом процессе как раз и обнаружится что блоки по адресу от X до Y нам и не требуются уже. Логично захинтить накопитель о том фактк что их можно почистить. Как именно сделана отсылка trim я честно говоря не смотрел. Я только поигрался с этой механикой и заметил что это работает (есть вполне доступные методы проверки). > Вот другой вопрос - как, учитывая пару л-тройке логических слоев > до реального физического массива. Если через эти слои можно адресно записывать блоки то почему нельзя их же и чистить? > Насчет реализации TRIM ункутри FBSD. Да есть оно. А я то думал что у ней внутри неонка :) > Насчет как работает - сам не тестировал, все как-то накопители без этого > попадаются. Практически любой современный ssd например просто обязан trim уметь - фича уже довольно баянистая. А на механическом диске оно как-то и не надо - нет физического смысла. Это всего лишь хинт контроллеру накопителя что он может если хочет заранее стереть эти блоки. Чтобы не пришлось это делать в те моменты когда приперло по причине отсутствия чистых блоков, внепланово просрав скорость записи (erase блока флеша - довольно медленная операция).
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от uniman (ok), 11-Янв-12, 19:01
	>>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу >>> расчистить, чтобы потом по ней "с ветерком" шпарить. >> Гм, матчасть... > Что - матчасть? >> Вообще-то посылать TRIM - не дело слоя FS с бородатого года. > ФС лучше всех остальных знает когда вон те данные на ФС уже > никому не нужны. Стало быть, ей и инициировать это дело. Иницировать - это да. Может быть. >> В коде FS это вообще командо для контролеро как бы не обязано фигурировать. > Если честно - я не смотрел сорцы как это организовано. > Если через эти слои можно адресно записывать блоки то почему нельзя их > же и чистить? Блин :) Матчасть. Никто не "чистит блоки". В них есть функ запись, из них есть функ чтения. Как бэ все. В метаблоках он может быть помечен как занятый, может как свободный. Прочитал метаблоки в память, пометил как свободные, синхронизировал метаблоки из памяти на диск - все. Командой TRIM дополнительно информируется SSD при обновлении метаблоков, что, мол, воооон в те блоки с фуфлом в них - можно писать, ну и SSD весело в них пишет, если считает необходимым. Говорят, это SSD облегчает его нелегкую кремниевую жизнь. Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала с слоем драйверов. То есть пипл старался так делать. Ну вот теперь традиции меняются :) > Насчет реализации TRIM ункутри FBSD. Да есть оно. > А я то думал что у ней внутри неонка :) Некоторые так и думают, в своем мире. Судя по комментариям. >> Насчет как работает - сам не тестировал, все как-то накопители без этого >> попадаются. > Практически любой современный ssd например просто обязан trim уметь - фича уже > довольно баянистая. Да хрен там. Может я такой невезучий. Или может прогресивное человечество ушло вперед, и унесло триманутое SSD с собой.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 21:42
	> Иницировать - это да. Может быть. Ну я при случае залезу в сорц и посмотрю как они это делают. Все-таки любопытно. Что-то не думаю что они там прямо из драйвера ФС напрямую накопителю команды кидают. Это было бы как-то совсем уж по хакерски. Они конечно любят что-то такое отмочить, но не настолько же? :) >> Если через эти слои можно адресно записывать блоки то почему нельзя их >> же и чистить? > Блин :) Матчасть. Никто не "чистит блоки". В них есть функ запись, > из них есть функ чтения. Неправильно. У флеша есть три различных процедуры. Чтение - ну там все просто и понятно. А вот запись на самом деле является сочетанием 2 взаимодополняющих операций, гоняющих биты ячеек в разные стороны, как то program, когда желаемые данные пишутся в 1 чистую страницу, и erase, когда все страницы erase-блока очищаются одним чихом. CoW логика и уровень трансляции соответственно утрясают такие вот странные свойства своего физического уровня с желанием представить это как якобы диск с какими-то там якобы секторами, которых на самом деле нифига нет. Trim позволяет сборщику мусора контроллера флеша понять что блоки уже не используются и почистить их заранее. В противном случае у сборщика мусора в контроллере есть одна довольно тупая проблема: а он не знает, нужны вам еще вон те данные или уже нет. На них не написано! Как я понимаю, он может сделать выводы лишь на основе логики "если они вот это переписали, оно уже точно было не нужно". Что как-то не слишком оптимально. Trim позволяет реализовывать более удачную упреждащую логику сбора мусора заранее, до того как реально припрет что-то записать и обнаружить что надо оказывается чего-то там перелопатить. > Как бэ все. Как бэ щаззз. > В метаблоках он может быть помечен как занятый, может как свободный. > Прочитал метаблоки в память, пометил как свободные, синхронизировал метаблоки из памяти > на диск - все. Я не знаю кто такие метаблоки, но флеш оперирует двумя понятиями - относительно мелкие страницы на 1..4 кило и относительно большие erase block на 64...512 кило. > Командой TRIM дополнительно информируется SSD при обновлении метаблоков, > что, мол, воооон в те блоки с фуфлом в них - можно писать, Еще один неандерталец, который явно не в курсе что у флеша нет понятия записи как таковой, а есть расщепление этой операции на две взаимодополняющие - erase и program. >  ну и SSD весело в них пишет, если считает необходимым. > Говорят, это SSD облегчает его нелегкую кремниевую жизнь. Говорят, что это позволяет контроллеру на ssd понять что вон те блоки уже никому нафиг не нужны и можно заранее их erase'ануть. Это бы все-равно пришлось сделать потом для их использования, но если это делать когда приперло записать туда что-то - так сперва придется дождаться конца erase а только потом делать program. А это медленее чем немедленно вфигачить желаемое (program) в заранее очищенные страницы. С соответствующим результатом для скорости операции "записи" (которая по факту сочетание erase и program). > Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала > с слоем драйверов. То есть пипл старался так делать. > Ну вот теперь традиции меняются :) SSD вообще на диски не похожи. Какой козел придумал что он должен выглядеть как диск я не знаю но он заслуживает прогулки на эшафот. За создание геморроя остальным в "благих" целях обратной совместимости. >> Насчет реализации TRIM ункутри FBSD. Да есть оно. >> А я то думал что у ней внутри неонка :) > Некоторые так и думают, в своем мире. Судя по комментариям. Ну просто мало меня интересуют кишки этой вашей FBSD, просто потому что я не собираюсь ей пользоваться в обозримом будущем. Кишки флешатины или там пингвина - а почему бы и нет, собственно? Я и тем и другим пользуюсь и буду пользоваться в обозримом будущем. Такой я вот редиска. >> Практически любой современный ssd например просто обязан trim уметь - фича уже >> довольно баянистая. > Да хрен там. Может я такой невезучий. Или может прогресивное человечество ушло > вперед, и унесло триманутое SSD с собой. У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim через смотрение в каком секторе лежит файл, его стирание и смотрение с тем что стало с этим сектором после sync. Правда у них разумеется применительно к линуксу и ext4, насколько их инструкции прокатят для bsd и тамошних ФС я не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от uniman (ok), 11-Янв-12, 21:59
	> Еще один неандерталец, который явно не в курсе что у флеша нет > понятия записи как таковой, а есть расщепление этой операции на две > взаимодополняющие - erase и program. Ну спасибо. Теперь буду жить по другому. Стану бриться и перестану ругаться матом. Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI. Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже стану носить галстук.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 22:25
	> Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI. > Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже > стану носить галстук. Подляна состоит в том что нативную механику флеша вывешивать как некий интерфейс зассали и вместо этого сделали какие-то кривые костыли для представления этого как якобы какой-то там диск, похожий на то с чем привыкли работать ОСы. Осознав что в результате этих потуг получилась очень субоптимальная бнопня, сделали еще костылик в виде trim, позволяющий хоть как-то захинтить то что там на самом деле через тот интерфейс что есть. Теперь гланды через зад автогеном стало удалять в два раза забористее, приколитесь? :))
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 11-Янв-12, 23:06
	>> Ваще то я писал с точки зрения того самого интерфейса ATAPI/SCSI. >> Если вы найдете в спецификации SCSI команду РАСЩЕПИТЬ и ЗАЩИМИТЬ, то даже >> стану носить галстук. > Подляна состоит в том что нативную механику флеша вывешивать как некий интерфейс > зассали и вместо этого сделали какие-то кривые костыли для представления этого > как якобы какой-то там диск, похожий на то с чем привыкли > работать ОСы. Ну так. Мир несовершенен. И я бы так сделал. Или вы хотите лет пяток подождать до внедрения SSD c жутко корректным интерфейсом? Писать системный код и отлаживать - проектные затраты, поэтому внедрение идет по пути наименьших стеднепрогнозных потерь на изменения. Для многих встраиваемых систем смена HDD на SSD - уже благое дело, ибо резко повышает надежность по механике. И значит, благое дело для всех нас, их пользователей.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 07:25
	> Ну так. Мир несовершенен. Ну так. А наша цель - этой механике подыграть. Тому что по факту есть, а не тому маразму через который это вывешено. Ну вот SCSI всего лишь средство, не более. > И я бы так сделал. Или вы хотите лет пяток подождать до > внедрения SSD c жутко корректным интерфейсом? Да на самом деле у MS был бы чудный повод продать новую винду лохам с кульной новой фичой, а остальные могли бы быстро и эффективно работать с дисками, удачно раскладывая файловую систему по флешовым сущностям без большого онанизма. Просто тормозные корпорасты как обычно не понимают своего счастья и изобретают вместо этого костыли и подпорки. > Писать системный код и отлаживать - проектные затраты, поэтому внедрение идет > по пути наименьших стеднепрогнозных потерь на изменения. Это делается так: берется 2 компа, ставится на один старая винда, на второй новая, на супермодный SSD. Показывается разница во времени загрузки в рекламе. Хомяки фигеют и строятся в очередь. Ну а остальные и сами разберутся. И уж наверное всякие линуксы бы без проблем бы подхватили. Ну во всяком случае поддержку флех прицепленных к процам напрямую они что-то делают вполне оперативно. Хотя если уж на то пошло, редизайнить надо и интерфейс передачи данных - для ssd его может быть мало. Вон некоторые делают ssd на pci-e шину. Потому что sata им не хватает. > Для многих встраиваемых систем смена HDD на SSD - уже благое дело, > ибо резко повышает надежность по механике. Зато вносит препротивный лимит на объем записи на носитель. Если на винч можно писать хоть круглосуточно, то вот флехи от этого довольно быстро протираются и вскоре придется заменять флешку, хоть она и угроблена не механически а электрически. А еще они дорогие. Мало того что ssd объема сравнимого с топовыми винчами просто не делают, так еще и что-то хоть издали похожее на таковые стоит как половина самолета. > И значит, благое дело для всех нас, их пользователей. Да просто глупо тут то что сначала создали себе проблем а теперь вот героически их решают всякими неочевидными и кривыми костылями типа TRIM. Хотя могли бы и сделать некий набор команд типа ATAPI, но для флех, например. Ну подумаешь, в хучшем случае потребовался бы еще 1 драйвер под +1 тип накопителей. В лучшем таковой драйвер стал бы стандартной частью систем.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 12-Янв-12, 18:51
	> Да просто глупо тут то что сначала создали себе проблем а теперь > вот героически их решают всякими неочевидными и кривыми костылями типа TRIM. > Хотя могли бы и сделать некий набор команд типа ATAPI, но Тебя ждали.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 20:14
	> Тебя ждали. Круто!
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 11-Янв-12, 22:26
	> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки > уже никому нафиг не нужны и можно заранее их erase'ануть. Это ... Да неужто? А зачем? Наверное, для того что бы в них можно было что-то записать? Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают. Что диск жужжал, и человек мог понять, что он работает. > SSD вообще на диски не похожи. Какой козел придумал что он должен > выглядеть как диск я не знаю но он заслуживает прогулки на > эшафот. За создание геморроя остальным в "благих" целях обратной совместимости. Не, товарищи производители должны были подождать, пока все разработчики напишут новый код под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года. > Ну просто мало меня интересуют кишки этой вашей FBSD Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние. Во вторых, ваше право чем-то не интересоваться. Чего писать об этом так уж? В третьих, какая нахрен разница, код есть код. > У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim "Ну просто мало меня интересуют кишки этоих ваших арчеводов" :) > через смотрение в каком секторе лежит файл, его стирание и смотрение > с тем что стало с этим сектором после sync. Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM. В каком секторе лежит файл. Сильная методика. Жажду ссылки.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	127. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 08:20
	>> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки >> уже никому нафиг не нужны и можно заранее их erase'ануть. Это ... > Да неужто? А зачем? Наверное, для того что бы в них можно было что-то записать? Да. Потому что в отличие от магнитного диска на флеше нельзя просто взять и перезаписать уже занятый данными произвольно выбранный сектор. У хардов все просто. Сказали перезаписать сектор? Ну он пошел, переместил головы в это место, нашел и перезаписал его. Правила игры флеша совсем иные. И если seek time у флеша близко к нулю и его можно вообще почти проигнорировать, то вот время erase обычно лежит в пределах скольких-то там миллисекунд и попасть на эту операцию в процессе записи данных - довольно нехорошо и ведет к сильной просадке скорости записи. Потому что сколько-то там миллисекунд вместо записи курили бамбук, ожидая пока блок сотрется и станет можно в него что-то записать. У арчеводов с их весьма дельной викой кстати на вике есть весьма доходчивые графики как все это выглядит не только в теории но и на практике - сравнение того что получается с trim и без оного ;) > Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают. Некорректная аналогия. В магнитном накопителе сектор можно записывать сразу, без какой-то выделенной процедуры предварительной подготовки оного, выполняемой как некая отдельная сущность в отдельный момент времени. И к тому же винчу не проблема перезаписать только вот эти 512 (или накрайняк 4096) байтов не трогая соседние. А вот ssd в силу своего устройства так не может чисто физически и эмулирует такое поведение крайне извращенскими и неоптимальными действиями. Провокации оного на эти действия следует максимально избегать, если волнует эффективность процесса. А поскольку истинной геометрии нам неизвестно - это избегание превращается в некую черную магию. > Что диск жужжал, и человек мог понять, что он работает. Какая чудная логика неандертальца ффтыкающего на микроволновку :) [...] > Не, товарищи производители должны были подождать, пока все разработчики напишут новый код > под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года. А что, MS как раз с удовольствием бы пошел барыжить новой системой с суперфичой :). Вообще, ATAPI же как-то внедрили, да? Ну потаскали некоторые системы некоторое время с собой кастомные драйвера cd-rom. А потом драйвера внедрили в все основные ОС и нужда в этом отпала. Не вижу никакой трагедии. >> Ну просто мало меня интересуют кишки этой вашей FBSD > Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние. Сами как-нибудь это ваше достояние юзайте. А для меня - поскольку я не собираюсь это использовать, то и детали его внутренней механики волнуют крайне слабо. Разве что как какое-то обобщенное знание, не более. > Во вторых, ваше право чем-то не интересоваться. Чего писать об этом так уж? Скорее, не совсем понятно на кой перец лезть с вашей bsd к линухоидам с их планировщиком. Хотя тут скорее больше в огород изена, этот вообще абстрактный теоретик. Флехи он судя по всему только на картинках в книжках видел :) > В третьих, какая нахрен разница, код есть код. Да просто не понятно какую самоценность он несет и что это по вашему мнению должно проиллюстрировать. >> У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim > "Ну просто мало меня интересуют кишки этоих ваших арчеводов" :) Я это подозреваю, поэтому специально уточняю этот факт, предупреждая о том что эксперимент был опробован под вполне конкретную конфигурацию и работать в других так же не обязан а действия могут отличаться. Вам скорее всего придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу набор действий для FBSD, если вдруг захочется повторить такой эксперимент. >> через смотрение в каком секторе лежит файл, его стирание и смотрение >> с тем что стало с этим сектором после sync. > Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM. Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие от - может писаться хоть отдельными байтами в людском виде. Почему не юзают? Потому что плотность хранения данных никакая. Не надо никому носитель на несколько метров и по цене самолета. Во вторых, набор команд у SSD вроде как ATA, а не ATAPI. В третьих, нет, к сожалению напрямую обратиться в чип нельзя. Поэтому методика довольно хакерская и косвенная, продирающаяся через все эти костыли и слои абстракций к реальной физике. > В каком секторе лежит файл. Сильная методика. Жажду ссылки. Ага, сильная. Я тоже аж удивился. Правда извиняюсь, немного прогнал: ссылка на это у арчеводов, но сам эксперимент все-таки описан на другом сайте. Арчеводовская вика по теме - https://wiki.archlinux.org/index.php/Solid_State_Drives и я бы сказал что это довольно дельный ресурс, независимо от используемой системы. В том плане что из него понятно в какую сторону и что можно крутить, а как это сделать в вашей системе - сами уже как-нибудь допирайте. Статья на проверку поддержки TRIM в пингвине - http://techgage.com/article/enabling_and_testing_ssd_trim_su.../ (самое интересное, а именно проверка - на второй странице) В меру моего понимания, эта проверка довольно сильно закладывается на механику работы файловых систем типа ext4 (как минимум, такой метод проверки имхо не прокатит для CoW файловых систем, а для остальных - в зависимости от того как они стирают файлы и требуют ли почистить при этом область занятую файлом через trim так или иначе) и допускает довольно характерную логику поведения контроллера в ssd, чего разумеется для произвольно взятого ssd никто не гарантирует. Тем не менее, упомянутая там механика и тест вполне работает на конфигурации отдаленно напоминающей авторскую. Ну то-есть, если все отработало как описано у авторов - TRIM определенно есть и работает "по факту", реально расчищая блоки когда об этом попросили.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 12-Янв-12, 18:43
	>> Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают. >> Что диск жужжал, и человек мог понять, что он работает. > Некорректная аналогия. В магнитном накопителе сектор можно записывать сразу, без какой-то ... Батенька, вы еще не поняли что это издевка над вашим поучительством? >> Не, товарищи производители должны были подождать, пока все разработчики напишут новый код >> под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года. > А что, MS как раз с удовольствием бы пошел барыжить новой системой > с суперфичой :). Вообще, ATAPI же как-то внедрили, да? Ну потаскали > некоторые системы некоторое время с собой кастомные драйвера cd-rom. Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 - 1986 года. Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год. 12 лет. А таки потом сделали их интерфейс АТА и SCSI. >А потом драйвера внедрили в все основные ОС и нужда в этом отпала. Гениально! > Не вижу никакой трагедии. Точно. Тебе контакт генерального директора Тошибы али Самсунга подсказать, или сам найдешь? Там такие как ты гении нужны. Не, вдруг на самом все в производстве-индустрии гораздо проще? >>> Ну просто мало меня интересуют кишки этой вашей FBSD >> Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние. > Сами как-нибудь это ваше достояние юзайте. А для меня Меня мало волнуют и твои кишки. :) > придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу > набор действий для FBSD, если вдруг захочется повторить такой эксперимент. Не, теперь очередь этих, как его арчеводов. >> через смотрение в каком секторе лежит файл, его стирание и смотрение >>> с тем что стало с этим сектором после sync. >> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM. > Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. Он знал! Он знал! О великий магистр Йода! :) Парень, тебя так самодовольно прет от твоих открытый после программирования флеш-чипов, что остальному человечесту просто остается грется в лучах твоего сияния.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 13-Янв-12, 20:26
	[...] > Батенька, вы еще не поняли что это издевка над вашим поучительством? Да ладно вам, не стесняйтесь, я тоже покушать люблю и вы оказались вполне пригодны, извините уж за честность :) > Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 - > 1986 года.Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год. Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого. > 12 лет. А таки потом сделали их интерфейс АТА и SCSI. Так флеш тоже появился в 80-х годах, если не в конце 70-х. >>А потом драйвера внедрили в все основные ОС и нужда в этом отпала. > Гениально! Конечно! [...] > Там такие как ты гении нужны. Не, вдруг на самом все в > производстве-индустрии гораздо проще? Разумеется. Хотя честно говоря я не понимаю чего ои упустили возможность слупить бабла на ровном месте. Мелкомякоть могли бы продавать винду с поддержкой нового интрфейса лузерам за суперцену, производители флещатины тоже в минусе бы не остались, ну и так далее :). Видимо влом им что-то разрабатывать уже. Проще купоны стричь на патентной грызне. > Меня мало волнуют и твои кишки. :) Так я и не предлагаю их изучать :P. >> придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу >> набор действий для FBSD, если вдруг захочется повторить такой эксперимент. > Не, теперь очередь этих, как его арчеводов. Угу, арчеводы в отличие от некоторых как ни странно оказались парнями ориентирующимися на фактический результат, а не теоретические бсдения о скази-интерфейсах. Поэтому они будучи дотошными парнями нашли и статейку с описальником как проверить что trim реально работает в некоей конфигурации. > Он знал! Он знал! О великий магистр Йода! :) > Парень, тебя так самодовольно прет от твоих открытый после программирования флеш-чипов, > что остальному человечесту просто остается грется в лучах твоего сияния. Кто ж виноват что такие как вы видели флеш только на картинке, зато потеоретизировать насчет скази и книжек 1999 года - горазды.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 13-Янв-12, 21:32
	>> Стандарт CDROM IEC-19* хрен уже не помню, который потом ISO 9669 - >> 1986 года.Стандарт ATAPI, АTA-4/ATAPI, включающий интерфейc к мультимедия CDROM - 1998 год. > Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых > интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к > счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого. А пока, вы, батенька, предлагагате прицепить флешь-накопители на soundblaster. Ок. Хорошее предложение, у меня для этого и sb16 остался, вполне еще рабочий. Боюсь только, разработчики и покупатели встраиваемого оборудования ваших мысленных флаек не поймут. >> 12 лет. А таки потом сделали их интерфейс АТА и SCSI. > Так флеш тоже появился в 80-х годах, если не в конце 70-х. А спустя 20 лет появился анонимус в форуме на опеннете. Процесс разработки расширений на стандарты интефейсов идет постоянно. Открой для себя комитет T13 http://www.t13.org Фперед, с предложениями туда. Там отпушут, куда тебе идти дальше. >>>А потом драйвера внедрили в все основные ОС и нужда в этом отпала. >> Гениально! > Конечно! Вам осталось убедить всего пару-тройку корпораций в вашей гениальности. Ну хотя бы свою кошку. > Кто ж виноват что такие как вы видели флеш только на картинке, > зато потеоретизировать насчет скази и книжек 1999 года - горазды. Вы сам-то поняли, батенька анонимус, что написали?
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 17-Янв-12, 20:45
	>> Ага. Правда до этого сидиромы цепляли к звуковухам и было несколько несовместимых >> интерфейсов. До такого маразма как эмулировать из сидюка винч тогда к >> счастью не додумались и в результате оно доэволюционировало до чего-то вменяемого. > А пока, вы, батенька, предлагагате прицепить флешь-накопители на soundblaster. Прикольный вывод! Дерзайте! :) > Ок. Хорошее предложение, у меня для этого и sb16 остался, вполне еще рабочий. А, круто. Теперь дизайньте контроллер под этот интерфейс, чтоли :) > не поймут. А их вообще никто не будет спрашивать, независимо ни от чего. > Фперед, с предложениями туда. Там отпушут, куда тебе идти дальше. А что, есть опыт взаимодействия с оными? > Вам осталось убедить всего пару-тройку корпораций в вашей гениальности. > Ну хотя бы свою кошку. Прикольно наверное когда у вас кошка - корпорация :) > Вы сам-то поняли, батенька анонимус, что написали? Что-то написал. Правда среди этого не было книжек.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 17-Янв-12, 20:53
	>Что-то написал. Правда среди этого не было книжек. Так вы обратились к кому-либо со своими перспективными идеями создать новый интерфейс для флеш-накопителей, или только на опеннет анонимусом горазды? Результат когда будет?
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от netch (ok), 23-Янв-12, 21:56
	>>> через смотрение в каком секторе лежит файл, его стирание и смотрение >>> с тем что стало с этим сектором после sync. >> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM. > Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то > на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие > от - может писаться хоть отдельными байтами в людском виде. Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та же википедия пишет. Врут? > Почему > не юзают? Потому что плотность хранения данных никакая. Не надо никому > носитель на несколько метров и по цене самолета. > Во вторых, набор команд у SSD вроде как ATA, а не ATAPI. Ну имелось в виду, как я понял, с кастомным обращением не с блочными операциями, а значит - ATAPI. > (самое интересное, а именно проверка - на второй странице) Проверили, что нули... ничего интересного. Кстати, в случае SCSI спецификации не требуют нули, хотя и рекомендуют.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	188. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 01-Фев-12, 17:07
	> Вообще-то про NOR все пишут, что оно тоже может байтами писаться. Та > же википедия пишет. > Врут? Зависит от чипа. Зачастую - натурально может (под записью я имею в виду PROGRAM). А иногда только страницами, зависит от конкретиики реализации. Исторически, страничные режимы (для ускорения чтения-записи) появились позже побайтовых (а точнее, пословных, поскольку байт на, допустим, 16-битной шине - нечто довольно странное и не существующее физически). Но даже если запись и можно делать индивидуально, это будет с противной оговоркой: в NOR можно индивидуально спустить битики из 1 в 0 но вот обратно в 1 их загнать можно только ERASE'ом всего огромного блока. Кстати этот фокус позволял штукам типа JFFS писать в NOR 1 байт без стирания несколько раз: если нужное значение делается из того что уже записано только спуском битов - стирать не требуется. В современном мире однако ж чипы чаще всего NAND, а обмен чаще всего только страницами (по поводу чего указанный хак в jffs работать перестал и им пришлось немного переделать эту логику). У "настоящего" EEPROM наиболее заметное отличие от флеша - отсутствие блоков. Оно адресуется влоб по ячейкам. Стирание и запись ячеек индивидуальны, в отличие от. Туда всегда можно записать любой байт в любую ячейку и это будет сделано без стирания больших блоков. Так намного удобнее для программ, но за это воздается очень низкой емкостью чипа т.к. на кристалле получается намного больше проводников к ячейкам, etc. Поэтому емкость чипов EEPROM не может конкурировать с NOR и тем более NAND, так что они используются там где не надо большой емкости а индивидуальная запись ячеек - удобна. >> (самое интересное, а именно проверка - на второй странице) > Проверили, что нули... ничего интересного. Контроллер SSD отпедалил даденый ему хинт и потер блок. Вот так вот через такой хакЪ это и проверили :) > Кстати, в случае SCSI спецификации не требуют нули, хотя и рекомендуют. А это вытекает из физики работы флеша, а вовсе не. Это просто стертый блок. Контроллер SSD получив хинт через TRIM, выдал чипу флеша где ранее лежал тот сектор команду на ERASE блока, оттуда и нули (в случае NOR блок стирается наоборот во все единицы, а в NAND вот так вот). На запрос чтения сектора контроллер честно слазил в сектор и доложил что там нули, что и доказывает что упомянутая механика по цепочке отработала :)
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от netch (ok), 23-Янв-12, 21:48
	>>  ну и SSD весело в них пишет, если считает необходимым. >> Говорят, это SSD облегчает его нелегкую кремниевую жизнь. > Говорят, что это позволяет контроллеру на ssd понять что вон те блоки > уже никому нафиг не нужны и можно заранее их erase'ануть. Это > бы все-равно пришлось сделать потом для их использования, но если это > делать когда приперло записать туда что-то - так сперва придется дождаться > конца erase а только потом делать program. Кроме того, это показывает, что если пересобирается новый комплект блоков, то можно указанные блоки не спасать из очищаемого диапазона. >> Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала >> с слоем драйверов. То есть пипл старался так делать. >> Ну вот теперь традиции меняются :) > SSD вообще на диски не похожи. Какой козел придумал что он должен > выглядеть как диск я не знаю но он заслуживает прогулки на > эшафот. За создание геморроя остальным в "благих" целях обратной совместимости. А какая альтернатива? Опишите, пожалуйста, как выглядели бы они при другом подходе.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	69. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (?), 11-Янв-12, 16:52
	>[оверквотинг удален] > Ага, только проблема в том что для ssd и hdd удобны довольно > разные "стили" обмена данными. Например, у SSD нет особого penalty за > seek через полдевайса в отличие от винча. Зато ему очень удобно > если данные валятся большими блоками, по размеру erase-block флеша и смещение > этих данных - по началу блока накопителя. Еще файловая система может > подыгрывать SSD высылая ему команду trim, указывающую что "мы больше вон > те блоки не юзаем, можешь их подгрести GC'ом когда делать нечего". > Сие улучшает скорость записи, т.к. контроллеру ssd приходится не решать проблемы > по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу > расчистить, чтобы потом по ней "с ветерком" шпарить. PS Собственно, поскольку как-то указывать что за ху из ху ниже файловой системы к железяке, приходят к таким решениям. Ну и сотвественно маленько меняется логика FS в отношении нижнего слоя. # man newfs ....      -t      Turn on the TRIM enable flag.  If enabled, and if the underlying              device supports the BIO_DELETE command, the file system will send              a delete request to the underlying device for each freed block.              The trim enable flag is typically set when the underlying device              uses flash-memory as the device can use the delete command to              pre-zero or at least avoid copying blocks that have been deleted. ... # less /usr/src/sys/ufs/ufs/ufsmount.h /* This structure describes the UFS specific mount structure data. */                                           struct ufsmount { ...         int     um_candelete;                   /* devvp supports TRIM */ ... } # less /usr/src/sys/ufs/ffs/ffs_alloc.c         /*          * Nothing to delay if TRIM is disabled, or the operation is          * performed on the snapshot.          */         if (!ump->um_candelete || devvp->v_type == VREG) {                 ffs_blkfree_cg(ump, fs, devvp, bno, size, inum, dephd);                 return;         } И так далее. # svn log /usr/src/sys/ufs/ffs/ffs_alloc.c ------------------------------------------------------------------------ r216796 | kib | 2010-12-29 15:25:28 +0300 (Wed, 29 Dec 2010) | 16 lines Add kernel side support for BIO_DELETE/TRIM on UFS. The FS_TRIM fs flag indicates that administrator requested issuing of TRIM commands for the volume. UFS will only send the command to disk if the disk reports GEOM::candelete attribute. Since disk queue is reordered, data block is marked as free in the bitmap only after TRIM command completed. Due to need to sleep waiting for i/o to finish, TRIM bio_done routine schedules taskqueue to set the bitmap bit. Based on the patch by:  mckusick Reviewed by:    mckusick, pjd Tested by:      pho MFC after:      1 month В данном примере, если правильно понял, если стоит флаг трим и трям, то битовые операции проводить в снимке системы. Там еще всякое.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	182. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от netch (ok), 23-Янв-12, 21:42
	> Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций > от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке > "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров > винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный > планировщик I/O, которому в общем-то по барабану, с каким накопилем он > работает — с HDD или SSD. Ему вообще-то не совсем по барабану. Потому что если, например, для диска лифтовый шедулер знает, что сейчас мы пишем блок 1000, в очереди стоит блок 990 от низкоприоритетного процесса, текущее направление лифта - вниз, а поступил заказ на блок 2000 от высокоприоритетного процесса - то шедулер должен решить, достаточно ли новый заказ важен, чтобы сбить логику лифта и погнать его срочно вверх (на 2000), или можно продолжить проход вниз (где ждёт 990) и заставить высокоприоритетный процесс таки подождать. В целом мы будем иметь суммарный вес заказов на текущее направление движения и суммарный вес заказов на перебой направления. TQ и NCQ слегка устраняют эти проблемы, при условии, что текущая очередь не превышает их предельной глубины очереди (до 255 у SCSI TQ и до 31 у NCQ), но если заявок больше, то всё равно приходится начинать думать. А для SSD это всё не имеет никакого значения, всё равно не угадаешь, что там внутри в текущую минуту как разложено. Особый цимес конструированию шедулеров придают задачи обеспечения одновременно скорости важного потока и периодических мотаний туда-обратно головками для других важных операций... в общем тут можно полировать и вылизывать годами. Когда Вы говорили про время перемещения головки, вспоминали особенности старых дисков (грубо говоря, до времён PC, а вместо этого на PDP-11 или аналогах), которые были особо медленными, зато можно было угадать, что вот прямо сейчас мееедленно подползает блок 2 на дорожке. Да, с введением внутренних трансляций геометрии, мультизонных дисков с разной плотностью (это где-то от рубежа 400MB) это всё потеряло смысл окончательно, сейчас по LBA невозможно установить, в какой момент надо подавать какой блок на запись. Можно только предсказать положение головок, и это работает надёжно, по крайней мере пока нет ремапов. А при TQ и NCQ - весь текущий пул запросов будет отработан диском. Но, как я описал выше, это далеко не все проблемы. Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика. Если их введут, то придётся снова серьёзно думать о выборе шедулера.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	186. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 25-Янв-12, 01:00
	> Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O > нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика. BTW http://lkml.org/lkml/2011/3/25/44
	Ответить | Правка | Наверх | Cообщить модератору

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

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