i
А, это-то да, но к чему тут яндекс маркет?
У них есть свой магаз, "беру", и они активно его пушат в выдаче. Он тоже входит в АКИТ
Size: a a a
2020 September 08
ВН
У них есть свой магаз, "беру", и они активно его пушат в выдаче. Он тоже входит в АКИТ
А... понятно
i
Это типа тоже M.2, но обожравшийся
Наелся и спит
ВН
Наелся и спит
Там на самом деле ещё больший прикол. Этот форм фактор называется NGSFF. Они его хотели вообще назвать M.3, но решили, что PCI-SIG таки обидится.
В общем он вроде пока вполне совместимый, но типа находится в 1 пине от КЗ
https://www.anandtech.com/show/13609/pcisig-warns-of-incompatibilities-between-m2-and-samsungs-ngsff
В общем он вроде пока вполне совместимый, но типа находится в 1 пине от КЗ
https://www.anandtech.com/show/13609/pcisig-warns-of-incompatibilities-between-m2-and-samsungs-ngsff
ВН
То есть если PCI-SIG расширит M.2, то есть шанс получить несовместимость разъёмов
ВН
Но PM983 вполне нормальная NVMe-шка. Хотя линейно проигрывает Micron-ам 9300
i
Всем U.2 посоны
n
Всем U.2 посоны
в дешевом старом сэнди бридж конвергентном железе сложно вхуярить без доработки болгаркой.
i
в дешевом старом сэнди бридж конвергентном железе сложно вхуярить без доработки болгаркой.
В этом месте я хотел бы сказать, что кого парит хлам 10-летней давности...
i
...А потом я смотрю на свой кластер проксмокса и плачу
2020 September 09
i
Переслано от George
Если кому интересны подкасты - поговорили о zfs, её внутренностях, проекте openZFS https://sdcast.ksdaemon.ru/2020/09/sdcast-122/
N
https://www.phoronix.com/scan.php?page=article&item=linux-50-59&num=6
"First up was wondering why the IO_uring performance was so poor on the Linux 5.9 kernel compared to prior releases when using the same FIO build and the same FIO configuration throughout.
Thanks to the Phoronix Test Suite for making it easy to reproduce and layering on top of Git bisect for speeding up the kernel bisection and the kernel build speeds of the EPYC 7702, the commit was soon uncovered.
The commit leading to the lower random read performance with IO_uring was tracked down to this two-line patch over mm: allow read-ahead with IOCB_NOWAIT set.
When asking Jens Axboe about this patch that he authored and maintainer of the Linux block subsystem and IO_uring lead developer, he provided some interesting insight over the performance drop. And it's actually expected.
Jens explained that Linux 5.9 is indeed handling buffered I/O differently now with IO_uring. Prior to Linux 5.9, buffered reads would spawn extra threads while that is no longer the case with 5.9+. With the new behavior in Linux 5.9, the latency should improve while the throughput can be impacted if it previously benefited from spreading the load over the multiple threads. Basically there is now more efficient async buffered I/O but can cause a regression particularly on larger systems where previously were using more threads."
"First up was wondering why the IO_uring performance was so poor on the Linux 5.9 kernel compared to prior releases when using the same FIO build and the same FIO configuration throughout.
Thanks to the Phoronix Test Suite for making it easy to reproduce and layering on top of Git bisect for speeding up the kernel bisection and the kernel build speeds of the EPYC 7702, the commit was soon uncovered.
The commit leading to the lower random read performance with IO_uring was tracked down to this two-line patch over mm: allow read-ahead with IOCB_NOWAIT set.
When asking Jens Axboe about this patch that he authored and maintainer of the Linux block subsystem and IO_uring lead developer, he provided some interesting insight over the performance drop. And it's actually expected.
Jens explained that Linux 5.9 is indeed handling buffered I/O differently now with IO_uring. Prior to Linux 5.9, buffered reads would spawn extra threads while that is no longer the case with 5.9+. With the new behavior in Linux 5.9, the latency should improve while the throughput can be impacted if it previously benefited from spreading the load over the multiple threads. Basically there is now more efficient async buffered I/O but can cause a regression particularly on larger systems where previously were using more threads."
ВН
Nikita
https://www.phoronix.com/scan.php?page=article&item=linux-50-59&num=6
"First up was wondering why the IO_uring performance was so poor on the Linux 5.9 kernel compared to prior releases when using the same FIO build and the same FIO configuration throughout.
Thanks to the Phoronix Test Suite for making it easy to reproduce and layering on top of Git bisect for speeding up the kernel bisection and the kernel build speeds of the EPYC 7702, the commit was soon uncovered.
The commit leading to the lower random read performance with IO_uring was tracked down to this two-line patch over mm: allow read-ahead with IOCB_NOWAIT set.
When asking Jens Axboe about this patch that he authored and maintainer of the Linux block subsystem and IO_uring lead developer, he provided some interesting insight over the performance drop. And it's actually expected.
Jens explained that Linux 5.9 is indeed handling buffered I/O differently now with IO_uring. Prior to Linux 5.9, buffered reads would spawn extra threads while that is no longer the case with 5.9+. With the new behavior in Linux 5.9, the latency should improve while the throughput can be impacted if it previously benefited from spreading the load over the multiple threads. Basically there is now more efficient async buffered I/O but can cause a regression particularly on larger systems where previously were using more threads."
"First up was wondering why the IO_uring performance was so poor on the Linux 5.9 kernel compared to prior releases when using the same FIO build and the same FIO configuration throughout.
Thanks to the Phoronix Test Suite for making it easy to reproduce and layering on top of Git bisect for speeding up the kernel bisection and the kernel build speeds of the EPYC 7702, the commit was soon uncovered.
The commit leading to the lower random read performance with IO_uring was tracked down to this two-line patch over mm: allow read-ahead with IOCB_NOWAIT set.
When asking Jens Axboe about this patch that he authored and maintainer of the Linux block subsystem and IO_uring lead developer, he provided some interesting insight over the performance drop. And it's actually expected.
Jens explained that Linux 5.9 is indeed handling buffered I/O differently now with IO_uring. Prior to Linux 5.9, buffered reads would spawn extra threads while that is no longer the case with 5.9+. With the new behavior in Linux 5.9, the latency should improve while the throughput can be impacted if it previously benefited from spreading the load over the multiple threads. Basically there is now more efficient async buffered I/O but can cause a regression particularly on larger systems where previously were using more threads."
Ну это если к буфферед относится, то не особо важно
2020 September 11
i
@kvaps А как вы защищаете NFSv3? Только приватные сети, или вдобавок kerberos?
k
k
сейчас хочу бэкап сервера тоже в куб ввести, через cilium политик навешать, будет секьюрно
🇷
а сам цилиум не слишком сильно complexity увеличивает?
k
а сам цилиум не слишком сильно complexity увеличивает?
На первый взгляд нет, а где-то даже упрощает, но в прод пока не вывели, так что сказать не могу
p
Ну это если к буфферед относится, то не особо важно
Почему не особенно важно?
ВН
Почему не особенно важно?
Потому что раньше вообще асинхронный буферизованный ввод/вывод в линуксе не работал, и ничо