Linux'u büyük bir bölüme kurmak gerçekten ne kadar kötü?

Yeni sunucumuzda CentOS 7'yi çalıştıracağız. Sunucuda dahili olarak raid6'da 6 x 300GB sürücülerimiz var. (Depolama, 40TB baskın kutusu şeklinde büyük ölçüde haricidir.) Tek bir birim olarak biçimlendirilmişse, iç hacim yaklaşık 1.3 TB'a gelir. Bizim sysadmin, işletim sistemini büyük bir 1.3 TB'lik bölüme kurmanın gerçekten kötü bir fikir olduğunu düşünüyor.

Ben bir biyologum. Çalıştırmak ve test etmek için çoğu / usr / local alanlarına giren sürekli yeni yazılımlar kuruyoruz. Bununla birlikte, sistemi kullanan yaklaşık 12 bilgisayar meraklısı biyologa sahip olmadığımızdan, aynı zamanda ev / ev içinde de çok fazla kıtlık topluyoruz. Son sunucumuz / için 200GB'lık bir bölüme sahipti ve 2.5 yıl sonra% 90 doluydu. Bunun bir daha olmasını istemiyorum ama aynı zamanda uzman tavsiyelerine karşı gelmek de istemiyorum!

1.3TB'yi, gerektiğinde ve gerektiğinde alanın mevcut olduğundan emin olmak için en iyi şekilde nasıl kullanabiliriz, ancak sysadmin için bir bakım kabusu yaratmaz mıyız?

Bölümlemenin birincil (tarihsel) nedenleri şunlardır:

• için kullanıcı ve uygulama verilerinden işletim sistemini ayrı . RHEL 7 piyasaya sürülünceye kadar, desteklenen bir yükseltme yolu yoktu ve büyük sürüm yükseltme, yeniden kurulum gerektirecek ve ardından /homeayrı bölümlerde (veya LVM birimlerinde) örneğin ve diğer (uygulama) verilere sahip olmak, kullanıcı verilerini kolayca korumanıza izin veriyor. ve uygulama verilerini girin ve işletim sistemi bölümlerini silin.

• Kullanıcılar düzgün bir şekilde giriş yapamıyor ve disk alanınız tamamen tükendiğinde sisteminiz ilginç şekillerde başarısız olmaya başlıyor. Birden çok bölüm, işletim sistemi için sabit disk alanı atamanıza izin verir ve bunu, kullanıcıların ve / veya belirli uygulamaların yazmalarına izin verilen alandan ayrı tutmasını (örn /home /tmp/ /var/tmp/ /var/spool/ /oradata/. Vb.) Ve kötü davranış gösteren kullanıcıların ve / veya uygulamaların operasyonel riskini azaltır .

• Kota. Disk kotası, yöneticinin tek tek bir kullanıcının mevcut tüm alanı kullanmasını engelleyerek sistemin diğer tüm kullanıcılarına hizmet vermesini önlemesini sağlar. Dosya sistemi başına ayrı bir disk kotası atanır, bu nedenle tek bir bölüm ve dolayısıyla tek bir dosya sistemi yalnızca 1 disk anlamına gelir. Çoklu (LVM) bölümleri, daha ayrıntılı kota yönetimi için izin veren çoklu dosya sistemleri anlamına gelir. Kullanım senaryosuna bağlı olarak, örneğin, her kullanıcının kendi ana dizininde 10 GB'a, harici depolama dizisindeki / data dizininde 2 TB'a izin vermesini isteyebilir ve herkesin ana dizini için çok büyük veri kümelerini atabileceği paylaşılan büyük bir karalama alanı oluşturabilirsiniz. ve politikanın "tam dolu" olduğu yerde, ancak bu olduğunda hiçbir şey bozulmaz.

• Özel GÇ yolları sağlamak . SSD'lerin ve dönen disklerin bir birleşimine sahip olabilirsiniz ve bunları farklı bir şekilde ele almanız iyi olur. Genel amaçlı bir sunucuda çok fazla bir sorun değil, ancak veritabanı kurulumlarında oldukça yaygın olan şey, aynı zamanda IO çekişmesini önlemek için belirli iş millerini (diskleri) atamaktır; örneğin işlem günlükleri için ayrı disk, gerçek veri tabanı verileri için ayrı diskler ve ayrı diskler geçici alan için diskler. .

• Önyükleme Ayrı bir /bootbölüme ihtiyaç duyabilirsiniz . Tarihsel olarak, 1024 silindir sınırının ötesinde önyüklemeyle ilgili BIOS sorunlarını çözmek için, günümüzde daha sık olarak şifrelenmiş birimleri destekleme, belirli RAID denetleyicilerini, HBA'lar SAN tarafından yüklenmeyi desteklemeyen ya da kurulumcu tarafından hemen desteklenmeyen dosya sistemlerini destekleme zorunluluğu getirilmiştir.

• Ayarlama Farklı ayar seçeneklerine veya hatta tamamen farklı dosya sistemlerine ihtiyaç duyabilirsiniz.

Sert bölümler kullanıyorsanız, az veya çok kurulum sırasında doğru bir şekilde kullanmak zorunda kalırsanız, o zaman tek bir büyük bölüm en kötüsü değildir, ancak yukarıdaki kısıtlamalardan bazılarıyla birlikte gelir.

Genelde ana biriminizi tek bir büyük Linux LVM fiziksel birimi olarak bölümlemenizi ve ardından mevcut gereksinimlerinize uygun ve disk alanınızın kalanı için mantıksal birimler oluşturmanızı ve gerektiğinde atanmamış bırakmanızı öneririm .

Gerektiğinde, bu birimleri ve dosya sistemlerini (canlı bir sistemde yapılabilecek önemsiz bir işlemdir) genişletebilir veya ek sistemler oluşturabilirsiniz.

LVM birimlerinin küçültülmesi önemsizdir, ancak çoğu zaman üzerlerindeki dosya sistemlerini küçültmek çok iyi desteklenmez ve muhtemelen kaçınılması gerekir.

Birden çok bölüm kullanma kavramı, yanlış yerdeki bir bölümün tüm sistemin beklenmedik bir şekilde çalışmasına neden olmayacağı yönündedir.

Boş alan bulunmadığı noktaya kadar oldukça hızlı bir şekilde bir günlük dosyasını doldurmak için makinede bir işlem düşünün. Tek bölümlemeli bir makinede bu, örneğin sistemin / tmp'ye yeni veri yazmasını engelleyebilir. Eğer / tmp'a yazmak isteyecek başka bir işlem varsa, muhtemelen beklenmeyen davranışa sebep olan bir hata ile çıkar.

Kullanıcıların veya işlemlerin normal olarak (/ home, / var, / tmp) yazdığı yerler için farklı bölümler kullanırsanız bu önlenebilir.

Eski sunucunuza hangi klasörlerin büyük olma eğiliminde olduğunu kontrol etmenizi öneririm. Bunu komut satırında yapabilirsiniz.

du -h -d 1 / 2> /dev/null

En fazla verinin nerede toplandığını göreceksiniz ve bir sonraki sisteminizi uygun şekilde tasarlayın. "-D 1" çıktıyı daha fazla okunabilir kılmak için yalnızca bir klasör derinliği seviyesine sınırlar.

Tek bir büyük bölüme sahip olmanın temel sorunu, dosya sistemini doldurmanın artık oturum açmanın mümkün olmamasıdır.

Kullanıcı kökünün bunun /rootdışında ana klasörü ( ) var /home. Dosya sistemi bazı durumlarda doluysa, root bile oturum açamaz ve sistemi onaramaz.

Bu normalde için ayrı montaj noktaları oluşturmak nedeni budur /var, /tmpve /homediğer bölümleri biri kadar dolu olduğunda sistemi onarmak için kök olarak en azından giriş yapabilmek için.

IMHO, bir bölüme sahip olmak / oldukça makul.

Ancak, lvm'yi (mantıksal cilt yöneticisi) kullanabilirsiniz. Tüm diskleri lvm grubu olarak kullanın, ancak /, / home, / usr ve sysadmin'iniz ne isterse, küçük mantıksal diskler oluşturun. Ardından, sisteminiz dolmaya başladığında ve ihtiyaç duyduğunuz diskleri genişlettiğinizde, bildiğiniz bir şeyler izleyin. lvresize and resize2fs çevrimiçi bir araçtır ve sunucuyu yeniden başlatmadan genişletme yapabilirsiniz. Ancak diskleri azaltamazsınız, bu nedenle oldukça küçük bir şekilde başlamanız ve ihtiyaç duyduğunuz yerde artırmanız gerekir.

Linux'un büyük-tek bölümlü kurulumunda asgari problemler var, fakat büyük ödülleri var.

Bir bölüm düzenini değiştirmek, uzun süre kullanılmadan sık sık yapamayacağınız biraz zor ve riskli bir şeydir.

Tek avantajı, disk dolu sorunlara karşı bir miktar korumanızın olmasıdır. Ancak bu sorunları çok sık bulacaksınız . Durumunuz, bölümlerinizden biri doluysa ve diğer bölümlerdeki boşluğu neredeyse boş olsalar bile kullanamazsınız !

Bazı profesyonel sistem yöneticileri bu konuda tamamen farklı bir görüşe sahip. Birden fazla bölüme sahip olmanın sisteminizi daha güvenilir hale getirebileceğini ve bölümlemeden önce bölümlerinizin ne kadar büyük olacağını bilmeniz gerektiğini söylüyorlar. Bence, bu basitçe söylenemez, sistemdeki esnekliğin korkunç bir sakıncasıdır ve asıl motivasyonları, bölüm haritalarıyla oynamayı sevdikleridir .

Lvm adında basit bir sistem var ve “bölümlerin” anında hareket etmesini / yeniden boyutlandırılmasını sağlıyor (terminolojisinde, hacimlerde). Ancak, tek bir yerel departman sunucusunda IMHO normalde gerekli değildir.

Bölümlemenin iki ana nedeni vardır:

1. Statik verileri statik olmayan verilerden uzak tutmak için
2. Genel verileri özel verilerden uzak tutmak için

İlk neden en açık olanıdır - dosyaları doldurmayan alanları yalıtmanız gerekir ve özellikle engellenemez bir sistemden kaçınmak için korumak / / yapmak istiyorsunuz. Örneğin, / var dizini genellikle günlük dosyalarının depolanacağı yerdir (var "değişken" anlamına gelir) ve bu nedenle / var / 'dan ayrı bir bölüme monte edilme eğilimindedir.

Yukarıdaki ikinci neden daha az alıntılanmıştır (en son 15 yıl önce Veritas Cilt Yöneticisi kursunda duydum) ve bu gerçekten sadece birçok kişinin giriş yaptığı ve iş yaptığı sistemler ile ilgilidir.

Etkili ayrıştırma için bir sanat eseri var ve bu yüzden belki de onu biraz ileri götüren Sys Admins (IMO) var. Sadece içerideki dosya sistemini bilmek zorunda değilsiniz, aynı zamanda kullanım amacını da bilmek zorundasınız. Şahsen, sunucuların bugün kullanıldığı yöntemlerle daha az ve daha az ilgili hale gelen oldukça eski moda bir yaklaşım olduğunu düşünüyorum.

Bir yazılım geliştiricisi olarak, özellikle mevcut disk alanından bağımsız olarak / tmp, / home, / var ve / öğelerinin boyutunu ciddi şekilde kısıtlayan, düşüncesiz bölümleme şemalarına sahip Ops departmanından Sanal Makinelerden bıktım. / usr veya / opt gibi belirgin seçimleri ayrı ayrı yapmayın. Bu makineler, genellikle, istediğiniz disk alanından kalanları, kaçınılmaz olarak, her şeyi içine yerleştirerek ve birbirine bağladığınız bir "/ stuff" birimine yerleştirir, ancak bu bir teselli olur. Net sonuç, dosyaları dolaşmak ve gerçek bir iş yapmaktan ziyade uyarı e-postaları göndermek için genellikle daha fazla zaman harcıyoruz.

Tek bir bölüme sahip olmanın doğası gereği "kötü" bir şey yoktur. Herhangi bir sistemde, disk kullanımınızı proaktif olarak izlemeniz ve mantıklı temizlik stratejileri (örneğin, günlük döndürme, giriş dizinleri kotaları) kullanmanız gerekir; bu nedenle tek gerçek soru şudur: kaç ayrı dosya sistemi hakkında endişelenmek istersiniz?

Bu nedenle şunu söyleyebilirim: Kendi kullanım durumunuz için sistemi etkin bir şekilde bölümleme becerinize% 100 güvenmediğiniz sürece, hiçbir şekilde bölümlere ayırmayın .

IMHO tamamen size kalmış. İlk önce birkaç şey düşünün, ancak tamamen göreceli olsa da.

• bu sistem sık sık uygulanacak mı?
• bu sistem bir veya daha fazla kullanıcı tarafından kullanılacak mı?
• bu sistem masaüstü olarak mı yoksa sunucu olarak mı hizmet verecek?

Kişi herhangi bir dizini (neredeyse) düşünebildiğinden, bir tane de bir tane büyüyen veri içeren ve bir tane büyüyen veri içerenleri dikkate almalıdır.

Linux sisteminin ne kadar azının (biraz büyüyen veriler) çalıştırılması gerektiğini ve büyüyen verilerle ne kadar tüketildiğini görünce şaşıracaksınız (genellikle / var / opt / home / srv)

Ayrıca, bölümleme gereksinimlerini belirleyen bu sistemin kullanımını nasıl tanımladığınıza da bağlıdır. LVM için kullanımı dahil.

Tipik bir masaüstü sistemi, bir çok yazılımın yüklenmesi için yaklaşık 20GB'lık bir kapasiteye ihtiyaç duyacaktır; LVM, sisteminizde küçük bir ek yüke neden olur ve bu özel durumda, bu kadar büyük bir fayda sağlamaz. Düşünceler farklı olsa da.

Bir sunucuda yüklü yazılımın masaüstü sistem kadar dinamik olması daha az olasıdır. Ayrıca / tmp / var / usr / home / opt / srv gibi tipik dosya sistemi bileşenleri için gerçek bağlama noktalarına sahip olmak daha akıllıcadır. Burada LVM kullanımı zorunlu değildir.

Bu, sisteminizin büyük modülerliğini sunar, örneğin, bu bölümü bir VM'ye klonlamak gibi aptalca şeyler yapmanıza izin verir. Veya dd kullanarak blok düzeyinde bir yedekleme oluşturmak.

Bazı tecrübelere dayanarak, işte birkaç not. Ayrıca, daha fazla kontrol için birden fazla montaj noktasına izin vermeyi düşünün, hızlı veya yavaş bir disk cihazını montaj noktasına atamak fark yaratabilir ve maliyet verimliliğini önemli ölçüde artırabilir.

Dağılma noktası /

• 1GB (/ var / usr / opt / home / tmp için ayrı bağlantı noktaları kullanıyorsanız)
• Ayrı / evli bir masaüstü sistemi olarak kullanıyorsanız +10 veya hatta +20 GB

mountpoint / home kullanıyorsanız

• kullanılıyorsa tüm boş alanı ata, / home ne

mountpoint / opt kullanıyorsanız

mountpoint / usr kullanıyorsanız

• Bu zor bir tanesidir ve yüklü olan yazılım tabanına oldukça bağımlıdır.

mountpoint / var kullanıyorsanız

• Bu zor bir tanesidir ve yüklü olan yazılım tabanına oldukça bağımlıdır.
• Örneğin, veritabanları, tüm Linux değilse de, verilerini Debian tabanlı sistemlerde yazıyor.
• Ayrı / var / tmp olması mantıksız değildir

mountpoint / tmp kullanıyorsanız

• tmpfs'nin var olduğunu ve RAM / tmp ayırdığını düşün
• Bazı uygulamaların burada çok fazla veri yazabileceğini düşünün.

Her şeyden önce, neden bu soruyu burada yayınladığınızı bile, neden sabit disk bölümlemenin daha ince noktalarına ilişkin görünüşte yetkin bir sistem yöneticisi ile tartışan bir biyolog olduğunu sormalıyım! (alınma, sadece gerçekten neden sysadmin'e güvenmediğini merak ediyorum).

Yani, birkaç gözlem:

• 1.3 TB artık büyük bir sürücü değil. 2 TB, bugünlerde masaüstü dünyasında az çok standart bir SATA sürücü boyutudur.

• Herhangi bir Linux Distro kurulumunun 100 GB’dan daha fazlasına ihtiyaç duyması olası değildir. Kuşkusuz, / (kök) ve (takas) boyutu, cömertçe aşağılayarak (kök için) veya sistem yapılandırma kılavuzlarıyla (takas) üst sınır numaraları olarak kolayca belirlenmelidir.

• / home için bağlantı noktası, 40 TB RAID sunucunuzda bir yere işaret ediyor olmalıdır. Bu verilere, kullanıcıların ana dizinlerine, o kök aygıt üzerinde herhangi bir yerde olmaları gerekmez. Onları RAID sunucusuna koymak muhtemelen yine de daha iyi koruma sağlar. Ve, büyük olasılıkla kolayca genişletilebilir bir NAS tesisidir, oysa sunucu kutusuna yerleştirilmiş küçük RAID'ler muhtemelen değildir.

• muhtemelen özel yazılımınızı ayrı bir bölüme yerleştirmelisiniz (/ usr / local / bin vb. için bağlama noktası), böylece işletim sistemi güncellemeleri ve kök bölüm silme bezlerinde bunu koruyabilirsiniz. Aksi takdirde, işletim sistemi yükseltme / düzeltme / neyse, "özel" yazılım uygulamalarınızı yeniden kurmanız gerekebilir.

• Eğer sisteminizin yönetimi hakkında endişelenmek istiyorsanız, farklı bir soru soracağım: Bina yangına girdikten ve sunucular ve RAID kutuları imha edildikten sonra olağanüstü durum kurtarma süreci nedir? Önemsediğiniz veriler tamamen kafanızda kalmıyorsa, bu her kullanıcının kendi IT / sysadmin milletinden sorması gereken bir soru. Strateji, "ihtiyacımız olan donanımı nasıl çoğaltacağız" ve "tekrar çalışmaya başlamadan önce ne kadar zaman alacağımız" gibi soruları içermelidir. Sunucularınızı sanallaştırma hakkında bazı tartışmalar, donanım bağımlılıklarıyla ilgili sorunları çözmenize ve işletim sisteminizi yeniden yapılandırma gereği duymadan işleri yeniden başlatmanıza ve çalıştırmanıza yardımcı olabilir (değişmeyen "yumuşak" bir aygıt ortamında çalışacak şekilde yapılandırılabildiğinden,

• Benzer şekilde, kullanıcı verilerini program ve kullanıcı hata verisi kayıplarına karşı koruma stratejisinin ne olduğunu sormak isteyebilirsiniz. Boş bir dosyayı araştırma belgenizin gerçekten büyük taslağı üzerine kaydetmek veya kullanıcının yanlış komutu (örneğin rm -rf *) yazması, kesinlikle bir deprem veya yangın veya başka bir fiziksel hasar kadar veri kaybına neden olur. Bireysel dosya kurtarma çözümleri, toptan felaket kurtarma için en faydalı olanlardan biraz farklıdır (veya olabilir!).

-

Bu, işletim sistemini kullanıcı verilerinden bağımsız olarak yedeklemenizi, geri yüklemenizi veya yeniden yüklemenizi sağlar. Bu size özgürlük, bağımsızlık ve güvenlik sağlar.

1. Kullanıcı verilerinin mutlak çoğunluğunu koruyarak başka bir Linux dağıtımına geçmek çok daha kolaydır.

2. İşletim sistemi bölümünün yedeğini uygulayarak buggy güncellemelerini geri almak kolaydır (çift önyükleme gereklidir). Bu yedekleme daha da eski olabilir - bunu uygulayabilir ve daha sonra bilerek kararlı olan sürüme güncelleyebilirsiniz.

3. Son zamanlarda uygulanan "büyük yükseltme" işleminden hoşlanmıyorsanız, işletim sisteminin önceki sürümüne dönmek kolaydır (çift önyükleme gerekir).

Bu yaklaşımın en büyük potansiyeli için, çift önyüklemeyi de yapılandırmanız gerekir (ayrıca CentOS / CentOS da olabilir), böylece işletim sistemini diğerinden çalıştırırken bir işletim sistemi bölümünün üzerine yazabilirsiniz. Ve elbette, sistem bölümünü en az birkaç ayda bir yedeklemelisiniz.

Kısa cevabım, bir masaüstünün bile asla "büyük bir bölüm" kullanmaması gerektiğidir. Geçenlerde daha iyi bir karar vermeme rağmen denedim çünkü "sadece bir dizüstü bilgisayar" ve otomatik yükleyici tek bir bölüm kullanıyordu ve ben sadece düğmeyi tıklattım.

Farklı bir dağıtım kurmaya gittiğimde, sürücülerimi yeniden bölümlendirmem gerekti, çünkü yükleyici mevcut bir dağıtım üzerine kurulmayacaktı. Kendi bölümünüz varsa, evinizi / evinizi sağlam tutacaktır. Bu yüzden, gparted live-cd'yi başlattım ve bölümü küçülttüm, / home ve diğerleri için yeni bölümler oluşturdum, verilerimi yeni bölümlere taşıdım ve sonra da yeni işletim sistemi için kurucuya atladım.

İdeal olarak, bir SSD'yi koymak / oturtmak, / home'yu sabit sürücüye, / varsayı sabit sürücüye / usr, yükseltmeyi ne sıklıkta planladığınıza bağlı olarak bir SSD veya HDD'de olabilir. / tmp bir sabit sürücüye. Genelde mp3'ler ve filmler gibi paylaşılan medya dosyaları için / evimden kendisine eşlik eden başka bir bölüm yapıyorum. / Sbin'nin kökün bir parçası olduğunu ve / bin ve / root olduğunu unutmayın. Bu, / bin ve / usr / bin arasındaki fark, / usr, tüm sürücüleriniz monte edilinceye kadar kullanılamayacak şeylerdir, bu nedenle mount komutu / usr! Diğer linux dağıtımları için genellikle birkaç ekstra bölüm daha tutuyorum, sanki gerçekten kötü bir şeyi mahvettiğimde gparted olanı sabit diskimde duruyor, kurtarma çalışması için hazır başka bir canlı sistemim var.

Eşyaları taşımak zorunda kalabileceğiniz, dinamik olarak depolama alanı ekleyebileceğiniz ve sürekli olarak kalması gereken bir sunucu için, kesinlikle LVM kullanın !!!

/ Usr / local yazılımını kurmak zorunda değilsiniz, tüm yazılımları / home içinde olabilecek farklı bir önek olarak kurabilirsiniz. Çoğu yazılım bunu örneğin kaynaktan çalıştırarak, kaynaktan derlediğinizde yapabilir. ./configure --prefix=/home/bin

Bir biyolog olduğunuzdan, bir rpm veya deb'de düzgün bir şekilde paketlenmemiş olan bir çok yazılımla ilgileniyor olabilirsiniz ve yine de kaynaktan derlemeniz gerekecek.

Kullanıcılarımız arasında çok sayıda biyolog olan bir HPC sistemi için sysadmin'im, / apps / filesystem altında istedikleri tüm yazılımları yüklüyoruz, bu yüzden çoğu yazılım için bunu yapmanın mümkün olduğunu biliyorum. çok zor ol. Bu sorunu çözmek için meslektaşlarım ve ben EasyBuild (Free and open source) adlı bir araca yazı yazdık . Kaynaktan yazılım derleyip yükleyebilir ve farklı bir klasöre yükleyebilir ve sizin için otomatik olarak bir ortam modülü dosyası oluşturabilir. aslında aynı yazılımın 2 farklı sürümü yüklü olabilir ve herhangi bir çakışma olmaz.

Tek bir komutla kurabileceğimiz paket listemize bir göz atın , bir biyolog olarak bunların çoğunu tanıyabilirsiniz ;-)

Feragatname: Ben EasyBuild'in geliştiricisiyim

Genel olarak yeni başlayan / tanıtıcı * ix kullanıcısı için sistemin doğası hakkında daha fazla bilgi edinilene kadar en az bölüme sahip olabileceğini düşünüyorum. Ancak, bir nedenden ötürü sadece bir para cezasına sahip olamazsınız ve sizin durumunuzda efendim.

Bunun ilk ve daha genel olarak pratik nedeni, çoğu Linux Sisteminin bir takas bölümü gerektirmesidir (genellikle RAM * 1-2 * arasında olmalıdır) ayrıca ayrı bir sistem, önyükleme veya ev bölümleri gerektirir ve UEFI önyükleme linux sistemleri söz konusu olduğunda bir EFI bölümü (sadece 500 MB).

Durumunuza özellikle uygulanabilir olan ikinci sebep, 6x 300GB diskleri kullanmanın ve onları bir baskın 6 yapmasının, en azından, en uygun dizilimi yapmamasıdır. Her ne kadar yeni teknoloji, Raid 6'yı evrensel olarak daha iyi bir sistem olarak görüyor olsa da, şeritleme algoritması daha çok gereklidir ve bilgi depolamak için gereken alan (RAID 5 ile karşılaştırıldığında) daha büyüktür.

RAID 6'nın ek bir donanım parçası gerektirdiğinden bahsetmiyorum. Saygılarımla bence disk arızası, aksama süresi, felaket kurtarma veya ek teknik yardım masraflarından kaçınmak için daha büyük diskler satın almanız gerekir. Belki birçoğunun belki de benimle aynı fikirde olmayacağını biliyorum ve gelecek iki yıl boyunca disklerin daha büyük boyutta olduklarını (son birkaç fiyattan düşürdükleri için) RAID6’yı daha büyük diziler için büyük gelirli şirketler açık bir seçim olacaktır. Ancak bu durumda, RAID 6 kullanımını önermiyorum.

İkinci (RAID tabanlı olmayan) sorun için, yansıtıldığında dev bir bölüm oluşturmak sizin için işe yarayabilir, ancak verimliliği en üst düzeye çıkarmak için daha büyük sürücüler ve çoklu bölümler kullanın. Bu şekilde, bir çift disk arızanız varsa, / dev + / dir'ye bağlı olarak belirli bağlanma noktalarında veya çok az zamanınız olmaz.

En azından / sys'inizin (sistem, çekirdek vb.) Ayrı çalışmasını sağlayın, böylece herhangi bir nedenden dolayı çekirdeğiniz önyüklememeye karar verirseniz, basitçe bir kurtarma çekirdeği, uzaktan önyükleme veya PXE, disk önyüklemesi vb. d-recovery işlemi gerçekleşirken bilgilerinize geniş erişim.

Sisteminiz çalıştığı sürece şirketiniz bu aksanları umursamıyor olabilir ama insanların neden bir şeyler yaptığını açıklamaya çalışıyorum. Aynı zamanda diğerlerinden daha fazla duymayı, bu tartışmaya karşı ve bu tartışmaya karşı çıkmayı ve diğer noktaları yükseltmeyi çok isterim. Kabul etmiyorsan, nedenini söyle. Afiş-- Size bazı linkler de vereceğim.

Linux Topluluğumuza Bir Aşk Spencer Reiser

PS Özellikle, halka açık olan ağ sunucularında veya sistemlerde, kimlik bilgileriyle olsa bile, bölümlerinizi ayırmanız gerçekten en iyisidir. Diğerleri buraya daha fazla girebilir, daha çok kahveye ihtiyacım var.