The OpenNET Project / Index page

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



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

Оглавление

Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS , opennews (??), 26-Июн-22, (0) [смотреть все]

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


1. "Применение асинхронной буферизированной записи на базе io_ur..."  +28 +/
Сообщение от Аноним (1), 26-Июн-22, 22:47 
Оказывается, если данные на диск не записывать, то "запись" будет быстрее. А что с надёжностью?
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

2. "Применение асинхронной буферизированной записи на базе io_ur..."  –4 +/
Сообщение от achtosluchilos (ok), 26-Июн-22, 22:47 
Ничего не понятно за счет чего получаются такие результаты. Автор новости пиши для орков, не для эльфов. Эльфы они в Шотландии.
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

3. "Применение асинхронной буферизированной записи на базе io_ur..."  +1 +/
Сообщение от Шарп (ok), 26-Июн-22, 22:48 
Лучше 12309 почините. Позавчера словил при копировании с одного ssd на другой. Сначала выдал скорость 1.7 гбайт/с, а потом комп повис.
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

11. "Применение асинхронной буферизированной записи на базе io_ur..."  +/
Сообщение от Dzen Python (ok), 26-Июн-22, 23:45 
90% просадок в скорости на ФС дают транзакции и журналирование записи - вообще все то, что делает durty bit если не бессмысленным, то всего лишь некритичным флагом для fsutil пройтись по журналу и поправить ссылки/создать список цепочек блоков в lost+found.

Интересно, а ребята тестировали только на грязной стабильной работе, без обработок внештатных ситуаций?

Мне вот интересно, как будут восстановлены данные из буфера при некорректном выключении (никак же, да, буфер не сохраняется? Т.е. детская болезнь времен ДОСа возвращается?)

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

20. "Применение асинхронной буферизированной записи на базе io_ur..."  +2 +/
Сообщение от Аноним (20), 27-Июн-22, 00:28 
Пояснительная бригада, теперь XFS лучшая ФС или еще нет?
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

52. "Применение асинхронной буферизированной записи на базе io_ur..."  +/
Сообщение от Аноним (52), 27-Июн-22, 09:17 
и сделало 80 каких-нить уязвимостей которые найдут через пять лет
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

61. "Применение асинхронной буферизированной записи на базе io_ur..."  –1 +/
Сообщение от Аноним (61), 27-Июн-22, 11:01 
Херасе они кэш изобрели!!! Срочная новость "Виндекапец близко"
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

72. "Применение асинхронной буферизированной записи на базе io_ur..."  +/
Сообщение от freehckemail (ok), 27-Июн-22, 13:15 
> Предварительные тесты производительности, проведённые при помощи инструментария fio (1 поток, размер блока 4кб, 600 секунд, последовательная запись), показывают увеличение числа операция ввода/вывода в секунду (IOPS) от 77k до 209k, скорости передачи данных от 314MB/s до 854MB/s и падения задержек от 9600ns до 120ns (80 раз).

Ну если это всё правда, то тогда надо сделать новые бенчмарки для сравнения с ext4. Если раньше ext4 отставала процентов на 5-8 в разных тестах, то с этими данными, вероятно, у нас появится новая дефолтная ФС.

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

83. "Применение асинхронной буферизированной записи на базе io_ur..."  +1 +/
Сообщение от Аноним (-), 27-Июн-22, 14:52 
А на чём проверяли? Cкорости которые описаны похожи на скорсти от NVMe.
Это рам диск ddr3 1333Hz два канала fat32 кластер 4Кб:

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x86 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    4KiB (Q=  8, T= 1):   166.137 MB/s [  40560.8 IOPS] <   170.89 us>
  SEQ    4KiB (Q=  1, T= 1):   195.756 MB/s [  47792.0 IOPS] <    18.46 us>
  RND    4KiB (Q= 32, T= 1):   161.623 MB/s [  39458.7 IOPS] <   783.15 us>
  RND    4KiB (Q=  1, T= 1):   191.221 MB/s [  46684.8 IOPS] <    18.45 us>

[Write]
  SEQ    4KiB (Q=  8, T= 1):   137.327 MB/s [  33527.1 IOPS] <   207.03 us>
  SEQ    4KiB (Q=  1, T= 1):   140.372 MB/s [  34270.5 IOPS] <    26.65 us>
  RND    4KiB (Q= 32, T= 1):   133.575 MB/s [  32611.1 IOPS] <   947.88 us>
  RND    4KiB (Q=  1, T= 1):   139.039 MB/s [  33945.1 IOPS] <    26.55 us>

Profile: Default
   Test: 1 GiB (x5) [Z: 0% (0/3019MiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec
   Date: 2022/06/27 9:11:42


То есть еслибы я мог в Linux создать рам диск как устройство NVMe и отфармотировать в xfs в Linux, и запустить тест KDiskMark (fio) то молучил с этим пачем прирост скорости в три раза? У меня сомнения что-то я не понемаю до конца. Нет информации на каком оборудовании получили прирост. А c остальными устройствами тоже прирост в три раза usb, hdd, DVD-R? DVD-R это сарказм.
------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x86 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  1851.487 MB/s [   1765.7 IOPS] <  3953.91 us>
  SEQ    1MiB (Q=  1, T= 1):  2041.897 MB/s [   1947.3 IOPS] <   504.95 us>
  RND    4KiB (Q= 32, T= 1):   161.623 MB/s [  39458.7 IOPS] <   783.15 us>
  RND    4KiB (Q=  1, T= 1):   191.221 MB/s [  46684.8 IOPS] <    18.45 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  1971.909 MB/s [   1880.6 IOPS] <  3700.51 us>
  SEQ    1MiB (Q=  1, T= 1):  1996.254 MB/s [   1903.8 IOPS] <   516.41 us>
  RND    4KiB (Q= 32, T= 1):   133.575 MB/s [  32611.1 IOPS] <   947.88 us>
  RND    4KiB (Q=  1, T= 1):   139.039 MB/s [  33945.1 IOPS] <    26.55 us>

Profile: Default
   Test: 1 GiB (x5) [Z: 0% (0/3019MiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec
   Date: 2022/06/27 9:24:56

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

88. "Применение асинхронной буферизированной записи на базе io_ur..."  +/
Сообщение от Аноним (93), 27-Июн-22, 15:32 
Я правильно понимаю, они sync-write делают async?
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

109. "Применение асинхронной буферизированной записи на базе io_ur..."  –3 +/
Сообщение от Аноним (109), 27-Июн-22, 18:49 
XFS же deprecated. Разве нет?
Ответить | Правка | Наверх | Cообщить модератору
есть ответы, показать

172. "Применение асинхронной буферизированной записи на базе io_ur..."  +3 +/
Сообщение от vitalif (ok), 29-Июн-22, 02:21 
Новость из серии "учёный изнасиловал журналиста".

Поддержка асинхронной буферизированной записи в io_uring для XFS уже была, и для ext4 уже была. Её для XFS просто ускорили - добавили "fast path".

99% приложений это ни холодно, ни жарко, ибо те, кто морочится об асинхронной записи, в основном работают без буферизации, с O_DIRECT, в частности, потому, что в linux aio асинхронная запись просто не работает без O_DIRECT - она превращается в синхронную. В io_uring вот работает, да, но кто ж его поддержал-то...

Кроме того, если пройти по ссылке на первоисточник, там видно, что и большой прирост в довольно специфическом кейсе...

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

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

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




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

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