forum.opennet.ru

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

Оглавление

Для ядра 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)

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

34. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +1 +/–

Сообщение от Аноним (-), 11-Янв-12, 07:28

> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов. Плюс буфера и у ос и у накопителя, скорость трансфера в которые порядка скорости sata линка.
> и привет 20MB/s ;)
Теоретик хренов. А с фрагментами все не так просто. Чтобы было оптимально, блоки должны попадать точно в erase-блоки и размер фрагмента должен быть кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного. И дольше, и wearing в 2 раза увеличивается - ssd подохнет быстрее.
В каком-нить ext4 есть даже средства позволяющие захинтить файловой системе желаемый размер одного обмена с накопителем в не менее чем вон столько. Хоть это формально и для рэйдов, для которых удобнее чтобы блоки по очереди валили на разные диски, никто ж не запрещает и для ssd фичу юзать, избавив ssd от кучи мелких записей, неоптимальных для оного.
А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый на педалинг огромных битовых карт и прочих бестолковостей на ssd будет роялить еще больше. Поэтому древность и костыльность структур ФС и тут вам будет икаться от души.

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

44. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 09:14

> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов.
Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?

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

57. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Ваня (??), 11-Янв-12, 14:31

Они оптимизируют разные вещи. Напр. блок управления карбюратором машины управляет впрыском топлива, и ему безразлично куда едет машина. Можно ли сказать что т.к. карбюратор оптимизирует работу двигателя, то не требуется оптимизировать маршрут поездки? Нет.

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

84. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 18:34

> Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда
> контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?
В идеале можно попробовать подогнать смещение файловой системы под erase block и стараться оперировать блоками размером с оный. На практике сие больше смахивает на черную магию, поскольку внешне все карточки, флешки и ssd пытаются выглядеть как якобы простые диски с якобы 512 байтными секторами, а свою истинную геометрию не сообщают. А на самом деле 512 байтных секторов вообще там ни разу нет и запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кб, что явно более 512 байтов и вообще целая свистопляска для контроллера вместо атомарной операции. А в хучшем случае будет вообще стирание большого erase block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)

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

85. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Aleksey Salow (ok), 11-Янв-12, 18:52

> запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кб
страница 2kb. Запись идёт блоком из 64 страниц, а чтение действительно постранично.
> А в хучшем случае будет вообще стирание большого erase
> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно
> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
Выкиньте свой jmicron в помойку. В современных накопителях давным давно cow с gc и что там творится в реальности знает только контроллер. Любая запись там выглядит как read-modify-write, если пользовать trim есно. Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи будет все лишь один read с пачкой modify и одним write в заранее чистый блок. А чтобы чистых блоков вообще не было - так это имхо нужно забить весь накопитель к чертям и банально писать поверху. А так, любая передышка, и gc собирает мусор очищая блоки.

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

103. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 20:26

> страница 2kb.
Разная у разных флех. У мелких бывает и 1 кб. У очень больших бывает 4. Или ты посмотрел даташт на конкретную флеху и возомнил что только так - вообще везде? Прут меня виндузятники своей непосредственностью. Дикарь с копьем который увидел микроволновку и судорожно пытается втиснуть в свою примитивную модель мира такую неведомую фигню как магнетрон.
> Запись идёт блоком из 64 страниц, а чтение действительно постранично.
У разных чипов флешек число страниц на erase block бывает разным. В мире нет какой-то универсальной константы, описывающей размер страницы или erase block как единственно верные константы мирового масштаба. В лучшем случае у флешек одного поколения они примерно одинаковы. Но это не гарантированно. Лично я в курсе и иных сочетаний. Вон у упомянутых арчеводов например где-то в вике упоминается страница в 4К, 128 страниц на блок. Т.е. 512 К на блок. Подумаешь, в 4 раза присвистнул и указал неоптимальный размер блока. Кстати запись постранично тоже возможна, но с одной большой оговоркой: записываемая страница должна быть чистой. А вот с этим засада. Из-за физических особенностей флеша, стирать его можно только большими блоками. Если в страницу уже что-то записано, ее нельзя стереть отдельно от остальных в этом erase block. Можно закатить erase для всего erase block целиком, тогда все страницы блока очистятся. Отсюда следует что erase для записи страницы требуется не всегда, но в хучшем случае действительно нужен.
Кстати да, питекантроп пытающийся осознать как работают наши магнетроны соверщенно забыл про то что у флеша erase - это отдельная логически осмысленная процедура, являющаяся отдельной сущностью. Trim имеет непосредственное отношение к оной процедуре. Erase это не чтение и не запись в их привычном понимании. Это приведение всех страниц erase-block'а в чистое состояние.
>> А в хучшем случае будет вообще стирание большого erase
>> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно
>> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
> Выкиньте свой jmicron в помойку.
Какой еще jmicron? Упомянутый спич является обобщением логики работы всей этой механики вообще. В том плане что по другому это как-то не особо то и сделаешь, даже самый хитрый контроллер будет реализовывать похожую логику и ничего не сможет поделать с тем фактом что флешу удобно работать целыми erase-block'ами или хотя-бы страницами. Выравнивание на erase-block лучше тем что ведет к избеганию ситуации когда контроллеру для всего блока надо будет сделать read-erase-modify-write, чтобы оформить частичную модификацию erase блока во что-то физически существующее.
> В современных накопителях давным давно cow с gc и что там творится в реальности
> знает только контроллер.
Это не отменяет того факта что ему тоже удобнее всего фигачить блоками размером с erase block с правильным выравниванием. Просто потому что даже самый умный контроллер ничего такого сделать с физической природой флеша не может. Он может заныкать от вас служебное действо когда запись менее чем удобная величина ведет к read-modify-(иногда erase)-write, но отменить его и сделать чудо он не может. Trim позволяет реже нарываться на нужду erase при записи, давая контроллеру хинт что если он хочет то может в фоне вон те блоки и почистить, т.к. они не нужны. А erase довольно тормозная операция.
> Любая запись там выглядит как read-modify-write, если пользовать trim есно.
Wrong. Самый удачный вариант ака достаточно большая запись и только в чистые страницы будет просто программированием этих страниц. Быстро и без проблем. Trim нужен как раз для того чтобы дать шанс контроллеру заранее подчистить неиспользуемые блоки и по возможности создать именно эту, самую удачную для записи ситуацию.
> Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи
> будет все лишь один read с пачкой modify и одним write
Уважаемый дикарь в попытках осознания процесса работы магнетрона напрочь забывает о том что у флеша есть read, program и отдельная операция известная как erase. Program и erase - две логически дополняющие друг друга сущности, грубо говоря, тягающие биты ячеек в разные стороны (одна в одно состояние, вторая в другое). По разным правилам игры, вытекающим из физического устройства флеша. Program вгоняет биты страницы в те значения которые хочется получить. А вот обратно их вернуть можно только erase'ом всего здорового блока. Если интересно - см. в английской вике, тем вполне дельно разжевано откуда такая странная брейнфакерская логика берется - она вытекает из того как биты хранятся в ячейках флеша.
> в заранее чистый блок. А чтобы чистых блоков вообще не было
> - так это имхо нужно забить весь накопитель к чертям и
> банально писать поверху.
Достаточно чтобы gc вовремя не подсуетился. Тогда ему придется делать erase прямо на ходу и скорость записи просядет, что логично. Trim нужен чтобы этого максимально избегать, выдавая хинты контроллеру что он может уже стирать вон те блоки. Не дожидаясь того момента когда припрет, так что надо бы записать, а чистых страниц что-то нету, так что давайте судорожно расчищать прямо сейчас (а запись соответственно подождет до лучших времен).
> А так, любая передышка, и gc собирает мусор очищая блоки.
Вот только проблема в том что сам по себе gc как-то не очень то и знает - нужен вон тот кусок данных файловой системе, или уже можно его в расход. Вот trim как раз и позволяет gc приобрести это знание и действовать именно так, заранее расчищая блоки. Упреждая ситуацию когда приперло и надо чистить блоки прямо в процессе записи, тормознув запись.

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

105. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Michael Shigorin (ok), 11-Янв-12, 20:39

> В идеале можно попробовать подогнать смещение файловой системы под erase block
Не "в идеале", а "для начала".  Иначе и SSD, и 4k-HDD, и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели.

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

107. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 21:06

> Не "в идеале", а "для начала".  Иначе и SSD, и 4k-HDD,
> и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели.
Грабль состоит в том что для флеша это довольно сложно, поскольку истинную геометрию нам не показывают и есть минимум 2 сущности разного размера да еще CoW логика. Поэтому достоверно определить как наши действия состыкуются с внутренней механикой можно только серией хитровыгнутых экспериментов, которые к тому же в зависимости от логики контроллера совершенно не обязаны давать одинаковые или даже просто осмысленные или воспроизводимые результаты.
Кстати если какое-нибудь там начало раздела и партишн тейбл еще можно осмыленно разложить, выбрав выравнивание так чтобы сие было явно кратно erase block (просто считая его кратным достаточно большому 2^N, например 512Кб выравнивание устроит как тех у кого он 512Кб, так и тех у кого блок в 256 или 128Кб) то вот например осознать как там будут блоки с данными ФС расположены - уже не так легко. А вы это в состоянии для ну хотя-бы ext4? В том плане что граница 4k блока EXTа должна бы совпасть с границей страниц флеша. Но вот проверять это... хм... а существует какой-то удобный и автоматизированный метод? И кроме того - а известен ли метод смещать блоки с данными относительно начала раздела?

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

58. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." –2 +/–

Сообщение от Aleksey Salow (ok), 11-Янв-12, 14:32

>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок
> в группу чипов, размазав записи и чтения на кучу чипов.
Минимальный блок для записи - 128K вроде как. Сколько там размер сектора? 512b. Вот и получаем что для изменения одного битика нужно переписать целый блок. В современных ssd конечно cow, но писать всё-равно будет одним блоком, правда на другой чип.
>> и привет 20MB/s ;)
> Теоретик хренов.
Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png
> А с фрагментами все не так просто. Чтобы было оптимально,
> блоки должны попадать точно в erase-блоки и размер фрагмента должен быть
> кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного.
> И дольше, и wearing в 2 раза увеличивается - ssd подохнет
> быстрее.
Это пусть у контроллера голова болит, они шибко умные нынче пошли.
> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
> вам будет икаться от души.
Только почему-то на этой самой ntfs всё работает хер знает когда, показывает пиковую производительность, а в линупсе только сейчас осознали что что-то не так в консерватории. Неужели так долго копили на ssd для тестов? :)

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

73. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." –1 +/–

Сообщение от iZEN (ok), 11-Янв-12, 17:45

>>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые
>>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля
>> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок
>> в группу чипов, размазав записи и чтения на кучу чипов.
> Минимальный блок для записи - 128K вроде как. Сколько там размер сектора?
> 512b. Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.
В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).

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

74. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Aleksey Salow (ok), 11-Янв-12, 17:48

> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
В zfs под рейды точили походу, а на ufs2 + gstripe я тоже делал 64k, страйп быстрее работал.

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

77. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от iZEN (ok), 11-Янв-12, 18:00

>> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
> В zfs под рейды точили походу,
Не только. ZFS разрабатывали в том числе для использования с SSD. ;) Все эти кширующие техники для ZIL и L2ARC описаны в применении к SSD (с быстрыми SLC и медленными MLC, соответственно).
Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD хорошо и эффективно.

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

80. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Aleksey Salow (ok), 11-Янв-12, 18:04

> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
> хорошо и эффективно.
А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но мало ли что случится в ближайшем будущем ;)

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

82. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." –1 +/–

Сообщение от iZEN (ok), 11-Янв-12, 18:21

>> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
>> хорошо и эффективно.
> А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но
> мало ли что случится в ближайшем будущем ;)
О перспективах ZFS и флэш-памяти: http://blogs.oracle.com/jonathan_ru/entry/о_перспективах_zfs_и_флэш
Ещё может пригодиться:
A look at MySQL on ZFS: http://habrahabr.ru/blogs/mysql/78473/
Объяснение ARC и L2ARC: http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/

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

95. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 19:34

> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)
Ага, правда SSD в природе не было в момент дизайна ZFS, но изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый булшит от санок повторять как мантру, ведь верить в это намного приятнее, правда? :)

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

111. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от uniman (ok), 11-Янв-12, 21:43

>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)
> Ага, правда SSD в природе не было в момент дизайна ZFS, но
> изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый
> булшит от санок повторять как мантру, ведь верить в это намного
> приятнее, правда? :)
Там другое. Например, группировка сбросов на диск по их рейтингк.
ttp://constantin.glez.de/blog/2011/02/frequently-asked-questions-about-flash-memory-ssds-and-zfs
ZFS also has a sophisticated cache called the "Adaptive Replacement Cache" (ARC) where it stores both most frequently used blocks of data and most recently used ones. The ARC is stored in RAM, so each block of data that is found in the RAM can be delivered quickly to the application, instead of having to fetch it again from disk. When RAM is full, data needs to be thrown out of the cache and is not available any more to accelerate reads.
SSDs can be used as a second level cache: Blocks that can't be stored in the RAM-based ARC can then be stored on SSDs and in case they're needed, they can still be delivered quicker to the application than by fetching them again from disk. An SSD that is used as a second level ARC is therefore called an L2ARC, or a "cache device".
Поэтому жретъ памяти, зараза :)

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

133. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 12-Янв-12, 09:50

> therefore called an L2ARC, or a "cache device".
> Поэтому жретъ памяти, зараза :)
Если честно, я в этом спиче не вижу ни 1 звука про собственно саму оптимизацию записи на SSD. То-есть рассказали про то что они умеют юзать как кеш. Ну круто. Но ни звука про то как запросы к ФС оптимизируются на предмет минимального протирания SSD и максимальной скорости работы оного. И ниоткуда не следует что кеш обязан по дефолту сливаться на диск в виде оптимальном для SSD.

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

140. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от uniman (ok), 12-Янв-12, 18:04

>> therefore called an L2ARC, or a "cache device".
>> Поэтому жретъ памяти, зараза :)
> Если честно, я в этом спиче не вижу ни 1 звука про
Не видите звуков? Оригинально. Попробуйте пощупать код на слух.

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

147. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 12-Янв-12, 20:36

> Не видите звуков? Оригинально. Попробуйте пощупать код на слух.
Тоже не слышно ничего. Поэтому процитируйте плиз где там про оптимизацию процесса записи на SSD хоть слово вообще. То что ssd в роли кеша работает лучше механики - так это не только парни из сана заметили, прикиньте? Кстати мне вот интересно - а быстро ssd там до дыр затирается?

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

185. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +1 +/–

Сообщение от netch (ok), 23-Янв-12, 22:04

>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;)
> Ага, правда SSD в природе не было в момент дизайна ZFS, но
> изена такие мелочи не волнуют, как обычно.
Вообще-то у ZFS сейчас идёт уже где-то 15-я минимум версия пула - это раз.
Флэшовые накопители были уже много лет - это два. Да, у них не было умного контроллера, ремапа по обстоятельствам и так далее, но часть проблем была уже известна.
> Он лучше будет маркетинговый
> булшит от санок повторять как мантру, ведь верить в это намного
> приятнее, правда? :)
Урежьте осетра.

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

99. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 19:38

> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD
> хорошо и эффективно.
А майкрософт на своем сайте так и вообще рассказывал что виндус сервер обгоняет линукс. Верить бложику чувака из коммерческой компании? Спасибочки, а ничего что у пиарщиков всегда их продукт самый лучший? Что ж ты будешь делать если услышишь пиар конкурирующих компаний? Неужели разорвешься на 2 части? :)

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

87. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 19:02

> Минимальный блок для записи - 128K вроде как.
Минимальный блок для записи у флеша - страница. Обычно 1...4Кб у nand-флешек из которых делается все и вся, от карт памяти до могучих ssd.
> Сколько там размер сектора? 512b.
Да хрен тебе, теоретик. У флеша нет 512-байтовых секторов. Совсем. Они эмулируются совершенно адскими высерами контроллера с read-modify-write. Кстати это же объясняет почему у некоторых господ иногда странно теряются данные. Вплоть до того что на картах памяти и юсб флехах с FATом изредка у некоторых господ очень неудачно слетает все что угодно, вплоть до таблицы разделов. Если таблица разделов попала в тот же erase-block что и например кусок FAT и питальник неудачно слетел, так что read-modify-write срубился в самом начале, кусок с MBR и таблицей разделов может и не успеть записаться. И если то что FAT должен был пострадать за то что перезаписывался в этотм момент - логично, то вот то что MBR пострадает лишь за то что его угораздило жить в том же erase block - куда менее очевидный и намного менее приятный факт :). По этой причине кстати фабричный формат на флешках и картах довольно характерно выравнивает ФС на характернуые величины, кратные 2^N, по размеру erase-block разумеется.
> Вот и получаем что для изменения одного битика нужно переписать
> целый блок. В современных ssd конечно cow, но писать всё-равно будет
> одним блоком, правда на другой чип.
А тут ты как ни странно не прогнал. Проблема только в том что один хрен загаженный блок стирать придется. Не сейчас, так потом. Единственное чего можно выиграть в стирании его не сей момент а в фоне - скорость записи. Это как езда по дороге со снегом. Если перед тобой медленно тащится снегоуборщик - понятно какая скорость езды получится. А если он заранее проехал, скорость будет другой :)
> Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте
> даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png
Гражданин, не наглей, да? Я не только читал гору даташитов на всевозможный флеш, я еще и программировать эти самые чипы флеша умею. Вплоть до того что я лично реализовал процедуру зашивки нескольких чипов, покурив даташиты, когда приспичило. Приколись, а? Если ты такой умный и даже даташитами козыряешь - ну покажи, в каком месте ты 512 байтные сектора у флеша углядел, для начала.
[...]
>> И дольше, и wearing в 2 раза увеличивается - ssd подохнет
>> быстрее.
> Это пусть у контроллера голова болит, они шибко умные нынче пошли.
Умнота контроллера не отменяет вполне характерного устройства чипов флеша на уровне весьма базовой физики лежащей в процессе их работы. Этой физике можно подыграть даже через призму контроллера флеша.
>> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
>> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
>> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
>> вам будет икаться от души.
> Только почему-то на этой самой ntfs всё работает хер знает когда, показывает
> пиковую производительность,
Меня интересует в основном средняя производительность и worst case, а не пиковая. Пиковая скорость записи в моей системе - несколько Гб в секунду (ram cache hit). Да, кстати линь намного умнее делает. В лине буфером ФС является почти вся свободная память прямо сразу (линь при необходимости просто урезает этот буфер на ходу), тогда как винда отращивает дисковый буфер крайне неохотно. Поэтому в лине dvd-iso sized чушка у меня просто улетает в буфер. Мгновенно. В винде ... хаха, ну ты понял. Половина в буфер влазит а дальше все, жопа. Полфайла быстро пишется, а потом... потом там уже половина исохи ждет своей записи на винч, а буфер уже кончился. И хотя оперативы еще свободно как грязи, винда не спешит отращивать буфера. Пусть лучше юзер 30 секунд ффтыкает на то как это сливается на диск, а прога будет заблочена пока в буфере еще места под данные не появится ;)
> а в лину псе только сейчас осознали что что-то не так в консерватории.
> Неужели так долго копили на ssd для тестов? :)
Линукс мало того что умнее с дисковыми буферами работает, так еще и можно например своп на ссдшник засунуть, без риска в момент его протереть. Поставить минимальную агрессию свопинга, чтобы своп юзался как нечто на крайний случай, когда совсем прижало. И большую часть времени такой своп не будет протирать флеху с ее лимитами на число перезаписей. А вот виндовозный своп флешатину до дыр протрет довольно быстро и я как-то не в курсе - а в винде можно рулить агрессивностью свопа как в лине? А то дефолтная логика там вообще как во времена вин95, видимо с тех пор не менялось. Хотя для машин с 4гб памяти логичны совсем иные настройки чем для машин с 16Мб. В итоге винды позорно тормозят при переключении между увесистыми задачами на машине с совершенно любым количеством оперативки. Хоть 16 гиг воткни, а все-равно несколько гб фуфла в своп сольется при активном использовании. Даже если еще с десяток гигов памяти свободно и вообще нет повода гадить в своп.

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

72. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от iZEN (ok), 11-Янв-12, 17:16

> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый
> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет
> роялить еще больше. Поэтому древность и костыльность структур ФС и тут
> вам будет икаться от души.
User294, почему ты не логинишься под своим ником? Тебе же сто раз объясняли, что битовые карты никакой существенной роли в производительности записи на ФС не несут. Чтобы они что-то значали в скорости поиска свободных блоков, нужно иметь ФС размером порядка 16 ТБ и больше.

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

89. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 19:11

> User294, почему ты не логинишься под своим ником? Тебе же сто раз
> объясняли, что битовые карты никакой существенной роли в производительности записи на
> ФС не несут.
Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень характерный эффект на большинстве бенчмарков ;)
> Чтобы они что-то значали в скорости поиска свободных
> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто пи...т как дышит. А тебе не приходило в бошку что компактную стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши засираются и прочее, а? Или ты думаешь что все новые дизайнф ФС экстенты стали чисто для красоты использовать? ;)

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

101. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от iZEN (ok), 11-Янв-12, 20:18

>> User294, почему ты не логинишься под своим ником? Тебе же сто раз
>> объясняли, что битовые карты никакой существенной роли в производительности записи на
>> ФС не несут.
> Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень
> характерный эффект на большинстве бенчмарков ;)
Карта свободных блоков — битмапы — кэшируются в ОЗУ. Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см. "FreeBSD. Архитектура и реализация").
>> Чтобы они что-то значали в скорости поиска свободных
>> блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
> А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто
> пи...т как дышит. А тебе не приходило в бошку что компактную
> стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши
> засираются и прочее, а? Или ты думаешь что все новые дизайнф
> ФС экстенты стали чисто для красоты использовать? ;)
Экстенты из другой оперы.

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

106. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 11-Янв-12, 20:46

> Карта свободных блоков — битмапы — кэшируются в ОЗУ.
И что? Это не отменяет нужды читать/писать их на диск (озу знаешь ли не энергонезависимое) и модифиицровать довольно крупные битмапы.
> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см.
> "FreeBSD. Архитектура и реализация").
Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий бсдун. Остальные это называют окаменелым пометом мамонта.
>> засираются и прочее, а? Или ты думаешь что все новые дизайнф
>> ФС экстенты стали чисто для красоты использовать? ;)
> Экстенты из другой оперы.
Обычно из той же самой. Или уж занятость блоков описывается битмапой, или уж какой-то компактной структурой, например упакованой в дерево.

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

119. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от uniman (ok), 11-Янв-12, 22:49

>> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см.
>> "FreeBSD. Архитектура и реализация").
> Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий
> бсдун. Остальные это называют окаменелым пометом мамонта.
Ваш генный код старее окаменелого говна мамонта. И судя по вашему тексту, назвать это удачной реализацией архитектуры можно только с натягом.
Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не вставать.
http://www.usenix.org/publications/library/proceedings/useni...

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

159. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 13-Янв-12, 20:15

> Ваш генный код старее окаменелого го вна мамонта. И судя по вашему тексту,
> назвать это удачной реализацией архитектуры можно только с натягом.
Мы существа одного вида, поэтому вам наверное недостатки видны не хуже меня, на своем примере :)
> Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не
> вставать.
Ага, только к SSD это все не относится практически никак.

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

163. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от uniman (ok), 13-Янв-12, 20:46

>> Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не
>> вставать.
> Ага, только к SSD это все не относится практически никак.
Точно, реализация FS не относиться к SSD никак. Кстати, о чем новость?
Перечитайте предложение выше, для начала, и постарарайтесь поразмыслить на предмет реализации стратегии записи через интерфейс, и как реализация стратегии записи вообще относится к записи байтиками и вышивке крестиками.

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

189. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..." +/–

Сообщение от Аноним (-), 01-Фев-12, 17:17

> Точно, реализация FS не относиться к SSD никак.
Не согласен. Есть более удобные и менее удобные для ssd файловые системы, более того - с учетом иных физических свойств накопителя оверхед от операций ФС вылезет совсем в ином виде. И кому как не файловой системе видно что и где (не)используется?
> Кстати, о чем новость?
О планиовщике I/O.
> стратегии записи через интерфейс, и как реализация стратегии записи вообще относится
> к записи байтиками и вышивке крестиками.
Например, самое очевидное: логично подгонять стратегию таким образом чтобы накопителю было удобно записывать то что ему в результате этой стратегии свалилось. Дебильно выбрав стратегию можно основательно просадить скорость записи у SSD.

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

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

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

Партнёры:

Хостинг:

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

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


	34. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от Аноним (-), 11-Янв-12, 07:28
	> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые > максимально фрагментируют данные, в противном случае будет чтение из одного модуля Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов. Плюс буфера и у ос и у накопителя, скорость трансфера в которые порядка скорости sata линка. > и привет 20MB/s ;) Теоретик хренов. А с фрагментами все не так просто. Чтобы было оптимально, блоки должны попадать точно в erase-блоки и размер фрагмента должен быть кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного. И дольше, и wearing в 2 раза увеличивается - ssd подохнет быстрее. В каком-нить ext4 есть даже средства позволяющие захинтить файловой системе желаемый размер одного обмена с накопителем в не менее чем вон столько. Хоть это формально и для рэйдов, для которых удобнее чтобы блоки по очереди валили на разные диски, никто ж не запрещает и для ssd фичу юзать, избавив ssd от кучи мелких записей, неоптимальных для оного. А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый на педалинг огромных битовых карт и прочих бестолковостей на ssd будет роялить еще больше. Поэтому древность и костыльность структур ФС и тут вам будет икаться от души.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 09:14
	> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок в группу чипов, размазав записи и чтения на кучу чипов. Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Ваня (??), 11-Янв-12, 14:31
	Они оптимизируют разные вещи. Напр. блок управления карбюратором машины управляет впрыском топлива, и ему безразлично куда едет машина. Можно ли сказать что т.к. карбюратор оптимизирует работу двигателя, то не требуется оптимизировать маршрут поездки? Нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 18:34
	> Ну и жесть. Как вообще можно что-то оптимизировать в такой ситуации, когда > контроллер у разных дисков по разному работает и сам что-то пытается оптимизировать? В идеале можно попробовать подогнать смещение файловой системы под erase block и стараться оперировать блоками размером с оный. На практике сие больше смахивает на черную магию, поскольку внешне все карточки, флешки и ssd пытаются выглядеть как якобы простые диски с якобы 512 байтными секторами, а свою истинную геометрию не сообщают. А на самом деле 512 байтных секторов вообще там ни разу нет и запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кб, что явно более 512 байтов и вообще целая свистопляска для контроллера вместо атомарной операции. А в хучшем случае будет вообще стирание большого erase block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	85. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Aleksey Salow (ok), 11-Янв-12, 18:52
	> запись 512 байтов выльется в как минимум read-modify-write какой-то страницы, а это обычно 1...4Кб страница 2kb. Запись идёт блоком из 64 страниц, а чтение действительно постранично. > А в хучшем случае будет вообще стирание большого erase > block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно > масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :) Выкиньте свой jmicron в помойку. В современных накопителях давным давно cow с gc и что там творится в реальности знает только контроллер. Любая запись там выглядит как read-modify-write, если пользовать trim есно. Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи будет все лишь один read с пачкой modify и одним write в заранее чистый блок. А чтобы чистых блоков вообще не было - так это имхо нужно забить весь накопитель к чертям и банально писать поверху. А так, любая передышка, и gc собирает мусор очищая блоки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 20:26
	> страница 2kb. Разная у разных флех. У мелких бывает и 1 кб. У очень больших бывает 4. Или ты посмотрел даташт на конкретную флеху и возомнил что только так - вообще везде? Прут меня виндузятники своей непосредственностью. Дикарь с копьем который увидел микроволновку и судорожно пытается втиснуть в свою примитивную модель мира такую неведомую фигню как магнетрон. > Запись идёт блоком из 64 страниц, а чтение действительно постранично. У разных чипов флешек число страниц на erase block бывает разным. В мире нет какой-то универсальной константы, описывающей размер страницы или erase block как единственно верные константы мирового масштаба. В лучшем случае у флешек одного поколения они примерно одинаковы. Но это не гарантированно. Лично я в курсе и иных сочетаний. Вон у упомянутых арчеводов например где-то в вике упоминается страница в 4К, 128 страниц на блок. Т.е. 512 К на блок. Подумаешь, в 4 раза присвистнул и указал неоптимальный размер блока. Кстати запись постранично тоже возможна, но с одной большой оговоркой: записываемая страница должна быть чистой. А вот с этим засада. Из-за физических особенностей флеша, стирать его можно только большими блоками. Если в страницу уже что-то записано, ее нельзя стереть отдельно от остальных в этом erase block. Можно закатить erase для всего erase block целиком, тогда все страницы блока очистятся. Отсюда следует что erase для записи страницы требуется не всегда, но в хучшем случае действительно нужен. Кстати да, питекантроп пытающийся осознать как работают наши магнетроны соверщенно забыл про то что у флеша erase - это отдельная логически осмысленная процедура, являющаяся отдельной сущностью. Trim имеет непосредственное отношение к оной процедуре. Erase это не чтение и не запись в их привычном понимании. Это приведение всех страниц erase-block'а в чистое состояние. >> А в хучшем случае будет вообще стирание большого erase >> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно >> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :) > Выкиньте свой jmicron в помойку. Какой еще jmicron? Упомянутый спич является обобщением логики работы всей этой механики вообще. В том плане что по другому это как-то не особо то и сделаешь, даже самый хитрый контроллер будет реализовывать похожую логику и ничего не сможет поделать с тем фактом что флешу удобно работать целыми erase-block'ами или хотя-бы страницами. Выравнивание на erase-block лучше тем что ведет к избеганию ситуации когда контроллеру для всего блока надо будет сделать read-erase-modify-write, чтобы оформить частичную модификацию erase блока во что-то физически существующее. > В современных накопителях давным давно cow с gc и что там творится в реальности > знает только контроллер. Это не отменяет того факта что ему тоже удобнее всего фигачить блоками размером с erase block с правильным выравниванием. Просто потому что даже самый умный контроллер ничего такого сделать с физической природой флеша не может. Он может заныкать от вас служебное действо когда запись менее чем удобная величина ведет к read-modify-(иногда erase)-write, но отменить его и сделать чудо он не может. Trim позволяет реже нарываться на нужду erase при записи, давая контроллеру хинт что если он хочет то может в фоне вон те блоки и почистить, т.к. они не нужны. А erase довольно тормозная операция. > Любая запись там выглядит как read-modify-write, если пользовать trim есно. Wrong. Самый удачный вариант ака достаточно большая запись и только в чистые страницы будет просто программированием этих страниц. Быстро и без проблем. Trim нужен как раз для того чтобы дать шанс контроллеру заранее подчистить неиспользуемые блоки и по возможности создать именно эту, самую удачную для записи ситуацию. > Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи > будет все лишь один read с пачкой modify и одним write Уважаемый дикарь в попытках осознания процесса работы магнетрона напрочь забывает о том что у флеша есть read, program и отдельная операция известная как erase. Program и erase - две логически дополняющие друг друга сущности, грубо говоря, тягающие биты ячеек в разные стороны (одна в одно состояние, вторая в другое). По разным правилам игры, вытекающим из физического устройства флеша. Program вгоняет биты страницы в те значения которые хочется получить. А вот обратно их вернуть можно только erase'ом всего здорового блока. Если интересно - см. в английской вике, тем вполне дельно разжевано откуда такая странная брейнфакерская логика берется - она вытекает из того как биты хранятся в ячейках флеша. > в заранее чистый блок. А чтобы чистых блоков вообще не было > - так это имхо нужно забить весь накопитель к чертям и > банально писать поверху. Достаточно чтобы gc вовремя не подсуетился. Тогда ему придется делать erase прямо на ходу и скорость записи просядет, что логично. Trim нужен чтобы этого максимально избегать, выдавая хинты контроллеру что он может уже стирать вон те блоки. Не дожидаясь того момента когда припрет, так что надо бы записать, а чистых страниц что-то нету, так что давайте судорожно расчищать прямо сейчас (а запись соответственно подождет до лучших времен). > А так, любая передышка, и gc собирает мусор очищая блоки. Вот только проблема в том что сам по себе gc как-то не очень то и знает - нужен вон тот кусок данных файловой системе, или уже можно его в расход. Вот trim как раз и позволяет gc приобрести это знание и действовать именно так, заранее расчищая блоки. Упреждая ситуацию когда приперло и надо чистить блоки прямо в процессе записи, тормознув запись.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	105. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Michael Shigorin (ok), 11-Янв-12, 20:39
	> В идеале можно попробовать подогнать смещение файловой системы под erase block Не "в идеале", а "для начала". Иначе и SSD, и 4k-HDD, и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели.
	Ответить \| Правка \| К родителю #84 \| Наверх \| Cообщить модератору


	107. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 21:06
	> Не "в идеале", а "для начала". Иначе и SSD, и 4k-HDD, > и RAID5/6/50/60 будут тормозить, цепляя лишние erase block'и/секторы/шпиндели. Грабль состоит в том что для флеша это довольно сложно, поскольку истинную геометрию нам не показывают и есть минимум 2 сущности разного размера да еще CoW логика. Поэтому достоверно определить как наши действия состыкуются с внутренней механикой можно только серией хитровыгнутых экспериментов, которые к тому же в зависимости от логики контроллера совершенно не обязаны давать одинаковые или даже просто осмысленные или воспроизводимые результаты. Кстати если какое-нибудь там начало раздела и партишн тейбл еще можно осмыленно разложить, выбрав выравнивание так чтобы сие было явно кратно erase block (просто считая его кратным достаточно большому 2^N, например 512Кб выравнивание устроит как тех у кого он 512Кб, так и тех у кого блок в 256 или 128Кб) то вот например осознать как там будут блоки с данными ФС расположены - уже не так легко. А вы это в состоянии для ну хотя-бы ext4? В том плане что граница 4k блока EXTа должна бы совпасть с границей страниц флеша. Но вот проверять это... хм... а существует какой-то удобный и автоматизированный метод? И кроме того - а известен ли метод смещать блоки с данными относительно начала раздела?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–2 +/–
	Сообщение от Aleksey Salow (ok), 11-Янв-12, 14:32
	>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые >> максимально фрагментируют данные, в противном случае будет чтение из одного модуля > Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок > в группу чипов, размазав записи и чтения на кучу чипов. Минимальный блок для записи - 128K вроде как. Сколько там размер сектора? 512b. Вот и получаем что для изменения одного битика нужно переписать целый блок. В современных ssd конечно cow, но писать всё-равно будет одним блоком, правда на другой чип. >> и привет 20MB/s ;) > Теоретик хренов. Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png > А с фрагментами все не так просто. Чтобы было оптимально, > блоки должны попадать точно в erase-блоки и размер фрагмента должен быть > кратен erase-блоку. Иначе для записи придется стирать 2 блока вместо одного. > И дольше, и wearing в 2 раза увеличивается - ssd подохнет > быстрее. Это пусть у контроллера голова болит, они шибко умные нынче пошли. > А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый > на педалинг огромных битовых карт и прочих бестолковостей на ssd будет > роялить еще больше. Поэтому древность и костыльность структур ФС и тут > вам будет икаться от души. Только почему-то на этой самой ntfs всё работает хер знает когда, показывает пиковую производительность, а в линупсе только сейчас осознали что что-то не так в консерватории. Неужели так долго копили на ssd для тестов? :)
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	73. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от iZEN (ok), 11-Янв-12, 17:45
	>>> И как, есть какой-то прирост? Вообще-то для ssd полезно использовать fs которые >>> максимально фрагментируют данные, в противном случае будет чтение из одного модуля >> Вообще-то, контроллер ssd сам не тупой и отпараллелизует один большой непрерывный блок >> в группу чипов, размазав записи и чтения на кучу чипов. > Минимальный блок для записи - 128K вроде как. Сколько там размер сектора? > 512b. Вот и получаем что для изменения одного битика нужно переписать > целый блок. В современных ssd конечно cow, но писать всё-равно будет > одним блоком, правда на другой чип. В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Aleksey Salow (ok), 11-Янв-12, 17:48
	> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили). В zfs под рейды точили походу, а на ufs2 + gstripe я тоже делал 64k, страйп быстрее работал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от iZEN (ok), 11-Янв-12, 18:00
	>> В ZFS — 128k (по умолчанию), в UFS2 — 64k (недавно увеличили). > В zfs под рейды точили походу, Не только. ZFS разрабатывали в том числе для использования с SSD. ;) Все эти кширующие техники для ZIL и L2ARC описаны в применении к SSD (с быстрыми SLC и медленными MLC, соответственно). Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD хорошо и эффективно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Aleksey Salow (ok), 11-Янв-12, 18:04
	> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD > хорошо и эффективно. А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но мало ли что случится в ближайшем будущем ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	–1 +/–
	Сообщение от iZEN (ok), 11-Янв-12, 18:21
	>> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD >> хорошо и эффективно. > А ссылочку можно? Мне конечно ssd во фряхе пока не грозит, но > мало ли что случится в ближайшем будущем ;) О перспективах ZFS и флэш-памяти: http://blogs.oracle.com/jonathan_ru/entry/о_перспективах_zfs_и_флэш Ещё может пригодиться: A look at MySQL on ZFS: http://habrahabr.ru/blogs/mysql/78473/ Объяснение ARC и L2ARC: http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 19:34
	> Не только. ZFS разрабатывали в том числе для использования с SSD. ;) Ага, правда SSD в природе не было в момент дизайна ZFS, но изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый булшит от санок повторять как мантру, ведь верить в это намного приятнее, правда? :)
	Ответить \| Правка \| К родителю #77 \| Наверх \| Cообщить модератору


	111. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 11-Янв-12, 21:43
	>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;) > Ага, правда SSD в природе не было в момент дизайна ZFS, но > изена такие мелочи не волнуют, как обычно. Он лучше будет маркетинговый > булшит от санок повторять как мантру, ведь верить в это намного > приятнее, правда? :) Там другое. Например, группировка сбросов на диск по их рейтингк. ttp://constantin.glez.de/blog/2011/02/frequently-asked-questions-about-flash-memory-ssds-and-zfs ZFS also has a sophisticated cache called the "Adaptive Replacement Cache" (ARC) where it stores both most frequently used blocks of data and most recently used ones. The ARC is stored in RAM, so each block of data that is found in the RAM can be delivered quickly to the application, instead of having to fetch it again from disk. When RAM is full, data needs to be thrown out of the cache and is not available any more to accelerate reads. SSDs can be used as a second level cache: Blocks that can't be stored in the RAM-based ARC can then be stored on SSDs and in case they're needed, they can still be delivered quicker to the application than by fetching them again from disk. An SSD that is used as a second level ARC is therefore called an L2ARC, or a "cache device". Поэтому жретъ памяти, зараза :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	133. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 09:50
	> therefore called an L2ARC, or a "cache device". > Поэтому жретъ памяти, зараза :) Если честно, я в этом спиче не вижу ни 1 звука про собственно саму оптимизацию записи на SSD. То-есть рассказали про то что они умеют юзать как кеш. Ну круто. Но ни звука про то как запросы к ФС оптимизируются на предмет минимального протирания SSD и максимальной скорости работы оного. И ниоткуда не следует что кеш обязан по дефолту сливаться на диск в виде оптимальном для SSD.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	140. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 12-Янв-12, 18:04
	>> therefore called an L2ARC, or a "cache device". >> Поэтому жретъ памяти, зараза :) > Если честно, я в этом спиче не вижу ни 1 звука про Не видите звуков? Оригинально. Попробуйте пощупать код на слух.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	147. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 12-Янв-12, 20:36
	> Не видите звуков? Оригинально. Попробуйте пощупать код на слух. Тоже не слышно ничего. Поэтому процитируйте плиз где там про оптимизацию процесса записи на SSD хоть слово вообще. То что ssd в роли кеша работает лучше механики - так это не только парни из сана заметили, прикиньте? Кстати мне вот интересно - а быстро ssd там до дыр затирается?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	185. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+1 +/–
	Сообщение от netch (ok), 23-Янв-12, 22:04
	>> Не только. ZFS разрабатывали в том числе для использования с SSD. ;) > Ага, правда SSD в природе не было в момент дизайна ZFS, но > изена такие мелочи не волнуют, как обычно. Вообще-то у ZFS сейчас идёт уже где-то 15-я минимум версия пула - это раз. Флэшовые накопители были уже много лет - это два. Да, у них не было умного контроллера, ремапа по обстоятельствам и так далее, но часть проблем была уже известна. > Он лучше будет маркетинговый > булшит от санок повторять как мантру, ведь верить в это намного > приятнее, правда? :) Урежьте осетра.
	Ответить \| Правка \| К родителю #95 \| Наверх \| Cообщить модератору


	99. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 19:38
	> Шварц довольно подробно описал в своём блоге, почему использование ZFS на SSD > хорошо и эффективно. А майкрософт на своем сайте так и вообще рассказывал что виндус сервер обгоняет линукс. Верить бложику чувака из коммерческой компании? Спасибочки, а ничего что у пиарщиков всегда их продукт самый лучший? Что ж ты будешь делать если услышишь пиар конкурирующих компаний? Неужели разорвешься на 2 части? :)
	Ответить \| Правка \| К родителю #77 \| Наверх \| Cообщить модератору


	87. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 19:02
	> Минимальный блок для записи - 128K вроде как. Минимальный блок для записи у флеша - страница. Обычно 1...4Кб у nand-флешек из которых делается все и вся, от карт памяти до могучих ssd. > Сколько там размер сектора? 512b. Да хрен тебе, теоретик. У флеша нет 512-байтовых секторов. Совсем. Они эмулируются совершенно адскими высерами контроллера с read-modify-write. Кстати это же объясняет почему у некоторых господ иногда странно теряются данные. Вплоть до того что на картах памяти и юсб флехах с FATом изредка у некоторых господ очень неудачно слетает все что угодно, вплоть до таблицы разделов. Если таблица разделов попала в тот же erase-block что и например кусок FAT и питальник неудачно слетел, так что read-modify-write срубился в самом начале, кусок с MBR и таблицей разделов может и не успеть записаться. И если то что FAT должен был пострадать за то что перезаписывался в этотм момент - логично, то вот то что MBR пострадает лишь за то что его угораздило жить в том же erase block - куда менее очевидный и намного менее приятный факт :). По этой причине кстати фабричный формат на флешках и картах довольно характерно выравнивает ФС на характернуые величины, кратные 2^N, по размеру erase-block разумеется. > Вот и получаем что для изменения одного битика нужно переписать > целый блок. В современных ssd конечно cow, но писать всё-равно будет > одним блоком, правда на другой чип. А тут ты как ни странно не прогнал. Проблема только в том что один хрен загаженный блок стирать придется. Не сейчас, так потом. Единственное чего можно выиграть в стирании его не сей момент а в фоне - скорость записи. Это как езда по дороге со снегом. Если перед тобой медленно тащится снегоуборщик - понятно какая скорость езды получится. А если он заранее проехал, скорость будет другой :) > Э? Когда сделаете домашку по математике сходите на сайт микрона и почитайте > даташиты на память. Вот вам картинка для затравки: http://xxx.org.ua/cdm.png Гражданин, не наглей, да? Я не только читал гору даташитов на всевозможный флеш, я еще и программировать эти самые чипы флеша умею. Вплоть до того что я лично реализовал процедуру зашивки нескольких чипов, покурив даташиты, когда приспичило. Приколись, а? Если ты такой умный и даже даташитами козыряешь - ну покажи, в каком месте ты 512 байтные сектора у флеша углядел, для начала. [...] >> И дольше, и wearing в 2 раза увеличивается - ssd подохнет >> быстрее. > Это пусть у контроллера голова болит, они шибко умные нынче пошли. Умнота контроллера не отменяет вполне характерного устройства чипов флеша на уровне весьма базовой физики лежащей в процессе их работы. Этой физике можно подыграть даже через призму контроллера флеша. >> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый >> на педалинг огромных битовых карт и прочих бестолковостей на ssd будет >> роялить еще больше. Поэтому древность и костыльность структур ФС и тут >> вам будет икаться от души. > Только почему-то на этой самой ntfs всё работает хер знает когда, показывает > пиковую производительность, Меня интересует в основном средняя производительность и worst case, а не пиковая. Пиковая скорость записи в моей системе - несколько Гб в секунду (ram cache hit). Да, кстати линь намного умнее делает. В лине буфером ФС является почти вся свободная память прямо сразу (линь при необходимости просто урезает этот буфер на ходу), тогда как винда отращивает дисковый буфер крайне неохотно. Поэтому в лине dvd-iso sized чушка у меня просто улетает в буфер. Мгновенно. В винде ... хаха, ну ты понял. Половина в буфер влазит а дальше все, жопа. Полфайла быстро пишется, а потом... потом там уже половина исохи ждет своей записи на винч, а буфер уже кончился. И хотя оперативы еще свободно как грязи, винда не спешит отращивать буфера. Пусть лучше юзер 30 секунд ффтыкает на то как это сливается на диск, а прога будет заблочена пока в буфере еще места под данные не появится ;) > а в лину псе только сейчас осознали что что-то не так в консерватории. > Неужели так долго копили на ssd для тестов? :) Линукс мало того что умнее с дисковыми буферами работает, так еще и можно например своп на ссдшник засунуть, без риска в момент его протереть. Поставить минимальную агрессию свопинга, чтобы своп юзался как нечто на крайний случай, когда совсем прижало. И большую часть времени такой своп не будет протирать флеху с ее лимитами на число перезаписей. А вот виндовозный своп флешатину до дыр протрет довольно быстро и я как-то не в курсе - а в винде можно рулить агрессивностью свопа как в лине? А то дефолтная логика там вообще как во времена вин95, видимо с тех пор не менялось. Хотя для машин с 4гб памяти логичны совсем иные настройки чем для машин с 16Мб. В итоге винды позорно тормозят при переключении между увесистыми задачами на машине с совершенно любым количеством оперативки. Хоть 16 гиг воткни, а все-равно несколько гб фуфла в своп сольется при активном использовании. Даже если еще с десяток гигов памяти свободно и вообще нет повода гадить в своп.
	Ответить \| Правка \| К родителю #58 \| Наверх \| Cообщить модератору


	72. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от iZEN (ok), 11-Янв-12, 17:16
	> А еще в винде архаичный ntfs, как ты понимаешь, процент времени потраченый > на педалинг огромных битовых карт и прочих бестолковостей на ssd будет > роялить еще больше. Поэтому древность и костыльность структур ФС и тут > вам будет икаться от души. User294, почему ты не логинишься под своим ником? Тебе же сто раз объясняли, что битовые карты никакой существенной роли в производительности записи на ФС не несут. Чтобы они что-то значали в скорости поиска свободных блоков, нужно иметь ФС размером порядка 16 ТБ и больше.
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	89. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 19:11
	> User294, почему ты не логинишься под своим ником? Тебе же сто раз > объясняли, что битовые карты никакой существенной роли в производительности записи на > ФС не несут. Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень характерный эффект на большинстве бенчмарков ;) > Чтобы они что-то значали в скорости поиска свободных > блоков, нужно иметь ФС размером порядка 16 ТБ и больше. А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто пи...т как дышит. А тебе не приходило в бошку что компактную стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши засираются и прочее, а? Или ты думаешь что все новые дизайнф ФС экстенты стали чисто для красоты использовать? ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	101. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от iZEN (ok), 11-Янв-12, 20:18
	>> User294, почему ты не логинишься под своим ником? Тебе же сто раз >> объясняли, что битовые карты никакой существенной роли в производительности записи на >> ФС не несут. > Ага, конечно, именно поэтому замена гигантских битмапов на компактные экстенты дает очень > характерный эффект на большинстве бенчмарков ;) Карта свободных блоков — битмапы — кэшируются в ОЗУ. Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см. "FreeBSD. Архитектура и реализация"). >> Чтобы они что-то значали в скорости поиска свободных >> блоков, нужно иметь ФС размером порядка 16 ТБ и больше. > А судя по бенчмаркам хоть того же ext3 vs ext4 кое кто > пи...т как дышит. А тебе не приходило в бошку что компактную > стркутуру читать, парсить и писать - натурально быстрее, меньше всевозможные кеши > засираются и прочее, а? Или ты думаешь что все новые дизайнф > ФС экстенты стали чисто для красоты использовать? ;) Экстенты из другой оперы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	106. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 11-Янв-12, 20:46
	> Карта свободных блоков — битмапы — кэшируются в ОЗУ. И что? Это не отменяет нужды читать/писать их на диск (озу знаешь ли не энергонезависимое) и модифиицровать довольно крупные битмапы. > Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см. > "FreeBSD. Архитектура и реализация"). Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий бсдун. Остальные это называют окаменелым пометом мамонта. >> засираются и прочее, а? Или ты думаешь что все новые дизайнф >> ФС экстенты стали чисто для красоты использовать? ;) > Экстенты из другой оперы. Обычно из той же самой. Или уж занятость блоков описывается битмапой, или уж какой-то компактной структурой, например упакованой в дерево.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	119. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 11-Янв-12, 22:49
	>> Для поддержки адресации 1 ТБ UFS2 нужно всего лишь 64 МБ оперативной памяти (см. >> "FreeBSD. Архитектура и реализация"). > Сам смотри свой окаменелый шитец, имхо. Называть это архитектурой может только настоящий > бсдун. Остальные это называют окаменелым пометом мамонта. Ваш генный код старее окаменелого говна мамонта. И судя по вашему тексту, назвать это удачной реализацией архитектуры можно только с натягом. Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не вставать. http://www.usenix.org/publications/library/proceedings/useni...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	159. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 13-Янв-12, 20:15
	> Ваш генный код старее окаменелого го вна мамонта. И судя по вашему тексту, > назвать это удачной реализацией архитектуры можно только с натягом. Мы существа одного вида, поэтому вам наверное недостатки видны не хуже меня, на своем примере :) > Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не > вставать. Ага, только к SSD это все не относится практически никак.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	163. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от uniman (ok), 13-Янв-12, 20:46
	>> Для остальных описание метода сведения метаданных FS, шоб накопителю два раза не >> вставать. > Ага, только к SSD это все не относится практически никак. Точно, реализация FS не относиться к SSD никак. Кстати, о чем новость? Перечитайте предложение выше, для начала, и постарарайтесь поразмыслить на предмет реализации стратегии записи через интерфейс, и как реализация стратегии записи вообще относится к записи байтиками и вышивке крестиками.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	189. "Для ядра Linux представлен планировщик ввода-вывода FIOPS дл..."	+/–
	Сообщение от Аноним (-), 01-Фев-12, 17:17
	> Точно, реализация FS не относиться к SSD никак. Не согласен. Есть более удобные и менее удобные для ssd файловые системы, более того - с учетом иных физических свойств накопителя оверхед от операций ФС вылезет совсем в ином виде. И кому как не файловой системе видно что и где (не)используется? > Кстати, о чем новость? О планиовщике I/O. > стратегии записи через интерфейс, и как реализация стратегии записи вообще относится > к записи байтиками и вышивке крестиками. Например, самое очевидное: логично подгонять стратегию таким образом чтобы накопителю было удобно записывать то что ему в результате этой стратегии свалилось. Дебильно выбрав стратегию можно основательно просадить скорость записи у SSD.
	Ответить \| Правка \| Наверх \| Cообщить модератору