> вот смотрите, у нас есть 10 дисков, raid 5. производительность массива на
> определяется в первую очередь сиками (seek), условно по 100 iops на диск.
> нам нужно прочитать мегабайт с диска.
> при чанке в 4мб это будет 1 сик (задействован один диск).
> при чанке в 64кб это будет 10 сиков (задействованы все диски).
> то есть в первом случае мы сможем держать (очень условно) на порядок больше клиентов.С чтением-то всё так. А вот для кучи мелких записей (особенно read-modify-write) это проблема.
> а по причинам проблемы: я подозреваю, что там правильно написано — «теряется»
> какой-то запрос к блочному устройству (все случаи воспроизведения были связаны с
> большой дисковой активностью).
> ext4 в тех же условиях просто работает (возможно, что-то и портит на диске, но я не замечал)
Как уже говорил выше, ext4 очень старательно кучу мелких записей пытается откладывать на последний момент (дабы в итоге сделать меньшую кучу и более крупных). В итоге этого обходного манёвра, вероятно, у глючного железа при этом так и не наступает такая ситуация, когда запрос дропается. Но и для ext* можно создать такую ситуацию, например, когда делается всё то же удаление/переименование кучи мелких (можно и не мелких) файлов, там уже его трюки не работают и он тоже похожим образом начнёт висеть/еле ползать. И это не единственное, в чём ext4 ведёт себя, гм, нехорошо.
XFS себе таких вольностей не позволяет (сказано писать мелкими кусками, будет писать мелкими кусками и синхронизировать после каждого, а то вдруг сейчас питание прервут или ещё какая война), так что нещадно фрагментируется в таких сценариях (один из самых болезненных его недостатков для меня, пожалуй) и, после какого-то момента тупит. Довольно сильно спасает использование fallocate, кстати говоря (хотя и не всегда, надеюсь, я что-нибудь на этот счёт всё-таки допилю).
