Synology'den UniFi UNAS Pro 8'e geçiş, NTFS veri akışları ve Robocopy'nin /Z parametresi yüzünden sekteye uğradı

Rutin bir NAS değişimi debugging seansına dönüşüyor

Hacker News'in ana sayfasında öne çıkan bir yazıda blogunda kaleme alan Scott Hanselman, uzun süredir hizmet veren bir Synology NAS'taki paylaşımları, yeni yükseltilmiş 10 gigabitlik dahili ağ üzerinden bir Ubiquiti UniFi UNAS Pro 8'e taşüdı. Her iki uç da SMB konuşuyor ve Windows onlarca yıldır güvenilir dosya kopyalama araçları sunuyor; bu yüzden sıkıcı bir akşam bekliyordu. Öyle olmadı.

Explorer ile başladı; Explorer, dosyalarda tek tek "İstenen işlem bir dosya sistemi sınırlaması nedeniyle tamamlanamadı" mesajıyla başarısız oldu. Başarısız olanlardan biri, son derece sıradan 05 Wires.m4p adlı bir parçaydı. Daha iyi tanılama için Robocopy'ye geçince, aynı dosya her denemede tam olarak yüzde 92'de öldü ve Windows 655 hatası bildirdi. Not: hata kodu 665'ti.

Hatayı izole etmek

Hanselman, dosya adlarındaki noktalama işaretlerini suçlamak yerine yolu ikiye bölerek ilerledi. Dosyayı Synology'den Windows masaüstüne kopyalamak işe yaradı. Bu yerel dosyayı Windows'tan UNAS'a kopyalamak aynı hatayla başarısız oldu. Synology dosyayı sunabiliyor, yerel NTFS tutabiliyordu; yalnızca bu belirli dosyayı yeni kutuya yazmak sınırlamayı tetikliyordu.

Yerel kopyada dir /r çalıştırmak nedeni ortaya çıkardı: 4,5 MB'lık ses verisinin yanında, dosya 01APIC_03.jpg adında, yaklaşık 360 KB'lık bir adlandırılmış Alternatif Veri Akışı (Alternate Data Stream) taşıyordu. ADS, dosyaya normal içeriğinin ötesinde ek adlandırılmış akışlar ekleyen on yıllardır var olan bir NTFS özelliğidir. Bu, tuhaf yüzde 92 işaretini de açıklıyordu: Robocopy ana dosyayı bitiriyor, sonra ek akışta takılıyordu.

Çözüm: /COPY:DATX

Robocopy, alternatif veri akışlarını atlayan bir X kopyalama bayrağı belgeler. Böylece /COPY:DATX dosyanın verisini, özniteliklerini ve zaman damgalarını taşırken adlandırılmış akışları geride bırakıyor, /DCOPY:DATX ise aynı kuralı dizinlere uyguluyor. Bu bayraklarla yeniden denendiğinde, sorunlu dosya sorunsuz kopyalandı.

Hanselman ayrımı vurguluyor: bu, MP3, M4A, M4P veya JPEG dosyalarının içine gömülü meta verileri değil, yalnızca bunlara bağlı ayrı dosya sistemi düzeyindeki akışları kaldırıyor. Onun durumunda bu akışlar yeni NAS'a taşınmaya değmezdi.

/Z sessiz darboğazdı

Hatalar çözüldükten sonra toplu geçiş çalıştı ama verimlilik çılgınca dalgalanıyordu: saniyede birkaç yüz megabitten, küçük dosyalarda neredeyse tam duraklamalara kadar. Hanselman arabelleklemeyen, yavaş diskleri, parity hesaplamalarını, UNAS üzerindeki SMB davranışını ya da yaşlanan Synology'yi şüphelendi. Robocopy'nin thread sayısını azaltmak, hatta tek thread'e indirmek bile hiçbir şeyi değiştirmedi. /Z'yi kaldırmak değiştirdi.

/Z yeniden başlatılabilir modu etkinleştiriyor; kesintiye uğrayan bir dosya sıfıncı bayttan başlamak yerine kaldığı yerden devam edebiliyor. Hanselman, 2007'de Robocopy ve XCopy üzerine yazısından beri bunu varsayılan olarak kullanıyordu; ancak Microsoft'un güncel geçiş kılavuzu, yeniden başlatılabilirliğin gerektirdiği ek günlük kaydının kopyalama performansını ciddi şekilde düşürebileceği konusunda özellikle uyarıyor.

Nihai müzik kütüphanesi komutu, bir günlük dosyasıyla /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE şeklinde çalıştı ve 15.940 dosyayı sıfır hatayla bitirdi: 6.991 kopyalandı, 8.949 atlandı, kalan yaklaşık 48 GB'lık veri ortalama saniyede yaklaşık 187 MB hızla taşındı.

Bunun her seferinde tek bir değişkeni izole eden kontrollü bir benchmark olmadığını açık sözlülükle belirtiyor; yani bu sayı /Z'nin önceki yavaşlamanın her parçasına neden olduğunu kanıtlamıyor. Pratik fark, artık LAN geçişlerine bu bayrak olmadan başlayıp yalnızca devam ettirilebilirlik gerçekten önemli olduğunda eklemesi kadar büyüktü.

/MT dosya başına ek yücü örtüşütürür, o kadar

Robocopy'nin /MT:n seçeneği 1 ile 128 arasında thread çalıştırıyor; tek başına verildiğinde varsayılan sekiz ve Microsoft'un kılavuzu daha fazla thread'in otomatik olarak daha hızlı geçiş anlamına gelmediğini belirtiyor. Hanselman'ın zihinsel modeli şu: thread'ler tek bir dosyanın kopyalanmasını hızlandırmıyor; açma, oluşturma, yazma, meta veri işleme ve kapatma gibi sabit dosya başına işleri örtüşütürüyorlar; böylece ağ ve diskler çok sayıda küçük dosya boyunca meşgul kalıyor. Binlerce parçalık bir kütüphane için dört thread tatlı noktayı yakaladı, on altı belirgin bir yarar sağlamadı, bir ise hiçbir iyileşme getirmedi. Herhangi bir değeri evrensel bir varsayılan olarak görmemek gerektiği konusunda uyarıyor.

Neden önemli

Kutudan kutuya NAS geçişleri, dosya sistemi uyumsuzluklarının ortaya çıktığı yerlerdir ve alternatif veri akışlarının neden olduğu Windows 665 hatası, dosya adı sorunu olarak yanlış okunması kolaydır. Genellenebilir yöntem şudur: kopyalama yolunu ikiye bölün, akışları incelemek için dir /r kullanın ve bunları korumaya değmiyorsa /COPY:DATX'e başvurun. Eşit derecede önemlisi, Robocopy alışkanlıkları katılaşıyor: /Z gibi 2007 döneminin güvenilmez bağlantılarında anlamlı olan bayraklar, modern bir 10GbE LAN'da bir kopyalamaya hükmedebilirken, /MT sihirli bir sabit değil, iş yükü ayar düğmesidir. Kendi Synology'den UNAS'a geçişini planlayan self-host'cular için yazı, en çok ısırmaya yatkın tuzakların kompakt bir kontrol listesi olarak da hizmet ediyor.