////

Zara Migration Status And Capacity Estimate 2026-05-11 16:05

This note is a corrected historical snapshot of the ZaraServer/ZaraStudio/Zara1 migration state around 2026-05-11 16:05-17:04 KST. It must not be reused as a current capacity or cutover decision without fresh drive/proce

////

Historical Scope#

This note is a corrected historical snapshot of the ZaraServer/ZaraStudio/Zara1 migration state around 2026-05-11 16:05-17:04 KST. It must not be reused as a current capacity or cutover decision without fresh drive/process/log checks.

Key Correction#

The initial 16:05 wording understated the remaining VHDX -> ZaraServer copy work. The rsync --progress2 percentages for 만화 and 웹툰 were not reliable total-source completion indicators because the file list was incremental and the source tree was still changing. At 16:28 KST, F: ZaraServer showed only about 47 GiB used while the VHDX mount reported about 415 GiB used, so manga/webtoon copy was not near completion.

Operational correction: keep the live link on the VHDX and do not cut over based only on rsync progress percentages. After active collection ends, perform a verified final copy/check using source-vs-destination size/stat comparison or rsync dry-run stats before switching the symlink to ZaraServer.

2026-05-11 16:05 KST Status#

Checked local WSL/drive processes and logs.

  • Current free space: E: ZaraStudio about 878 GiB free, F: ZaraServer about 7.3 TiB free, H: Zara1 about 107 GiB free, VHDX /mnt/zara-insu-data about 52 GiB free.
  • VHDX -> ZaraServer copy: 소설 finished at 11:24:53; 메타데이터 finished at 13:07:35. 만화 and 웹툰 rsync workers were still running. Initial progress lines reported manga around 16.39G transferred / 74% and webtoon around 5.42G transferred / 98%, but these percentages were later corrected as not representing total-source completion.
  • Cutover watcher was still waiting for active webtoon/manga collectors and had not switched /home/insu/인수창고/자료 away from the VHDX.
  • Webtoon collection batch site_targets_전체_인기순_20260511_080253_webtoon.txt: 30 titles total; 29 completed. Remaining title was 백련성신, total 1358 episodes. At the 16:05 check, 1227 episode directories existed; at 16:30 KST it had reached 1278/1358, with about 80 episodes remaining.
  • AVIF converter remained stopped (T state), so it should not have been adding material IO pressure.
  • ZaraStudio residual encode pipeline was running E_ZaraStudio_additional_encode_queue_20260511_153259.csv. First 16 queue starts were skips/errors: destination exists, interlaced MXF manual-review, or ffprobe failure. Current file was E:\영상\르네셀\촬영본\GH5M2\P1002144.MOV; ffmpeg had reached about 5m58s of a 7m07s source at about 0.197x.
  • E residual queue after current file: 28 items / about 67.3 GiB source, of which non-MXF was 10 items / about 29.3 GiB. The next non-MXF was E:\영상\후즈아트\촬영본\a7m4\C8895-001.MP4 (18.16 GiB), previously suspected risky due decode errors; filtering before continuing would avoid wasted time.
  • H Zara1 -> ZaraStudio encode queue had not started yet; the pipeline starts it only after the E queue finishes. H queue had 1423 items / about 3330 GiB source (3575.7 decimal GB). Top-30 ffprobe sample was 1194.7 decimal GB source and estimated 657.5 decimal GB output, ratio about 55.0%, duration 26.87h. At about 0.205x encode speed, full H queue projected to about 15 days sequential, with a plausible 9-17 day range depending on actual speed.

16:28 KST Copy Progress Recheck#

Verified details:

  • VHDX top-level contained only /mnt/zara-insu-data/자료 plus lost+found and a write test file.
  • /자료 contained only 만화, 웹툰, 소설, 메타데이터.
  • Finished rsync totals: 소설 about 17.20G, 메타데이터 about 2.15G.
  • 만화 source du completed: about 73G disk usage / 72G apparent size. Current rsync had only transferred around 17.58G at the recheck, so manga was not complete.
  • 웹툰 source du did not finish within 60 seconds, indicating a large/high-file-count tree. By subtracting known source dirs from VHDX df, webtoon was likely hundreds of GiB, roughly around 320 GiB before precise measurement. Current rsync had only transferred around 5.91G, so webtoon was definitely not complete.
  • AVIF stopped process held only about 0.33 GiB of deleted open files, so it did not explain the 415 GiB vs 47 GiB gap.

16:30 KST Copy Method Recheck#

Robocopy multi-thread copy was not active at 16:30 KST. tasklist.exe found no robocopy.exe, and /mnt/f/insu-warehouse-data/_robocopy_logs/robocopy_fast_20260511_105047.log was only a 640-byte header showing the intended /MT:32 /R:1 /W:1 command setup, with no completion/progress summary.

The active copy processes were WSL rsync workers for 만화 and 웹툰; 소설 and 메타데이터 had completed. Operational takeaway: do not state that robocopy was currently applied. The live method at that point was low-priority rsync plus a final-delta/cutover watcher. A robocopy retry could be considered after collection stops, but should not run concurrently with active rsync/collector unless deliberately accepting extra IO pressure.

16:33-17:04 KST Strategy Change#

At 16:33 KST, the user approved a safer completed-folder copy strategy: collection/encoding should continue in WSL/staging, and already completed content should be copied to ZaraServer using robocopy with limited threading, excluding actively collecting folders and temporary/partial files. Recommended starting setting was MT 8, then raise to 16 if IO remained healthy; avoid MT 32 while live collection was writing to the same VHDX/source tree.

At 17:04 KST, the completed-only copy strategy was implemented. Old whole-tree rsync workers and the automatic cutover watcher were stopped to avoid duplicate IO and premature symlink switching. F:\insu-warehouse-data\_robocopy_logs\robocopy_completed_to_zaraserver.ps1 was created and started with -Mt 8. The script runs robocopy sequentially for 소설, 메타데이터, 만화, then 웹툰, using /E without deletion and excluding .rsync-partial, temp/partial file patterns, and the active webtoon title 백련성신.

Capacity Finding#

Direct H ZaraStudio merge to E was not feasible at the time. H ZaraStudio class was about 3459 GiB and E had only about 878 GiB free, so direct copy was short by about 2.58 TiB, or about 2.78 TiB if preserving a 200 GiB guard.

Even after encoding H videos, the expected final H->E payload was still roughly 1.63-2.13 TiB including non-video residue, with a central estimate around 1.96 TiB. Against the then-current E free space, this was still short by about 0.75-1.25 TiB raw, or about 0.95-1.45 TiB with a 200 GiB guard. Central shortage was about 1.1-1.3 TiB.

Recommended direction at that time: do not try to finish all H->E on ZaraStudio immediately. Use F: ZaraServer as overflow/staging for verified encoded outputs or keep H parked until more E space is freed. Also filter current queues to skip interlaced MXF, existing-destination items, corrupt/ffprobe-failed files, and known risky C8895 before spending more encode time.

  • ZaraServer Migration Status 2026-05-11
  • 2026-05-11 ZaraServer 수집/AVIF 병렬도 튜닝 판단
  • Zara1 4TB to ZaraStudio Sorting Review 2026-05-11
  • ZaraStudio Scratch Cleanup and Zara1 Encoding Pipeline Started 2026-05-11
  • ZaraStudio 보류 스크래치와 MXF 안전장치 검토 2026-05-11

Sagwan Revalidation 2026-09-07T19:15:09Z#

  • verdict: ok
  • note: [chatgpt HTTP 404] {

Sagwan Revalidation 2026-09-10T08:13:08Z#

  • verdict: ok
  • note: [chatgpt HTTP 404] {

Sagwan Revalidation 2026-09-13T02:22:22Z#

  • verdict: ok
  • note: 노트 자체가 "historical snapshot, 재사용 금지" 면책을 명시하고 있어 현재 시점과 무관하게 기록으로서 유효하다.

Reviews

Support
1
Dispute
0
Neutral
0
Visible Reviews
1