The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Оценка производительности файловой системы F2FS, включённой ..., opennews (?), 22-Фев-13, (0) [смотреть все]

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


9. "Оценка производительности файловой системы F2FS, включённой ..."  –3 +/
Сообщение от iZEN (ok), 22-Фев-13, 11:43 
Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше.

Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который подготавливает пространство SSD под использование файловой системы, будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали, так как ФС там дюже умные и сами определяют, какой носитель они используют.

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

14. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 12:03 
>ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше.

ARC вообще не должно быть в грамотно спроектированной фс.

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

20. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 12:44 
> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти.

Да, да, отдельный кэш у ФС, не управляемый непосредственно ядром ОС - это пиндец как оптимально. Не, извините, юзеры линукса привыкли к нормально работающим решениям, а не вот такому вот.

> Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо".
> ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше.

Ну значит при большой записи он лишний раз тормознет. Понимаешь, пока вы его на костылях и подпорках учите бегать, в нормальных ФС дисковый кэш играет с кернелом в совместную игру, так что ФСам по сути всегда доступна вся свободная память покуда она есть. А как только она становится нужна - кернел может ее оттяпать форсированным образом, вплоть до форсирования сброса буфферов на диск с целью их изъятия. А случае живущего своей жизнью ARC так не катит.

> Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику
> 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD.

А также сдвиг по erase-блокам и прочая. Но это в идеале. А реально - половина юзерей безбашенно форматнет "уж как вышло". И хорошо бы чтобы ФС не падала в грязь лицом даже при таком, не столь удачном раскладе.

> Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который
> подготавливает пространство SSD под использование файловой системы,

И чем он так уж помогает флешу? И чего он такого делает, чего нельзя сделать иными средствами? Или это очередной понт "от изена"?

> будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали,
> так как ФС там дюже умные и сами определяют, какой носитель они используют.

Тем не менее, там есть и возможность вручную тыкнуть "а вот считай это SSD" или "а заюзай-ка trim вот с этим носителем". И да, если ты не понял, ФС должна довольно сильно менять логику работы под SSD, ориентируясь на крупноблочный обмен. Но зато совершенно не парясь насчет времени перемещения голов, которого нет. По поводу чего опция монтирования с требованием сделать именно это самое - смотрится вполне логично.

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

23. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от BayaN (ok), 22-Фев-13, 12:57 
>И чем он так уж помогает флешу? И чего он такого делает, чего нельзя сделать иными средствами? Или это очередной понт "от изена"?

А ничем, iZEN просто как всегда сморозил чушь:

>    The gnop utility is used for setting up transparent providers on existing
>    ones.  Its main purpose is testing other GEOM classes, as it allows
>    forced provider removal and I/O error simulation with a given probabil-
>    ity.  It also gathers the following statistics: number of read requests,
>    number of write requests, number of bytes read and number of bytes writ-
>    ten.  In addition, it can be used as a good starting point for implement-
>    ing new GEOM classes.

Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него просто есть возможность задать смещение, т.к. выровнять область на границу 4K. Это был временный костыль. Сейчас насколько мне известно всё делается с помощью gpart.

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

27. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от Аноним (-), 22-Фев-13, 13:04 
> Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него
> просто есть возможность задать смещение,

А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным образом, а изен почему-то решил что это - фича. Бывает :)

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

33. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от BayaN (ok), 22-Фев-13, 13:41 
> А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным
> образом

Нет, не так. Когда появились первые диски с 4K сектором (причём сообщающие, что у них всё по старому - 512), в списках рассылки freebsd возникла заворушка, типа всё тормозит и чё делать. Пришли к выводу что делать надо, нужно кодить. Но внезапно GEOM опять проявил свою гибкость и оказалось, что можно изпользовать GNOP в несвойственной ему области. Поэтому тем кому надо кровь из носу прямо сейчас, могут использовать GNOP, что не отменяет костыльность этого способа. Затем естественно проблему решили нормальным способом.



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

37. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 13:57 
> freebsd возникла заворушка, типа всё тормозит и чё делать. Пришли к
> выводу что делать надо, нужно кодить.

Да что там кодить то? Только смещение начала партиции указать. Неужто у бсдоидов партиционер такой элементарщины раньше не позволял? (для ФС на флеше хорошо бы еще угадать с началом erase block, делая отступ от начала диска на нечто кратное, допустим 512К).

> Но внезапно GEOM опять проявил свою гибкость и оказалось, что можно изпользовать
> GNOP в несвойственной ему области. Поэтому тем кому надо кровь из носу прямо сейчас,
> могут использовать GNOP, что не отменяет костыльность этого способа.

Ну я и говорю - неумение партиционера нормально размечать диски походу скомпенсировали таким вот фигурным костылем. А изен почему-то думает что это - фича. Лол :)

> Затем естественно проблему решили нормальным способом.

...а изен, забывший отпустить ручник, по прежнему считает что те костыли - не баг а фича...


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

36. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от iZEN (ok), 22-Фев-13, 13:52 
>> Это GEOM модуль для тестирование фреймворка. В случае с 4K, у него
>> просто есть возможность задать смещение,
> А, понятно, в бзде как обычно подставили изощренный костыль партиционеру весьма странным
> образом, а изен почему-то решил что это - фича. Бывает :)

SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что внутри флэша контроллер работает с 4k-блоками. Каким образом известить файловую систему о том, чтобы она использовала другое физическое представление секторов и отличала SSD от стандартного HDD? Подумай на досуге.


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

41. "Оценка производительности файловой системы F2FS, включённой ..."  –1 +/
Сообщение от ананим (?), 22-Фев-13, 14:14 
>SSD Crucial в dmesg пишет о 512 байтных секторах.

первый вопрос — в бздях?

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

69. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от iZEN (ok), 22-Фев-13, 22:07 
>>SSD Crucial в dmesg пишет о 512 байтных секторах.
> первый вопрос — в бздях?

В бздях. В линуксях по-другому?


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

42. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 14:23 
>> образом, а изен почему-то решил что это - фича. Бывает :)
> SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что
> внутри флэша контроллер работает с 4k-блоками. Каким образом известить файловую систему
> о том, чтобы она использовала другое физическое представление секторов и отличала
> SSD от стандартного HDD? Подумай на досуге.

Ну лично я вообше захинтил ext4'му в опциях что "это у нас, типа, stripe, с блоком 512К" при этом ФС будет стараться вести обмен с накопителем блоками по размеру erase-block'а. Что для SSD лучше чем россыпь из кучи мелочи на вход. Есть у ext4 такие твикинги. Оно исходно под RAID-ы заточено, но, собственно, я не вижу почему бы не применить этот фокус и к SSD, которому крупноблочный формат обмена явно лучше россыпи, которая почем зря заставит изгаляться FTL-уровень по распихиванию "куда-нибудь". Так что оно будет пытаться по возможности оперировать даже не страницами а erase block за раз. Что по идее должно быть достаточно удобным для накопителя.

Алсо, у ФС типа ext4 по сути нет понятия "сектор". Есть "блок ФС". Это минимально адресуемый за раз юнит. То что он по дефолту 4К - очень кстати. И остается разложить ФС так чтобы блоки не попадали на пересечение страниц. Сдается мне что если я выравнивал размещение ФС на целые 512К (по erase block'у), на страницы оно при этом "само" выровняется, просто потому что 4K * 128 == 512K. Т.е. я разложил ext4 с отступом кратным erase block от начала диска. Ну и ясен пень включил trim. В целом вроде неплохо работает - за почти год SSD протерся на 1% судя по SMART.

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

56. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Харитон (?), 22-Фев-13, 15:06 
В целом
> вроде неплохо работает - за почти год SSD протерся на 1%
> судя по SMART.

А по какому параметру вы это смотрите? А то я когда-то читал что для ССД смартцтл должен быть начиная с определенной версии и различные стандартные значения СМАРТА для винта имеют другое смысловое значение для ССД...

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

60. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 15:28 
Wear Leveling Count
http://www.citilink.ru/promo/crucial/review128.php
Ответить | Правка | Наверх | Cообщить модератору

72. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 23:22 
> А по какому параметру вы это смотрите?

У моего SSD несколько параметров касающихся wearing.
Наиболее интересные:
1) 233 Media_Wearout_Indicator, насколько я понимаю это процент износа (в процентах, vs число циклов/задекларированное для флеша производителем). У меня пока оно вообще идеальное, как у нового диска. С точностью до 1%. Получается что я пока не протер даже на 1%.
2) 226 Workld_Media_Wear_Indic - тоже нечто касающееся износа, однако формат цифры не соответствует даташиту. Ну, чтобы интел и совсем без багов - так не бывает :). Теоретически, там записан износ с момента последнего сброса таймера. Практически у меня этот атрибут содержит нечто, что совсем не укладывается в формат числа из даташита, по поводу чего интерпретировать данное поле мне не удалось.
3) 241 Host_Writes_32MiB - объем записанных данных, в 32Mb попугаях. Можно грубо прикинуть число циклов которые проехали. И/или сравнить с задекларированным объемом записи (для моего накопителя 60Tb). По ним как раз получается что я 1% не добрал.

Но это валидно только для SSD intel и только для серии с контроллером от интел. У других производителей могут быть иные атрибуты.

> А то я когда-то читал что для ССД смартцтл должен быть начиная с определенной версии и
> различные стандартные значения СМАРТА для винта имеют другое смысловое значение для ССД...

Абсолютно другое, т.к. параметры касающиеся вращаюшихся дисков к SSD неприменимы вообще. Smartctl должен быть достаточно свежий + девайс должен быть в его базе. Иначе он просто не сможет понять что это за атрибуты и будет выводить их как unknown_attribute. Впрочем, зная номер атрибута и производителя, можно скормить это гуглю и узнать WTF. Но лучше если smartctl сам по человечески покажет.

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

70. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от iZEN (ok), 22-Фев-13, 22:22 
> Алсо, у ФС типа ext4 по сути нет понятия "сектор".

Понятие "сектор" — физическая единица адресации пространства носителя.

> Есть "блок ФС". Это минимально адресуемый за раз юнит.

В NTFS и FAT он называется "кластер". И что?

> То что он по дефолту 4К - очень кстати. И остается разложить ФС так чтобы блоки не попадали на пересечение страниц.

Это достигается выравниванием размеченного раздела по границе, кратной 4k.

> Сдается мне что если я выравнивал размещение ФС на целые 512К (по erase block'у), на страницы оно при этом "само" выровняется

Оно само не выровняется. Просто твой хвост от 512k-блока ФС может по недоумению захватить первую четверть, две четверти или три четверти 4k-блока, а остальной кусочек будет уже принадлежать следующему по физическому расположению 512k-блоку ФС, и не факт, что эта пара блоков ФС будет принадлежать одному и тому же файлу.

Кроме того, 512k-блоки — это заранее обрекать себя на потерю пространства на маленьких (размером <512k) файлах.

> просто потому что 4K * 128 == 512K. Т.е. я разложил ext4 с отступом кратным erase block от начала диска.

У меня:
% gpart show ada4
=>       34  125045357  ada4  GPT  (59G)
         34          6        - free -  (3.0k)
         40       1024     1  freebsd-boot  (512k)
       1064        984        - free -  (492k)
       2048  125040000     2  freebsd-zfs  (59G)
  125042048       3343        - free -  (1.6M)

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

73. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 23:58 
>> Алсо, у ФС типа ext4 по сути нет понятия "сектор".
> Понятие "сектор" — физическая единица адресации пространства носителя.

Спасибо, капитан. Правда учитывая что SSD для записи 512 байтного сектора делает read-modify-write, это всего лишь такой красивый логический трындеж в паспорте диска, не имеющий под собой никакого реального физического смысла. Это всего лишь гнусная эмуляция, для того чтобы легаси софт (==древние ОС), который не подозревает о SSD не сыпался как горох. Полагаться на этот трындеж - себе дороже. Т.к. работа кусками по 512 байтов будет медленной, неэффективной и с конским write amplification factor, что поможет SSD побыстрее сдохнуть.

>> Есть "блок ФС". Это минимально адресуемый за раз юнит.
> В NTFS и FAT он называется "кластер". И что?

А ничего, то же самое по смыслу. И производители флешек с FAT отлично в курсе этого момента. И очень характерно кроят для них FAT и партишн тейблы, откровенно выравнивая все это на erase block. Чтоб оно по разным erase block было. Что спасает партишн тейбл от слета в момент когда апдейтили фат и питание слетело.

> Это достигается выравниванием размеченного раздела по границе, кратной 4k.

Какой ты догадливый. А лучше уж по erase block-у, т.е. 512К. В том числе из-за озвученных выше соображений, дабы развязать апдейт критичных структур друг от друга. Дабл факап служебных структур - досаден вдвойне.

> Оно само не выровняется. Просто твой хвост от 512k-блока ФС может по
> недоумению захватить первую четверть, две четверти или три четверти 4k-блока,

Ты не понял, в erase-block целове число страниц, при том одинаковое :). В частности erase-block на 512К содержит 128 x 4K страниц. Так что при выравнивании на 512К выравнивание на 4К получится "само" - просто потому что они кратные. А то что ты сказал - это случай когда выравнивание на 512К не удалось сделать.

> а остальной кусочек будет уже принадлежать следующему по физическому расположению 512k-блоку

Ну так это случай когда выравнивание на 512К не удалось сделать как раз. А если ты разместил структуры с смещением кратным 512К, оно будет автоматически кратно и 4К до кучи. И мне кажется наиболее логичным целиться в это двойное совпадение по возможности. Ну, как производители SD/флешек на фабричном формате примерно. Они ж не просто так делают, а из соображений оптимальной скорости и минимального веаринга. Как раз по озвученным тобой же :) причинам.

> ФС, и не факт, что эта пара блоков ФС будет принадлежать одному и тому же файлу.

Ну да, совершенно. Поэтому есть некий write amplification factor, т.е. фактически записей в флеш для удовлетворения конкретных запросов может оказаться больше чем размер запроса. Из-за фрагментации свободного места, например. В этом месте мы знакомимся с TRIM и его подыгрышем garbage collection, нацеленными на минимизацию этого безобразия. С trim накопитель может явно знать какие регионы не используются и расчистив заранее регионы более удачно раскладывать данные + не натыкаться на нужду GC+erase непосредственно в момент записи.

> Кроме того, 512k-блоки — это заранее обрекать себя на потерю пространства на
> маленьких (размером <512k) файлах.

Ну да, поэтому я обошелся более "мягким" хинтом ФС что желаемый размер "страйпа" - вот такой. При этом некий риск что хвост блока будет не идеально стыковаться с erase block - таки есть. Но в целом оно судя по всему работает достаточно недурно, судя по тому что за год SSD даже на 1% не затерся.

>   2  freebsd-zfs  (59G)

Пардон, ZFS достаточно навернут и я не возьмусь даже грубо прикидывать как его variable length блоки будут раскладываться относительно страниц/erase blocks. Если в случае с фиксированными блоками это еще можно прикинуть, то для variable - дохлый номер. Теоретически, на флеше минимальный размер variable блока должен быть 4К и инкремент - строго кратный 4К. Ну, чтоб выравнивание хотя-бы на страницы после такого блока не отъехало. Практически я не знаю можно ли допинать блоки переменного размера ZFS до такой кондиции. Это высший пилотаж для гур в ZFS уже. В случае экстентов типа того что в ext4, такое свойство "само" получается "автоматически", просто потому что минимальным адресуемым юнитом является блок ФС в 4К и менее крупный юнит не будет использоваться, а экстент - это регион из эн * 4K блоков. Что довольно неплохо с точки зрения попадания в геометрию флеша без пересечений.

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

77. "Оценка производительности файловой системы F2FS, включённой ..."  –2 +/
Сообщение от iZEN (ok), 23-Фев-13, 00:51 
> Пардон, ZFS достаточно навернут и я не возьмусь даже грубо прикидывать как
> его variable length блоки будут раскладываться относительно страниц/erase blocks.

Минимальный размер блока ZFS — 128k. То есть кратно 4k физическим блокам.

> Если
> в случае с фиксированными блоками это еще можно прикинуть, то для
> variable - дохлый номер.

Дохлый номер — это если варьируемый размер блока ФС не будет кратен размеру физического блока флэшатины — 4k, что в случае с ZFS исключено, так как у ней 128k — это ступень, от которой прыгают экстенты, которые, в свою очередь, не могут быть меньше размера базового блока (128k), но всегда кратны размеру блока ФС.

> Теоретически, на флеше минимальный размер variable блока
> должен быть 4К и инкремент - строго кратный 4К.

Именно.

> Ну, чтоб
> выравнивание хотя-бы на страницы после такого блока не отъехало. Практически я
> не знаю можно ли допинать блоки переменного размера ZFS до такой
> кондиции. Это высший пилотаж для гур в ZFS уже.

В своё время, как только ZFS выпустили в продакшен, генеральный директор Sun Шварц написал в своём бложике, что для SSD это — идеальная файловая система, так как решает сразу несколько проблем: обеспечивает контроль за целостностью данных в режиме запроса данных, имеет CoW принцип — старые данные не перезаписываются новыми, новые данные пишутся в новое место, затирая разве что самые старые данные, щадя флэш от перезаписи одних и тех же физических секторов.

> В случае
> экстентов типа того что в ext4, такое свойство "само" получается "автоматически",
> просто потому что минимальным адресуемым юнитом является блок ФС в 4К
> и менее крупный юнит не будет использоваться, а экстент - это
> регион из эн * 4K блоков. Что довольно неплохо с точки
> зрения попадания в геометрию флеша без пересечений.

А экстент в ZFS, по-твоему, это какого размера регион? Те же самые n*128k блоков файловой системы. ;)


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

45. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 14:30 
второе — в линухе вопрос решён.
>4096 looks good to me!!

http://forum.crucial.com/t5/Solid-State-Drives-SSD/linux/m-p...
если (если!!!) не решён, то
>Thus, I set up the file systems on the Intel SSD like this:
>mkfs.ext4 -b 1024 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda1
>mkfs.ext4 -b 4096 -E stride=32,stripe-width=32 /dev/sda3

http://blog.nuclex-games.com/2009/12/aligning-an-ssd-on-linux/
для btrfs — создаём с параметрами:
-A, --alloc-start offset     Specify the offset from the start of the device to start the btrfs filesystem.
-s, --sectorsize size        Specify the sectorsize, the minimum block allocation.
-n, --nodesize size         Specify the nodesize. By default the value is set to the pagesize.
монтируем как-то так:
space_cache,inode_cache,discard,noatime,rw,ssd,compress=lzo,thread_pool=32

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

80. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Michael Shigorinemail (ok), 02-Мрт-13, 00:10 
> SSD Crucial в dmesg пишет о 512 байтных секторах. Хотя известно, что
> внутри флэша контроллер работает с 4k-блоками.

JFYI, про erase block в 4k на SSD ещё не слышал -- обычно 128k.

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

34. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от iZEN (ok), 22-Фев-13, 13:48 
> В случае с 4K, у него просто есть возможность задать смещение, т.к. выровнять область на границу 4K.

Ни о каком смещении я не говорил, так как это привелегия gpart. Я имел в виду возможность прямого указания с помощью gnop размера "сектора" (см. ключ -S) для прозрачной трансляции этой информации ФС, которая работает с SSD, говорящем в dmesg о 512-байтовых секторах.

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

39. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 14:04 
какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру:
# smartctl -i /dev/sda
Model Family:     Seagate Momentus 7200.4
Device Model:     ST9500420ASG

Sector Size:      512 bytes logical/physical
# smartctl -i /dev/sdc
Model Family:     Seagate Momentus SpinPoint M8 (AF)

Sector Sizes:     512 bytes logical, 4096 bytes physical

нахрен не нужно вставлять дополнительную сущность для тривиальной операции.
тем более для zfs/btrfs.
разбил диск, создал фс, всё. как создал, так создал. как разбил, так разбил.
ты же предлагаешь заниматься преобразованиями данных через geom.
зыж
это для винтов. у кого есть ssd, плс, покажите айзену.

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

43. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 14:26 
> Sector Sizes:     512 bytes logical, 4096 bytes physical

А SSD от интеля врет про 512 байтов. Так что раз на раз...

> ты же предлагаешь заниматься преобразованиями данных через geom.

Я так понимаю, он не отпустиил ручник. Тут из зала более адекватные личности подсказывают :)

> это для винтов. у кого есть ssd, плс, покажите айзену.

Увы, мой ssd врет :)
Sector Size:      512 bytes logical/physical

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

46. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 14:35 
>> Sector Sizes:     512 bytes logical, 4096 bytes physical
>А SSD от интеля врет про 512 байтов. Так что раз на раз...

врёт, исправляйте вручную.
вон выше пару примеров дал.

>Увы, мой ssd врет :)
>Sector Size:      512 bytes logical/physical

а весь вывод смарта можно посмотреть? :D

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

51. "Оценка производительности файловой системы F2FS, включённой ..."  –1 +/
Сообщение от BayaN (ok), 22-Фев-13, 14:44 
> вон выше пару примеров дал.

Дай пример для ZFS.


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

54. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от ананим (?), 22-Фев-13, 14:49 
а зачем мне?
тут айзен за zfs оборону держит.
Ответить | Правка | Наверх | Cообщить модератору

76. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 23-Фев-13, 00:13 
> врёт, исправляйте вручную.

Ну ясен фиг, я как-то так и кроил себе ФС: захинтил размер страйпа в 512К + смещение подогнал. Журнал не отключал (kamikaze mode off), веар-левелинг худо-бедно с ним справится, тем паче что там только метаданные.

> а весь вывод смарта можно посмотреть? :D

=== START OF INFORMATION SECTION ===
Model Family:     Intel 320 Series SSDs
Device Model:     INTEL SSDSA2CW080G3
Serial Number:    <skip>
LU WWN Device Id: <skip>
Firmware Version: 4PC10362
User Capacity:    80,025,280,000 bytes [80.0 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Fri Feb 22 21:11:53 2013 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
(полный вывод занимает пару страниц и был заскипан)

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

81. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Michael Shigorinemail (ok), 02-Мрт-13, 00:16 
>>Увы, мой ssd врет :)
>>Sector Size:      512 bytes logical/physical

Аналогично для SanDisk SSD U100 252GB и KINGSTON SNVP325S2128GB.

> а весь вывод смарта можно посмотреть? :D

Без толку, мы в них (конкретно WD 15EARS) чем только не тыкали, почитав спецификацию.  Информация и ссылки по теме собраны на http://www.altlinux.org/BigSector

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

50. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от BayaN (ok), 22-Фев-13, 14:42 
>какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру

Простая, если диск врёт.

> нахрен не нужно вставлять дополнительную сущность для тривиальной операции.

тем более для zfs/btrfs.

В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер. Тут iZEN прав, с помощью GNOP её сообщают настоящий размер сектора. UFS2 в этом плане всегда нормально работает.

В случае с нормальными дисками. Ничего, кроме выравнивания разделов с помощью gpart делать не надо.

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

53. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 14:48 
>>какая в попу привелегия? эта инфа есть в смарт на самом носителе. к примеру
>Простая, если диск врёт.

да елки-палки…
врёт? исправляйте вручную параметрами при создании фс.
(если вы конечно узнали правильные)

>В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер.

для бтр вон выше параметры создания привёл.
а если фс нельзя заставить использовать те или иные параметры, то либо меняйте фс, либо устройство.
а заниматься преобразованиями данных… это даже для айзена слишком.

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

62. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от BayaN (ok), 22-Фев-13, 16:34 
> да елки-палки…
> врёт? исправляйте вручную параметрами при создании фс.
> (если вы конечно узнали правильные)

Для ZFS нельзя так сделать. Поэтому во FreeBSD фигачат gnop, в illumos'е конфигурят драйвер, в Linux'е я хз, как они это обходят.

> а если фс нельзя заставить использовать те или иные параметры, то либо
> меняйте фс, либо устройство.

Вариант, но не всегда.

> а заниматься преобразованиями данных… это даже для айзена слишком.

GNOP не занимается преобразованием данных, это класс который который прозрачно проталкивает данные дальше по графу. Тормозить там нечему.

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

59. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от ананим (?), 22-Фев-13, 15:18 
>В том-то и дело, что как раз для тривиальной операции для ZFS весь это геморой до сих пор и нужен, т.к. если диск врёт о размере сектора, то для ZFS нету способа задать размер.

а что, вот как то так обмануть нельзя http://blog.nuclex-games.com/2009/12/aligning-an-ssd-on-linux/
>To make fdisk use 32 heads and 32 sectors, remove all partitions from a hard drive and then launch fdisk with the following command line when you create the first partition:
> fdisk -S 32 -H 32 /dev/sda
>For a normal hard drive, I’d probably use 128 heads and 32 tracks now to achieve 4 KiB boundaries for my partitions.

не?

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

61. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от BayaN (ok), 22-Фев-13, 16:28 
> не?

Не, http://savagedlight.me/2012/07/15/freebsd-zfs-advanced-format/:

ZFS is smart enough to query the underlying device to see how large its sectors are, and use this information to determine the size of its dynamic-width stripes. This is all fine and dandy for as long as the hardware isn’t lying. Sadly, hardware currently lie more often than not. My drives claim to have a logical sector size of 512 bytes (ashift=9 because 2^9=512) while the physical sectors are 4Kib (ashift=12). As such, ZFS will make stripes aligned to 512 bytes. This means stripes will almost always be non-aligned, forcing the underlying device to work its magic which in turn degrades performance.

Это проблема только кривых дисков. Выравнивание разделов спокойно делается с помощью gpart. GNOP в данном случае просто костыль, который сообщает ZFS правильный размер сектора.

Хотя мне например, решение у illumos больше нравится (хотя это тоже костыль) http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+For...:

Some operating systems provide a way to pass the desired ashift value to zpool invokation in some way, or even hard-code ashift=12 into a separately built zpool binary.

The illumos-gate did not, after long discussions, follow this "trivial" path. Instead, illumos-based OSes can now override the physical block (sector) size for "talking" to particular devices regardless of what they announce, by using a value configured in the sd(7d) driver. Once the device vendor and identification strings are known, the /kernel/drv/sd.conf file can be modified:
sd-config-list =
        "SEAGATE ST3300657SS", "physical-block-size:4096",
        "DGC     RAID", "physical-block-size:4096",
        "NETAPP  LUN", "physical-block-size:4096";

Т.е. они конфигурируют драйвер, чтобы тот указывал нужный размер блока, а не тот, что рапортует железяка.

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

68. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от iZEN (ok), 22-Фев-13, 22:05 
На смотри:

% smartctl -i /dev/ada4
smartctl 6.0 2012-10-10 r3643 [FreeBSD 9.1-STABLE amd64] (local build)
Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron RealSSD C300/C400/m4
Device Model:     M4-CT064M4SSD2
Serial Number:    0000000012170909003D
LU WWN Device Id: 5 00a075 10909003d
Firmware Version: 000F
User Capacity:    64 023 257 088 bytes [64,0 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Fri Feb 22 22:03:33 2013 VOLT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


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

28. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от Аноним (-), 22-Фев-13, 13:05 
>[оверквотинг удален]
> работающим решениям, а не вот такому вот.
>> Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо".
>> ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше.
> Ну значит при большой записи он лишний раз тормознет. Понимаешь, пока вы
> его на костылях и подпорках учите бегать, в нормальных ФС дисковый
> кэш играет с кернелом в совместную игру, так что ФСам по
> сути всегда доступна вся свободная память покуда она есть. А как
> только она становится нужна - кернел может ее оттяпать форсированным образом,
> вплоть до форсирования сброса буфферов на диск с целью их изъятия.
> А случае живущего своей жизнью ARC так не катит.

Ты в этом уверен? Ткни мне место в сорце ZFS, где это написано, угумс? Потом потолкуем, чего там не катит, ага?

PS. Не надо трындеть о том, в чем ты не разбираешься и чего ты своими глазами НЕ ВИДЕЛ. Смекаешь?

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

52. "Оценка производительности файловой системы F2FS, включённой ..."  +2 +/
Сообщение от Аноним (-), 22-Фев-13, 14:45 
> Ты в этом уверен? Ткни мне место в сорце ZFS, где это
> написано, угумс? Потом потолкуем, чего там не катит, ага?

Фирма Оракл поздравляет мальчиков с 23 февраля, а девочек с 8 марта. И дарит вам всем замечательный подарок: http://hub.opensolaris.org/bin/view/Main/

"Site Unavailable After March 24, 2013"
In preparation for the decommission of opensolaris.org, certain content, mailing lists and projects will be moving to java.net and/or the Oracle Technology Network (OTN). If you have questions about a particular collective, contact a leader of that collective.

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

38. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от iZEN (ok), 22-Фев-13, 13:58 
>> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти.
> Да, да, отдельный кэш у ФС, не управляемый непосредственно ядром ОС -
> это пиндец как оптимально. Не, извините, юзеры линукса привыкли к нормально
> работающим решениям, а не вот такому вот.

Вообще-то, ZFS— часть ядра FreeBSD. Если в линуксе не так, то и говорите за линукс. Зачем в кучу мешать коней и людей?

>> Что было месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо".
>> ARC не так агрессивно распоряжается свободной оперативной памятью, как раньше.
> Ну значит при большой записи он лишний раз тормознет.

ARC никак не связан с записью. Это кэш для чтения.

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

У вас, может быть, он и живёт "своей жизнью". Но обобщать не надо.

>> Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику
>> 4k-блоков флешатины вместо стандартных 512 байтных секторов HDD.
> А также сдвиг по erase-блокам и прочая. Но это в идеале. А
> реально - половина юзерей безбашенно форматнет "уж как вышло". И хорошо
> бы чтобы ФС не падала в грязь лицом даже при таком,
> не столь удачном раскладе.

Поэтому ZFS используется специалистами весьма эффективно, а такими, как вы, — как придётся.

>> Для этого на FreeBSD есть провайдер GEOM Nop gnop(8), который
>> подготавливает пространство SSD под использование файловой системы,
> И чем он так уж помогает флешу? И чего он такого делает,
> чего нельзя сделать иными средствами?

Он помогает флэшу не делать перезаписей соседних областей (флэш перезаписывает полностью 4k блок) на любую серию 512-байтных "чихов" ФС.

>> будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об этом не слышали,
>> так как ФС там дюже умные и сами определяют, какой носитель они используют.
> Тем не менее, там есть и возможность вручную тыкнуть "а вот считай
> это SSD" или "а заюзай-ка trim вот с этим носителем". И
> да, если ты не понял, ФС должна довольно сильно менять логику
> работы под SSD, ориентируясь на крупноблочный обмен.

Вот именно я это и хочу донести. ФС не откуда узнать о правильной структуре флэша, если информация от него самого фальшива.

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

57. "Оценка производительности файловой системы F2FS, включённой ..."  –1 +/
Сообщение от Аноним (-), 22-Фев-13, 15:08 
> Зачем в кучу мешать коней и людей?

Оно у вас конечно часть ядра, но - примотанная скотчем сбоку. Со всеми вытекающими.

> ARC никак не связан с записью. Это кэш для чтения.

IIRC он таки и на чтение и на запись работает. Так что походу тебя жестоко глючит.

>> А случае живущего своей жизнью ARC так не катит.
> У вас, может быть, он и живёт "своей жизнью". Но обобщать не надо.

Угу, расскажи еще что бсдшники полностью переписали управление кешом. Сомнительно как-то при вечной нехватке ресурсов то.

> Поэтому ZFS используется специалистами весьма эффективно, а такими, как вы, — как придётся.

Да, как он используется специалистами типа iZEN я уже видел. Получить 6Мб/сек на шпиндель может только настоящий гуру.

> Он помогает флэшу не делать перезаписей соседних областей (флэш перезаписывает
> полностью 4k блок) на любую серию 512-байтных "чихов" ФС.

А приколись, в каком-нибудь ext4 минимальный юнит адресации равен блоку ФС и если он 4К то это получается "само" и "нахаляву". А еще там есть хинтинг для страйпа. Можно попытаться спровоцировать обмен размером с erase block, чтобы уж совсем хорошо.

>> да, если ты не понял, ФС должна довольно сильно менять логику
>> работы под SSD, ориентируясь на крупноблочный обмен.
> Вот именно я это и хочу донести. ФС не откуда узнать о
> правильной структуре флэша, если информация от него самого фальшива.

Как ни странно, в этом месте ты даже не очень уж и натрындел. Тем не менее, если ФС может распознать SSD, логично применить ряд более-менее универсальных оптимизаций. Типа попытки работать относительно крупными блоками, но не обязательно близкими в логическом пространстве накопителя.

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

71. "Оценка производительности файловой системы F2FS, включённой ..."  +1 +/
Сообщение от iZEN (ok), 22-Фев-13, 22:26 
>> ARC никак не связан с записью. Это кэш для чтения.
> IIRC он таки и на чтение и на запись работает. Так что походу тебя жестоко глючит.

Матчасть подучи по ZFS, потом приходи.

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

75. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от kurokaze (ok), 23-Фев-13, 00:06 
> Матчасть подучи по ZFS, потом приходи.

Матчасть?! Изень, я как много лет юзавший фряху и пишуший на жабке, утверждаю что ты и матчасть - это даже не разны планеты, это разные галактики.
Все на что ты способен - позорить любую отрасль своими кривыми лапками - будь то фряха или жабка или фс.
А знаешь почему? Потому что ты бздун.


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

78. "Оценка производительности файловой системы F2FS, включённой ..."  +/
Сообщение от exn (??), 23-Фев-13, 19:16 
> Сейчас ZFS серьёзно оптимизировали по потреблению ресурсов оперативной памяти. Что было >месяц назад и что сейчас на FreeBSD 9.1-STABLE — "земля и небо". ARC не так агрессивно >распоряжается свободной оперативной памятью, как раньше.
>Файловые системы для SSD нужно ещё правильно готовить, чтобы они учитывали специфику >4k-блоков флешатины вместо стандартных 512 байтных секторов HDD. Для этого на FreeBSD есть >провайдер GEOM Nop gnop(8), который подготавливает пространство SSD под использование >файловой системы, будь-то классическая ФС или же современная CoW-ФС. В Linux, наверное, об >этом не слышали, так как ФС там дюже умные и сами определяют, какой носитель они используют.

и этот комментарий заминусовали ? жесть, вообще обыдлела публика

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру