Оптимизация скорости бэкапов средствами файловой системы (read ahead, опережающее чтение)

[@ComodoHacker]

Хороший материал, но не хватает примеров и наглядности.
(Еще не поздно добавить)

[@1099511627776]

Поддерживаю. Может немного примерчиков для разных ОС с графиками было бы идеально

[@Harkonnen]

Хочу график для SMARTDRV.EXE

[@kachini]

добавил пример

[@kachini]

Тут больше зависимости от дисковой подсистемы, чем от операционки. VxFS на разных операционках примерно одинаковый. Различия могут быть вызваны архитектурой файлового кеша, где хранятся данные read ahead и ограничениями стека ввода-вывода (например на количество параллельных IO).

Больше всего конечно влияет дисковая подсистема и пропускная способность SAN.

ps. smartdrv.exe, вроде как, просто кеш был. равно как и ptscache.sys

[@Sov1et]

Сущесвет ли подобное для более «часых» файловых систем (XFS, ext3/4)?

[@Harkonnen]

У меня другой вопрос — существует ли в современном мире файловая система, где этого нет.

[@kachini]

я просто с ними не работаю, поэтому не знаю. Однажды возился с ext4 но недостаточно, чтобы рассказать.

[@ekungurov]

Насколько я понимаю, это функция ядра, а не [драйвера] файловой системы. В линуксе смотреть и управлять кешем можно с помощью команды blockdev. Пример с VxFS — это какой-то частный случай.

[@g0ff]

А что же Вы не привели реальных цифр с разницей до\после?

[@kachini]

привел

[@g0ff]

отлично! спасибо.

[@Superblaze]

Интересно ещё увидеть зависимость от типа массивов. Примерно на практике мы с ней сталкиваемся, но коэффициенты и зависимости красивей смотрятся на графиках. И ещё на блюдечке с голубой каёмочкой. :-)

[@0Lexx0]

Мда… Статья недоделана. Где конкретные команды для vxtunefs? Где хоть какое-то сравнение производительности до и после оптимизации? Где хоть какой-то пример из жизни?
Фразы вроде «Иначе, последствия могут быть непредсказуемыми» сразу говорят о том, что вы ниразу не пробовали отойти от мануалов. Очень похоже, что это просто краткая выдержка из официального гайда по тюнингу VxFS.
По поводу использования SAN — скорость скорее всего в него и упрется. Когда на предыдущем месте работы мы настраивали бекапы на ленточки и на евы — приходилось мучатся с мультипасингом — руками сносить лишние пути, тк они только мешали.

[@kachini]

Вы правы, я не люблю отходить от мануалов. По мне, буквальное следование мануалам — главный секрет успеха в этой профессии. По поводу непредсказуемых последствий, да, вплоть до kernel panic. Поэтом и пишу. Обычно, паники очень непредсказуемы. Кроме того, если буфера в файловом кеше имеют размер страницы памяти (например 4kb), логично читать блоком с кратным 4kb?

Основная проблема многих бэкапов — однопоточность. Если распараллелить на уровне приклада нельзя, то read ahead один из возможных путей. Он позволяет нескольким IO отправляться в массив почти параллельно. Понятно что может упираться в SAN, порт на массиве, число шпинделей, scsi queue, итд.

[@0Lexx0]

Спасибо за ответ и спасибо за реальные данные. Если бы вы еще на тестовой среде поставили read_pref_io отличный от степени двойки и пояснили для все, почему же оно не может быть например
65536 + 32768, то вашей статье цены бы не было.