20. Кеш: чому хмара використовує мій SSD?¶

Work in progress

Відкрили кілька кліпів із хмарного тому — а вільного місця на ноутбуці поменшало. Невже StudioFS вирішив завантажити весь архів? Ні: він залишає поруч дані, з якими ви працюєте, щоб не ходити до S3 по кожен наступний шматок відео. Хмара далеко, а монтажна програма чекати не любить.

Але слово «кеш» тут трохи підступне. На локальному диску є не лише копії вже опублікованих даних. Там також можуть лежати нові зміни, які ще не потрапили до хмари. Тому цю папку не можна сприймати як звичайні тимчасові файли.

Що залишається на комп’ютері¶

Під час читання StudioFS отримує потрібні дані зі сховища й кешує їх локально. Повторне відкриття вже прочитаних матеріалів зазвичай потребує менше мережевих звернень. Якщо потрібні дані вже є в кеші, StudioFS не завантажуватиме їх повторно.

Під час запису зміни спочатку стають доступними на вашому комп’ютері. Далі фонові процеси завантажують вміст до S3 і передають спільні метадані через PostgreSQL.

Корисно розрізняти два стани локальних даних:

Dirty — локально змінені дані, які ще потребують публікації. Це може бути єдина збережена копія вашої нової роботи. StudioFS захищає їх від звичайного витіснення з кешу.
Evictable — дані, які механізм кешу вже може витіснити, коли потрібне місце. Під час наступного звернення їх можна знову отримати зі сховища.

Не кожен байт, який уже перестав бути dirty, негайно стає evictable: дані можуть ще використовуватися поточною операцією. А кеш прочитаного не є обіцянкою доступності без мережі — його вміст може змінюватися. Не покладайтеся на нього як на гарантовану автономну копію проєкту.

Де це все лежить¶

Для кожного тому StudioFS створює окремий каталог за його UUID усередині базового каталогу кешу. Якщо --cache-dir не задано й немає збереженого налаштування, використовується cache у локальному каталозі метаданих тому.

Усередині каталогу тому є payload/objects із локальним вмістом, upload/objects для підготовки завантажень, index/cache.redb з індексом і tmp для тимчасових операцій. Локальні метадані зберігаються окремо. Усе це — пов’язаний робочий стан, а не набір незалежних файлів для прибирання вручну.

Для кешу обирайте швидкий локальний NVMe SSD із достатнім запасом місця та файловою системою, рекомендованою для вашої ОС: NTFS у Windows, APFS у macOS або ext4 у Linux. Не використовуйте exFAT.

Ось приклад параметрів наступного монтування на Linux:

studiofs mount studio /mnt/studio --cache-dir /srv/studiofs-cache --cache-size 50GB

Тут studio — назва прикладного тому, а обидва шляхи потрібно замінити своїми. У Windows шлях кешу може виглядати як D:\StudioFS-cache, у macOS — як /Users/yourname/StudioFS-cache.

Зберегти ці параметри як типові для StudioFS можна командою:

studiofs settings --cache-dir /srv/studiofs-cache --cache-size 50GB

Явні параметри mount мають перевагу над збереженими. settings не переналаштовує вже запущене монтування. Зміна шляху не переносить старі дані: якщо є неопубліковані зміни, не перемикайтеся на порожній каталог у надії, що StudioFS знайде їх сам. Спершу завершіть роботу програм, дочекайтеся публікації та штатно відмонтуйте том; перенесення робочого стану узгодьте з адміністратором.

Розмір кешу — не розмір тому¶

--cache-size задає бюджет дискового кешу. За відсутності явного або збереженого значення використовується 100GB. Це не означає, що StudioFS одразу займе весь цей простір або що хмарний том не може бути більшим.

Також це не гарантія граничного розміру всього локального каталогу. Індекс, метадані, тимчасова робота та підготовка завантажень теж потребують місця. Захищені дані не можна просто викинути заради красивого числа в налаштуваннях. Якщо звільнити достатньо місця неможливо, записи можуть сповільнюватися або завершуватися помилкою через брак місткості.

Для зазначення розмірів використовуйте суфікси B, KB, MB, GB, TB, PB, EB. У StudioFS вони двійкові: 1KB = 1024B, 1GB = 1024 × 1024 × 1024B. Наприклад, 50GB і 1.5GB — коректні значення; дробову частину байта парсер відкидає. Записуйте саме GB, а не GiB чи просто G: ці варіанти суфіксів CLI не підтримує.

Не виділяйте для кешу весь вільний простір SSD. Залишайте запас для найбільшого запланованого запису й роботи решти системи. Якщо ви записуєте швидше, ніж канал встигає передавати дані до S3, черга й локальні дані накопичуватимуться навіть за справного з’єднання. За замовчуванням StudioFS намагається залишати вільними 10 % місця на диску, де розташовано каталог кешу.

Якщо SSD майже заповнився¶

Призупиніть великі нові записи й експорти на цей диск. Перевірте вільне місце, правильність шляху кешу, Dirty bytes і Pending uploads. Якщо черга росте або не зменшується, перевірте доступ до S3; проблеми зі спільними метаданими окремо шукайте в доступі до PostgreSQL і діагностиці синхронізації.

Дайте фоновій роботі завершитися. Для негайного запасу можна звільнити місце поза робочими каталогами StudioFS, наприклад прибрати вже непотрібні власні експорти. Сам кеш, його індекс, підготовлені завантаження та локальні метадані вручну не видаляйте. Зменшення --cache-size теж не робить неопубліковані дані безпечними для видалення.

Перед наступним запуском перевірте розмір кешу й розташування його каталогу. Якщо після збою залишилися неопубліковані дані, не змінюйте каталог кешу: локальні дані та метадані з нього потрібні для відновлення. Байти, які до збою залишалися лише в пам’яті процесу, такої гарантії не мають.

Кеш потрібен, щоб прискорити роботу. Найбезпечніше ставитися до нього як до робочого столу: там є і копії довідкових матеріалів, і чернетка, яку ви ще нікому не передали.

Зміст · English · ← Попередня · Наступна →