| Предыдущий | Следующий |
| STATUS_LOG_STATE_INVALID | STATUS_LOG_METADATA_FLUSH_FAILED |
STATUS_LOG_PINNED
STATUS_LOG_PINNED объясняет, почему физический журнал не может повторно использовать пространство, даже когда старые записи кажутся приложению ненужными. Поток может закреплять свой хвост, а в мультиплексированном журнале один поток, не продвигающий хвост, со временем препятствует повторному использованию контейнеров всеми потоками.
Это не повод для принудительного удаления. Закрепление представляет активное требование хранения: неархивированную историю, хвост клиента или другой защищённый экстент. Восстановление должно определить это требование, а не обходить его прямыми изменениями контейнеров.
Что проверить
- Соберите base, tail и archive-tail LSN для всех значимых потоков и определите клиента, удерживающего самый старый экстент.
- Определите, требуется ли завершение архивации, callback хвоста управляемого клиента или выполнение обязательства восстановления приложения до освобождения места.
- Отличайте общее закрепление от
STATUS_LOG_PINNED_RESERVATION, где давление явно связано с зарезервированными записями.
Ссылки
- Microsoft: ClfsMgmtHandleLogFileFull и обработка полного журнала
- Microsoft: контейнеры CLFS, закрепление хвоста и управляемые клиенты
- Microsoft: API контейнеров, резервирования, добавления и flush
- Wine: независимые определения NTSTATUS
Нужно найти другой код? Найти другой код состояния или ошибки.