10 yıldır sürücü arızası yaşamayan 71 TiB ZFS NAS
(louwrentius.com)- 24 adet 4TB HGST sürücüyle kurulan 71 TiB ZFS NAS, 10 yılı aşkın süredir kullanılıyor; anakart ve güç kaynağı değiştirilmiş olsa da sürücülerde hâlâ arıza görülmedi
- 10 yıl boyunca sürücülerin toplam çalışma süresi yalnızca yaklaşık 6000 saat oldu; sistemi sadece gerektiğinde uzaktan açma yöntemi elektrik maliyetini büyük ölçüde düşürdü
- HN'de, 24 sürücünün 10 yıl boyunca hiç arızalanmama olasılığının sanılandan daha yüksek olabileceği yorumu yapıldı; bu nedenle bunu sık sık kapalı tutulmasına bağlamak zor
- ZFS, işletim sistemi değiştirildikten sonra da havuzu sorunsuz biçimde yeniden içe aktardı ve yılda birkaç kez çalıştırılan zpool scrub sırasında hiç checksum hatası bulunmadı
- Gürültü, ağ, UPS, yedekleme ve değiştirme planları; güç tüketimi, maliyet ve risk kabullenimi arasında bir dengeyle yönetildi ve aynı kapasite gelecekte 6~8 sürücülü RAIDZ2 ile de sağlanabilir
10 yılı aşan ömrüyle 71 TiB ZFS NAS
- 24 adet 4TB sürücüden oluşan 4U 71 TiB ZFS NAS 10 yılı aşkın süredir kullanılmaya devam ediyor
- Mevcut sistem şu anda ikinci anakartını ve ikinci güç kaynağını kullanıyor
- Sürücü arızası ise şimdiye kadar hiç yaşanmadı
- 4TB HGST sürücülerin toplam çalışma süresi yaklaşık 6000 saat, yani 10 yıllık dönemde yaklaşık 250 günlük çalışmaya denk geliyor
Yalnızca gerektiğinde açılan güç yönetimi
- NAS normalde kapalı tutuluyor ve yalnızca gerektiğinde uzaktan açılıyor
- Açma akışı şu şekilde
- Bir betikle IoT akıllı priz açılıyor
- BMC (Baseboard Management Controller) açılışını tamamlayınca IPMI ile NAS'ın kendisi açılıyor
- Alternatif olarak Wake-on-LAN da kullanılabilirdi
- İş bitince küçük bir betikle sunucu kapatılıyor, birkaç saniye beklendikten sonra duvardaki güç de kesiliyor
- Yalnızca sunucuyu kapatıp anakart ve BMC'ye güç bırakmak yaklaşık 7W sürekli tüketime yol açtığı için bu yöntemden kaçınıldı
- Diğer servisler Raspberry Pi 4 veya bekleme tüketimi çok daha düşük sunucularda çalıştığından, büyük NAS'ı sürekli açık tutmak gerekmiyordu
- Temel motivasyon elektrik faturasında tasarruf ve bunun sabit disk ömrü için de iyi göründüğü düşünülüyor
- Ancak HN'de, 24 sürücünün 10 yıl boyunca arızasız kalma olasılığının beklenenden yüksek olabileceği yönünde görüşler geldiğinden, bu sonucu güç keserek kullanım şekline bağlamak zor
- Önceki NAS da 20 adet 1TB Samsung Spinpoint F1 sürücüyle yaklaşık 5 yıl çalışmış ve sürücü arızası yaşamamıştı
Sürücülerden önce sorun çıkaran parçalar
- Sürücüler sağlam kalırken birkaç yıl önce anakartın değiştirilmesi gerekti
- Arıza belirtisi, BIOS'a girilememesi ve zaman zaman açılışın başarısız olmasıydı
- CMOS pilini çıkarmak gibi temel adımlar denendi ama çözüm olmadı
- Aynı anakart Ebay'de uygun fiyata bulunduğu için büyük sorun yaşanmadan değiştirildi
- Aynı karta ihtiyaç duyulmasının nedeni sunucunun 4 PCIe yuvası kullanmasıydı
- Yapılandırma 3 HBA ve 1 adet 10Gbit NIC'ten oluşuyordu
- Güç kaynağı, açılış sırasında tüm sürücülerin aynı anda spin-up olması nedeniyle birkaç saniye boyunca yaklaşık 600W çekilen bir koşulla karşı karşıya kaldı
- Güç kaynağı 750W değerindeydi ve 12V hattının da yeterli güç verebildiği hatırlanıyor, ancak açılışta bazen korumaya giriyordu
ZFS kullanımı ve scrub sonuçları
- ZFS yıllar boyunca sorunsuz çalıştı
- İşletim sistemi birkaç kez değiştirildi ama yeni OS kurulduktan sonra mevcut havuzu yeniden içe aktarmakta sorun yaşanmadı
- Yeni bir depolama sunucusu kurulacak olsa yine ZFS kullanılmak isteniyor
- zpool scrub yılda birkaç kez çalıştırılıyor
- Bir scrub işleminin tamamlanması yaklaşık 20 saat sürüyor
- Scrub sırasında güç tüketimi arttığı için, dinamik elektrik tarifesinde elektriğin ucuz olduğu günlerde çalıştırılıyor
- Şimdiye kadar scrub sırasında checksum hatası hiç bulunmadı
- Tüm sürücüler toplamda 1 petabayttan fazla veri okumuş gibi görünse de, ZFS'nin kurtarmaya müdahale etmesi gereken bir durum yaşanmadı
Sürücü hataları ve sessiz veri bozulması
- Sürücü arızaları genelde iki ana biçimde görülüyor
- Sürücünün hiç algılanmaması şeklindeki tam arıza
- Okuma-yazma hataları veya bozuk sektörler
- Üçüncü tür olan sessiz veri bozulmasının ise çok nadir olduğu düşünülüyor
- Diskin bozuk veriyi ilettiğini kendisinin fark etmemesi
- SATA bağlantısında checksum hatalarının tespit edilememesi
- Alt seviyede çok sayıda checksum kontrolü bulunduğundan bu riskin çok düşük olduğu düşünülüyor
- Sessiz veri bozulması gerçek bir risk olsa da, ev ortamından çok veri merkezi gibi büyük ölçekli ortamlarda daha fazla önem verilmesi gereken bir konu olarak görülüyor
- ZFS, Linux veya FreeBSD'ye aşina kullanıcılar için öğrenmeye değer ve öğrenmesi çok zor değil
Sessiz bir NAS için fan kontrolü
- Bu NAS, bir NAS için oldukça sessiz sayılıyor
- Kasada 24 sürücü yuvasını soğutan sağlam 3 adet 12V fan bulunuyor
- Varsayılan hızda çok gürültülü olsalar da düşük RPM'de oldukça sessizler ve çoğu durumda yeterli hava akışı sağlıyorlar
- Ancak yalnızca düşük hız, sürücüler okuma-yazma yaparken sıcaklığın zamanla yükselmesini engelleyemedi
- Kullanılan Supermicro anakart, Linux altında tüm fan başlıklarının kontrol edilmesine izin veriyordu
- En sıcak sürücünün sıcaklığına göre fan hızını ayarlayan bir betik yazıldı
- Matematik odaklı bir subreddit'te hem sessiz kalacak hem de sürücüleri serin tutacak uygun algoritma soruldu ve PID denetleyicisi önerildi
- Python ile PID denetim kodu yazıldı, örnek kodlar alınarak parametreler ayarlandı
- Bu betik yıllardır iyi çalışıyor ve sürücü sıcaklığını 40°C'nin altında tutuyor
- Temel hava akışı düşük olduğundan, HBA ve ağ kartı gibi 4 PCIe kartını soğutmak için ek fan da gerekti
Ağ yapılandırmasındaki değişimler
- Başlangıçta dört portlu gigabit ağ denetleyicisi ve network bonding kullanıldı
- Bu yapılandırmayla birden çok sistem arasında yaklaşık 450MB/s aktarım hızı elde edildi
- Çok fazla UTP kablo gerektiği için daha sonra uygun fiyatlı Infiniband kartlara geçildi
- Infiniband yapılandırmasında sistemler arasında yaklaşık 700MB/s seviyesine ulaşılabildi
- Ubuntu'dan tekrar Debian'a dönülünce Infiniband kartlar artık çalışmadı ve neden çözülemedi
- Daha sonra ikinci el 10Gbit Ethernet kartları satın alındı ve bunlar şu ana kadar sorunsuz çalışıyor
UPS, yedekleme ve risk kabullenimi
- Bir süre, elektrik kesintisinde düzgün kapanış sağlamak için büyük bir UPS kullanıldı
- UPS'in, sunucunun güç tüketimine ek olarak 10W'tan fazla daha harcadığı fark edilince sistemden çıkarıldı
- Güç kaynaklı bir sorun yüzünden sistemin kaybedilme riski kabul edildi
- En önemli veriler üç kez yedekleniyor
- Sunucuda tutulan verilerin önemli bir kısmının ise yedeklenecek kadar kritik olmadığı düşünülüyor
- Sürücü arızası nedeniyle veri kaybına karşı, yedek donanım ve ZFS'ye güveniliyor
- Bu koruma yeterli olmazsa kaybı kabullenme yaklaşımıyla sistem 10 yıldır işletiliyor
Daha küçük bir yapılandırmayla mümkün olan sonraki nesil
- Şu anda ayrı bir gelecek depolama planı bulunmuyor
- Bu sunucunun başlangıçta kurulma nedeni, alan yetersizliği yüzünden verileri sürekli taşımak istememekti ve bugün de hâlâ yeterince boş alan var
- Yedek anakart, CPU, bellek ve HBA kartları bulunduğundan, bir arıza olsa bile sistemi yeniden ayağa kaldırma olasılığı yüksek
- Sabit disk kapasiteleri büyük ölçüde arttığı için, bir gün 24 yuvalı kasa daha küçük bir form faktörle değiştirilebilir
- Aynı düzeyde yedekli depolama, 6~8 sabit disk ve RAID 6 düzeyinde yedeklilik sunan RAIDZ2 ile kurulabilir
- Depolamanın hâlâ pahalı olduğu düşünülüyor
- Bir başka olasılık da sistemin önümüzdeki birkaç yıl içinde sonunda arızalanması ve yerine yenisi konmadan depolama hobisinin sona ermesi
1 yorum
Hacker News yorumları
Disk değiştirme periyodu olup olmadığını merak ediyorum
24 diskin aynı model ve muhtemelen aynı partiden olması, dolayısıyla aşınmalarının da benzer olması muhtemel; bu durumda çoğu benzer zamanda arızalanabilir ve geri kalanlar da yeniden oluşturma sırasındaki artan yük yüzünden peş peşe bozulabilir
Güvenilir depolama işini yapmak zordur
Doğal olarak ikisi de aynı anda bozuldu ve bütün gece kurtarma işiyle uğraşmak zorunda kaldım
Gerçekten çok şanslıymışım :D
Ama donanım aşınmasının bu kadar tutarlı olacağını sanmıyorum
Bir disk öldü ve yeniden oluşturma sırasında ikinci disk de onun ardından gidene kadar sistem idare etti
Tabii bu ZFS değildi, düzenli scrub da yoktu, 2000’lerde disk arıza oranları da farklı olabilir ve kullanılmadığında cihazı kapatmıyordu
Buradaki esas nokta tam neden değil, korelasyonlu arıza. Genel uyarı olarak da bunun örneklem sayısı 1 olan, internetteki rastgele bir kişinin anlattığı bir olay olduğunu eklemek lazım
“Bu NAS, bir NAS için çok sessiz” kısmı, büyük çaplı fanların düşük RPM’de bile çok hava taşıyabilmesi ve enerji verimliliğinin de çok daha iyi olmasıyla ilgili
Oxide Computer bir sunumunda neden 80mm fan kullandığını anlattı; sebebin sessizlik ve daha da önemlisi düşük güç tüketimi olduğunu söyledi
Başka sunucularda enerjinin %25’ine kadarının fanları döndürmeye gittiğini, kendilerinde ise bunun yaklaşık %1 olduğunu gözlemlediklerini anlattılar
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Neredeyse yok olmuş Flex ATX güç kaynaklarındaki 40mm fanlar hariç öyle sayılır; 80mm de bugünlerde epey nadir. Genelde 120mm ya da 140mm görüyorum
Tipik DC yüksek devirli küçük fanların çıkardığı yüksek frekanslı gürültüden gerçekten nefret ediyorum
Umarım fan hızını kontrol ederken biraz “akıllı” yöntemler de kullanıyorlardır ;-)
Daha fazla hava akışını daha düşük hızda sağlama fikrine tamamen ikna oldum
Bunun 1U ya da 2U kasalarda zor olduğunu da anlıyorum
Yine de güzel. Sadece fan gürültüsündeki azalma bile şaşırtıcı; bu kadar basit görünen bir şeyi neden daha önce kimsenin düşünmediğini sorgulatıyor
Diskleri sürekli döndürmenin, güç çevrimlerinden kaynaklanan aşınmayı azalttığı yönünde tam tersi tavsiye de duymuştum
Neye inanmak gerektiğini bilmiyorum ama ZFS NAS’i açık bırakıp düzenli scrub çalıştırabilmek ve veriyi doğrulayabilmek hoşuma gidiyor
Referans olması açısından 4 diskli bir sistemi 10 yıl çalıştırdım; bu sürede iki disk arızası yaşadım ama bunlar kurumsal sınıf değil, WD Green’di
Diski günde bir iki kez açıp kapatmakla, her 15 dakikadan kısa sürede bir spin-down olması aynı şey değil
WD Green diskler NAS için önerilmez. Eskiden okuma/yazma kafalarını birkaç saniyede bir park ederlerdi; seyrek veri erişiminde sorun olmayabilir ama sunucuda bu, sürekli aşınmaya yol açıp erken arızayı tetikleyebilir
Okuma/yazma kafaları plakanın üzerinde süzülürken neredeyse hiç aşınmaz. Güç kapatıldığında ise kafa fiziksel olarak bir rafa ya da plaka üzerindeki iniş bölgesine oturur; iniş ve kalkış kafaya en büyük aşınmayı verir
En kötü durumda statik sürtünme yüzünden kalkış sırasında kafa kopabilir
Rulmanlar da daha uzun ömürlü olur; çok uzun süre dururlarsa sıkışabilirler. Aynı şey disk motoru için de geçerli
Cihaz açılırken oluşan ani akım da, ne kadar küçük olursa olsun, bir elektriksel strestir
Sabit diski kapatmanın nedenleri sadece güç tasarrufu, gürültüyü azaltma ve taşıma durumlarıdır
Bu da gün içinde defalarca spin-up ve spin-down yaşanabileceği anlamına gelir; bu yüzden bu iddia bana hiç ikna edici gelmiyor
Yine de bunu destekleyecek elimde kanıt yok
Böyle bir senaryoda, disklerin birkaç dakikada bir açılıp kapanmasını önlemek için sürekli dönmesini sağlamak ömür açısından faydalı olabilir
Ama bir homelab söz konusuysa, disk bakım maliyetinde tasarruf edeceğinizden çok daha fazlasını elektrik faturasında harcıyor olmanız muhtemel
Aile medyası için birkaç büyük diskim var ve bunları yalnızca “disk henüz bozulmadı” düzeyinden daha yüksek bir güvenle korumak istiyorum
Checksum dosya sistemi tartışmaları genelde ZFS ve BTRFS etrafında dönüyor, ama bcachefs kullanan biri var mı merak ediyorum
Linux çekirdeğine upstream edildi ve bildiğim kadarıyla tam checksum desteği sunuyor. Geliştiricisi de dosya sisteminin sorumluluğunu ciddiye alıyor gibi görünüyor
Burada kullanan var mı?
https://bcachefs.org/
Tüm RAID'in journal sorunu yüzünden mount edilemez hale gelmesi yaklaşık 1 hafta sürdü. Yapılandırma 8 HDD, 2 SSD write cache ve 2 NVMe read cache idi
Geliştiricisi Reddit'te bir gün içinde yanıt verdi ve önerdiği düzeltmeyi denedim. Linux çekirdeğini derleyip onunla boot etmem gerekti ama sorun çözülmedi
Sonrasında ne yazık ki yanıt gelmedi; birkaç gün bekledikten sonra sistemi silip sıradan bir mdadm RAID'e geri döndüm
Önemli olan her şeyi zaten yedeklemiştim ama önemsiz bazı verileri kaybettim; bu da bana en son teknoloji kararsızdır gerçeğini tekrar hatırlattı
Yine de kurulum süreci ve özellikleri harikaydı. Disk ekleyebilmek ve onları okuma/yazma cache olarak işaretleyebilmek bile güzeldi
Birkaç yıl daha olgunlaştıktan sonra kesinlikle tekrar denemeyi düşünüyorum
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Üretim verilerinde risk almak istemem ama homelab için uygun olabilir
Yine de bir şeyler ters giderse ne kadar zaman harcamaya istekli olduğunu kendine sorman gerekir
ZFS'yi de 15 yılı aşkın süredir kullanıyorum ve kötü donanım yüzünden çok şey gördüm, ama iyi kurumsal donanımda kusursuz çalıştı
Yaklaşık 2TiB SSD'yi, yaklaşık 8TiB büyük sabit disklerin önünde SSD cache olarak kullandığım bir düzeni deniyorum
Ubuntu'da artık legacy sayılan zsys + root ZFS kombinasyonuyla ufak tefek sorunlar yaşadım, ama bu yaygın bir kurulum ve yıllardır geniş çapta kullanıldığı için destek bulmak kolay
bcachefs benzer bir benimsenme düzeyine ve topluluk desteğine ulaşana kadar muhtemelen kullanmam
Disklerin çalıştığı ortamın ömür üzerinde çok büyük fark yarattığını düşünüyorum
Ev ortamı, veri merkezi ya da ofise göre çok daha değişken. Sıcaklık ve nem dalgalanmaları büyük bir mesele ama beni şaşırtan şey, az miktarda tozun bile oldukça belirgin bir etkisi olmasıydı
Çok uzun zaman önce bodrumdaki eski bir Dell sunucuda 8x500G dizisi çalıştırıyordum. Disklerin hepsi yeni Seagate'ti, 7200RPM'di ve belki de “enterprise” sürümlerdi
5 yıl boyunca ortalama her 6 ayda bir disk arızalandı. 2 parity diski tutuyor, yedek disk bulunduruyor ve her arızada RMA gönderiyordum
Taşındıktan sonra yalnızca laboratuvar için ayrılmış bir odam oldu ve aynı yapılandırmada sonraki 5 yıl boyunca tek bir arıza bile yaşanmadı. Yeni ortamın daha iyi olacağını bekliyordum ama daha temiz ve daha istikrarlı bir ortamın bu kadar fark yaratması şaşırtıcıydı
NAS/dosya sunucusunu yıllarca tozlu bir ev ortamında çalıştırdım, hatta şimdi bile o mat gri Synology logosunu görebiliyorum, ama böyle bir şey hiç yaşamadım
O nesilde bir firmware sorunu varmış gibi görünüyordu
Buradan yıllık arıza oranlarına bakabilirsin: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Günümüzdeki kapalı, helyum dolu disklerde, başlangıçta bir sorun olmuş olsa bile artık büyük bir mesele olmayacaktır
“Güç sorunları yüzünden sistemi kaybetme riskini göze alıyorum” kısmıyla ilgili olarak, UPS’in önlediği bir diğer çok nadir arıza türü de elektrik dengesizliği
Yakındaki bir inşaat sırasında elektrikte sorun çıkarsa ya da evin yakınındaki elektrik direğine yıldırım düşerse, yukarı ve aşağı yönlü spike’lar oluşabilir ve ikisi de yıkıcı olabilir
İlk işimde yaklaşık 10 yıl önce birkaç sunucu bu şekilde öldü. Ama böyle bir sorunu duyduğum tek zaman da oydu
Anladığım kadarıyla UPS bu tür spike’ları da engeller ve sunucu hasar görmeden önce önce UPS ölür
Anne babamın evindeki TV antenine yıldırım doğrudan düştü ve koaksiyel kablo üzerinden iletişim dolabındaki yükselteç/dağıtıcıya kadar ilerledi
Sonra bir şekilde yakındaki ağ patch paneline atladı ve ağa bağlı tüm kablolu Ethernet denetleyicilerini yaktı. Switch portları ve AP’lere gömülü olanlar da dahil
Ağ switch’lerinde akım muhtemelen toprağa gitmeye çalıştığı için güç kaynağını da yok etti
Koaksiyelden Cat5’e nasıl geçtiği hâlâ biraz gizem. Elektrikçi bir yerde birbirine yakın paralel döşenmiş bir bölüm bırakmış olabilir
Tüm ağı yeniden döşemek zorunda kaldım ama neyse ki sahada kablolu bilgisayar yoktu. Depolama da muhtemelen dayanamazdı
Office Depot’tan alınan 99 dolarlık 850VA APC bunu yapmaz. Sadece AC’den bataryaya çok hızlı geçer, gerçek anlamda güç temizleme yapmaz
İyi bir ürün alabiliyorsanız, uzun vadede donanım güvenilirliğini gerçekten artırır. Temiz güç iyidir
Ölen cihazlar, hasarlı cihazlar ve görünüşte sağlam kalan cihazların dağılımına bakılırsa, VDSL taşıyan bakır hat çok doğrudan bir yoldu. Modem Ethernet üzerinden diğer tüm cihazlara bağlıydı
Doğru çözüm muhtemelen fibere çevirip kısa bir fiber optik bölümden geçirip sonra tekrar dönüştürmek olur. Elektrik büyük olasılıkla cam yerine başka bir yol seçer
Ama ürün seçmek beklediğimden çok daha uğraştırıcı çıktı; ağ tarafının insanı olmadığım için yaklaşık bir saat ürünleri ayırt etmeye çalışıp vazgeçtim
Bu yüzden VDSL modem ile diğer ekipman arasına bir Wi-Fi bridge koydum. Bir sonraki fırtınada o arıza modunun izole kalmasını umuyorum
Aynı modeme bağlı bir ZFS dizisi vardı; hayatta kaldı ama sanırım sadece şanslıydı
O zaman sunucum yoktu ama birkaç haftada bir LED ampul bozulduğu için sinir bozucuydu. 60’lardan kalma eski bir binaydı ve dairemizin elektrik tesisatında da şüpheli geçici tamirler vardı
“Sır” gücü kapatmak değil, sadece şans
4TB HGST diskleri 10 yılı aşkın süredir 7/24 çalıştırıyorum. Tam 24 tane değil, 8 tane ama arıza sayısı 0
Ben de sadece şanslıyım; aynı disklerle defalarca RMA yapan tanıdıklarım da var
Asıl merak ettiğim, çoğu zaman kapalı tutulabiliyorsa 71TB gerektiren verinin ne olduğu. Yedek depolama sunucusu mu?
Örneğin rulmanlar soğukken sıkışabiliyordu
İstatistikten anlayan biri, yıllık arıza oranını yaklaşık %1 varsayıp 24’ünün de hayatta kalma olasılığını hesaplayabilir gibi
Üstelik önceki NAS’taki 20 diskte de arıza yokmuş. O zaman N=44; bu kadar şanslı olmak ne kadar olası?
Ev kullanımı için kullanılıyor ve veriye ihtiyaç olduğunda genelde 10Gbit ile çok daha düşük güç tüketen bir sisteme kopyalanıyor, sonra bu NAS tekrar kapatılıyor
Güç döngüsünün riskli olduğu diskler vardı
Bu yüzden modele katılıyorum ama bunun her zaman herkes için iyi bir yöntem olduğunu varsaymamak gerekir. Bazı SSD’lere periyodik olarak güç verilmesi gerekir
NAS’ın kullanım döngüsünde bu gereksinim muhtemelen karşılanır
Muhtemelen sorun olmaz ve elektrik faturası kesinlikle daha ucuzdur. Mile ekstra gres konmuş diskler bir dönemlik sıra dışı bir vakaydı
Backblaze’in disk açma/kapama ile ömür arasında istatistiksel bir modeli olup olmadığını merak ediyorum. Onlar hep açık olan problem alanında gibi görünüyor
Ama benim durumumda bu diskler sık sık güç döngüsüne girmiyor. En fazla ayda birkaç kez
Bunun büyük bir risk olmadığını söyleyemem ya da kanıtlayamam, ama öyle olmadığına inanıp bu riski 15 yıldan uzun süredir kabul ediyorum
Ayrıca sabit disklerde boşta kalınca spin-down seçeneği olduğunu da unutmamak gerek. Yani sabit diskler bir günde birçok spin-up’ı kaldırabilecek şekilde tasarlanmış
Birkaç Synology cihazını yedeklemek için dahili 3.5 inç sabit diskler ve USB dock kullanıyordu; dosya geri yüklemek ya da ek yedek almak için diski tekrar dock’a taktığında yaklaşık her 10 denemeden 1’inde yeniden açılmıyor gibiydi
Üretim ortamında birkaç yıldır ZFS üzerinde çok TB’lık PostgreSQL veritabanı kullanıyorum ve şimdiye kadar bit flip dahil hiçbir sorun yaşamadım
İlgilenenler için deneyimimi burada belgeledim:
https://lackofimagination.org/2022/04/our-experience-with-po...
Açılış sırasında aralıklı güç kesintileriyle ilgili olarak, disklerin başlangıçta 5V rail üzerinden güç çektiğine bakmak gerekir
Benzer diskler genelde en fazla 1.2A tüketir. Bunu 5V rail’in 25A azami yüküyle birleştirince (Seasonic Platinum 860W), staggered spinup kullanılmadığında açılış sırasında güç arızası yaşanması olasıdır