The OpenNET Project / Index page

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



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

Оглавление

Раздел полезных советов: Оптимизация использования SSD-накоп..., auto_tips (?), 31-Авг-12, (0) [смотреть все]

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


7. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от iZEN (ok), 01-Сен-12, 12:59 
Для ZFS TRIM не важна, так как в ZFS можно сделать настройку размера базового блока под размер сектора SSD (512k). И тогда не будет лишних очищений и перезаписываний страниц SSD.
Ответить | Правка | Наверх | Cообщить модератору

10. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от pavlinux (ok), 02-Сен-12, 04:31 
> под размер сектора SSD (512k).

У SSD нет секторов, головок и даже цилиндров :)

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

16. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok), 02-Сен-12, 17:51 
>> под размер сектора SSD (512k).
> У SSD нет секторов, головок и даже цилиндров :)

Да вообще их и у винтов нет. Уже лет дцать как LBA. К слову, геометрически сектор -
это часть круга (!), ограниченная дугой и двумя радиусами. Так что сектор для ХДД никогда не был математически верным термином.
Кому надо, те понимают, что "сектор" SSD - это блок. :)

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

18. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от pavlinux (ok), 02-Сен-12, 18:36 
> Кому надо, те понимают, что "сектор" SSD - это блок. :)

Блок был одним из немногих деятелей искусства Петрограда,
кто не просто принял советскую власть, но согласился
работать на её пользу. Власть широко начала использовать
имя поэта в своих целях.  Ужоснах =-о

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

12. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим (?), 02-Сен-12, 13:00 
брехня же
http://ru.wikipedia.org/wiki/TRIM
>TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных больше не используются и могут быть использованы накопителем для подготовки к записи.

а правда в том, что (см. там же):
>Linux 2.6.33     Поддерживается с февраля 2010[17]
>OpenSolaris     Поддерживается с июля 2010[18]
>FreeBSD 8.3 & 9.0     Поддерживается с UFS[19], не поддерживается с ZFS[20].

и ещё немного правды
https://forums.oracle.com/forums/thread.jspa?threadID=214362...
>Re: SSD trim support and Oracle Solaris Express 11
>Posted: 25.11.2011 5:14
>Hello,
>do you know whether 'SSD trim' is supported and used on the final Solaris 11/ZFS build?
>Thanks
>Posted: 15.01.2012 20:57
>Hi Community,
>I opened an SR to ask Oracle about this. The answer: CR 6913905 covers this request and is integrated into Solaris 11 SRU 5, planned for the end of March 2012.
>Hope that helps

вот и всё. для сравнение в другой COW-fs:
https://btrfs.wiki.kernel.org/index.php/Mount_options
>ssd
>Turn on some of the SSD optimized behaviour within btrfs. This is enabled automatically by checking /sys/block/sdX/queue/rotational to be zero. This does not enables discard/TRIM !

.

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

15. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok), 02-Сен-12, 17:47 
Таки в чём iZEN не прав? В том, что блок SSD "сектором" обозвал?
Если SSD-блок равен блоку ФС, то TRIM не требуется, тк он нужен только для отметки о неиспользуемости блока SSD. Что, логично, бесполезно, если блок SSD равен блоку ФС.
Ответить | Правка | Наверх | Cообщить модератору

20. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от ананим (?), 02-Сен-12, 21:08 
для дЭбилов даю ещё раз ссылку https://www.opennet.ru/openforum/vsluhforumID3/86249.html#12
Ответить | Правка | Наверх | Cообщить модератору

62. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от terr0rist (ok), 08-Сен-12, 01:41 
> для дЭбилов даю ещё раз ссылку https://www.opennet.ru/openforum/vsluhforumID3/86249.html#12

сам-то читал по этой ссылке?
Цитата
"TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных больше не используются и могут быть использованы накопителем для подготовки к записи."
"блоки (обычно 128 страниц или 512 Кбайт суммарно)"
"В SSD накопителях операция записи может быть проделана только для страниц, однако из-за аппаратных ограничений команда удаления всегда выполняется на весь блок"

вывод сделать за тебя или ещё раз мой пост перечитаешь? ананим такой ананим

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

65. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от абырemail (?), 10-Сен-12, 11:11 
Печальный вывод состоит в том что вы читать не умеете.
Попробуйте еще раз.
Ответить | Правка | Наверх | Cообщить модератору

27. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от iZEN (ok), 03-Сен-12, 16:32 
> Если SSD-блок равен блоку ФС, то TRIM не требуется, тк он нужен
> только для отметки о неиспользуемости блока SSD. Что, логично, бесполезно, если
> блок SSD равен блоку ФС.

В SSD операции перезаписи происходят только с целым блоком (512k). TRIM отмечает СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке. При очистке неиспользуемых страниц перезаписывается целый блок, который их содержит. Если блок SSD по размеру совпадает с блоком ФС, то TRIM — лишняя операция, так как ФС и так его перезапишет целиком. А когда размер блока ФС меньше размера блока SSD, то команда TRIM необходима для подготовки свободного пространства для размещения блоков ФС внутри блока SSD — без этого количество свободных блоков SSD при каждой записи данных будет уменьшаться — что мы и наблюдаем в реальности, когда классическая линуксовая ФС не поддерживает TRIM.


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

28. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим (?), 03-Сен-12, 22:45 
>TRIM отмечает СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке.

TRIM ничего не отмечает.
TRIM - это команда, посылаемая (кстати АТА/САТА и этк. в SCSI/SAS/FC не иеет смысла) ОС системе ввода-вывода, что "де эти блоки грязные".
А поскольку АТА - тупой бай дезиггн, то бывало что всё помечалось как удалённое.
и да, всё это происходит до сброса кэша на диск.

в любом случае от размера блока не зависит. хоть 512, хоть 4к. (просто выдаст что очищено 4, а не 1)

зыж
когда сани говорили, что отлично работают с ссд, то не врали.
НО! эти ссд не те что в магазине продаются, а сас по 4-е нуля килобаксов минимум.
ну а с АТА см. выше привёл.

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

63. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok), 08-Сен-12, 01:42 
>[оверквотинг удален]
> В SSD операции перезаписи происходят только с целым блоком (512k). TRIM отмечает
> СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке.
> При очистке неиспользуемых страниц перезаписывается целый блок, который их содержит. Если
> блок SSD по размеру совпадает с блоком ФС, то TRIM —
> лишняя операция, так как ФС и так его перезапишет целиком. А
> когда размер блока ФС меньше размера блока SSD, то команда TRIM
> необходима для подготовки свободного пространства для размещения блоков ФС внутри блока
> SSD — без этого количество свободных блоков SSD при каждой записи
> данных будет уменьшаться — что мы и наблюдаем в реальности, когда
> классическая линуксовая ФС не поддерживает TRIM.

я об этом и сказал.

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

24. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от kurokaze (ok), 03-Сен-12, 07:36 
> Для ZFS TRIM не важна, так как в ZFS можно сделать настройку
> размера базового блока под размер сектора SSD (512k). И тогда не
> будет лишних очищений и перезаписываний страниц SSD.

Лол! Ты даже не знаешь зачем нужен TRIM

In computing, a TRIM command allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.

Я конечно понимаю что дело в том что:
Operating system support
Linux-kernel: 2.6.28 - 25 December 2008
FreeBSD: 8.1 - July 2010

Но тщательнее надо быть, тщательнее (с)

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

43. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagualemail (ok), 04-Сен-12, 17:31 
> Для ZFS TRIM не важна, так как в ZFS можно сделать настройку
> размера базового блока под размер сектора SSD (512k). И тогда не
> будет лишних очищений и перезаписываний страниц SSD.

Для ZFS TRIM не важна потому что учитывая стстистику отказов SSD ниодин здравомыслящий админ не станет хранить на SSD что то кроме кешируемых данных, а потому на SSD ZFS как в бане лыжи там и UFS сойдет и даже без +S +J ...

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

49. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Andrew Kolchoogin (?), 05-Сен-12, 01:55 
Ты перепутамши.

По умолчанию размер блока файловой системы влияет на поведение только файловой системы. Но она может вести себя "более лучше" (C) Света из Иваново, если знает, каков размер блока underlying direct access storage device (DASD далее для краткости).

Размер блока HDD равен 512 байтам. Лет тридцать назад, во времена MFM, размер блока HDD был равен размеру одного физического сектора -- теперь это, конечно, не так, ибо RLL'и и прочие методы оптимизации свели понятие сектора на "нет", но для магнитных накопителей это не так уж и важно.

А вот с SSD засада -- во-первых, они могут перезаписывать данные только в чистые блоки, которые для NAND равны 4К. Соответственно, для неухудшения параметров дисковой подсистемы был придуман костыль в виде TRIM, а позже -- поддержка операционками DASD'ов с размером в 4K.

Но это не вся засада. Некоторые NAND не умеют даже поблочной перезаписи -- только постраничную, а она, как известно, 512K размером. И вот тут уже всё плохо -- насколько мне известно, современных операционных систем, поддерживающих DASD'ы с блоком в полмегабайта, не существует -- то есть, либо TRIM, либо специальный тюнинг ZFS -- нужно сделать так, чтобы ZPool начинался на границе 512K (как частный случай -- занимал весь SSD), и размер его блока был тоже 512K, тогда операции на таком ZPool'е с эффективностью будут соответствовать TRIM'у.

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

50. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagualemail (ok), 05-Сен-12, 11:06 
>[оверквотинг удален]
> параметров дисковой подсистемы был придуман костыль в виде TRIM, а позже
> -- поддержка операционками DASD'ов с размером в 4K.
> Но это не вся засада. Некоторые NAND не умеют даже поблочной перезаписи
> -- только постраничную, а она, как известно, 512K размером. И вот
> тут уже всё плохо -- насколько мне известно, современных операционных систем,
> поддерживающих DASD'ы с блоком в полмегабайта, не существует -- то есть,
> либо TRIM, либо специальный тюнинг ZFS -- нужно сделать так, чтобы
> ZPool начинался на границе 512K (как частный случай -- занимал весь
> SSD), и размер его блока был тоже 512K, тогда операции на
> таком ZPool'е с эффективностью будут соответствовать TRIM'у.

А есть примеры?

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

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

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




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

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