Делаю периодическое тестирование восстановления бэкапов, и обратил внимание что медленно происходит восстановление, в части создания чанков перед началом восстановления. Весь процесс начинается так:
1. после команды начать физ.восстановление информикс создает на диске на файловой системы файлы (чанки) необходимого размера (не пишет в них данные а именно создает файлы конкретного объема)
2. после создания файлов он начинает непосредственно процесс восстановления данных в эти файлы - пишет в них из бэкапа

Для файлов (чанков) размером в 25 Gb на создание (не восстановление данных!) каждого файла уходит примерно по 10 мин, а чанков таких много. Как ускорить выделение места под файлы на файловой системе?
raw device не использую.

ОС AIX, файловая система смонтирована с concurrent IO, включен журнал (мб тут затык?), по умолчанию используется group commit
Informix 11.50.FC8, включен DIRECT_IO = 2

Внесу уточнение: чанки (файлы) на ФС я создаю вручную с помощью touch. Информикс после запуска команды на физ. восстановление увеличивает файлы до необходимого объема, и только после этого начинает писать в них из бэкапа данные, это видно с помощью onstat -D (пока файлы расширяются в выводе onstat -D для поля "page Wr" нули для этих чанков). После того как все чанки увеличены до необходимого размера, начинается непосредственно процесс физ.восстановления, это опять таки видно в поле "page Wr".

Конечно оставлять файлы можно, но проблема в том что тестируются бэкапы с разных серверов, размера ФС не хватает, поэтому файлы приходится удалять после тестирования. Но я кое что нашел, называется это "sparse files" , кажется это то что надо:

A sparse file is a file with empty space, or gaps, left open for future addition of data. If the empty spaces are filled with the ASCII null character and the spaces are large enough, the file will be sparse, and disk blocks will not be allocated to it.

Ура ! Получилось использовать sparse files, т.е. теперь процесс восстановления не ждет, пока файлы создадутся, а начинает восстановление сразу. Конечно аллокация блоков на ФС происходит в процессе восстановления, но все равно сессия в storage manager не висит в ожидании, как это происходит при восстановлении в обычный файл.

АнатоЛой,

Насчет общего времени восстановления: общее время восстановления при использовании sparse files не увеличилось. Т.е. стало даже немного быстрее.
Что касается ожидания сессии в Storage Manager (у меня TSM), я не знаю всех нюансов работы TSM, но предполагаю что не есть гуд когда TSM готов отдавать данные Информиксу, а в это время идет обычное создание файлов и сессия в TSM банально висит, занимая ресурсы (дисковый пул например). Указанный способ позволяет начать восстановление сразу, не ожидая полного создания файлов на диске.

Журавлев Денис,

В контексте данного топика общее время восстановления = время создания файлов + время физ.восстановления данных в них

Подводя итоги
- если создаем файлы нулевого размера, сессия восстановления ждет, пока они не будут расширены до нужного объема, и только потом начинается восстановление. Минусы: блокируются некоторые ресурсы на TSM сервере на время увеличения файлов, админ TSM тоже иногда нервничает, что сессия на TSM что-то висит и ничего не передает :)
- если создаем sparse files, плюсы: восстановление начинается сразу, нет ожиданий на TSM сервере. Минусы: надо вручную указывать сколько блоков выделять для такого файла.
Общее время восстановления в обоих случаях примерно одинаковое.