Bana bölümleme sat


46

Özellikle Unixy OS'lerde (/ usr, / var, et al) neden bölümleme sürücülerine böyle bir tutku olduğunu sık sık merak etmişimdir. Bu, Windows kurulumlarında yaygın bir tema olarak görünmemektedir.

Bölünmenin, bir bölümün doldurulma olasılığını büyük oranda arttırdığı, diğerlerinde ise çok fazla boş alan olduğu görülüyor. Açıkçası bu, dikkatli tasarım ve planlama ile önlenebilir, ancak işler değişebilir. Bu makinelerde birçok kez, çoğunlukla başkalarının kurulumlarında veya söz konusu işletim sisteminin varsayılan kurulum ayarlarında yaşadım.

Duyduğum başka bir argüman yedeklemeyi kolaylaştırdığıdır. Yedeklemeyi nasıl kolaylaştırır? Ayrıca güvenilirliği arttırdığını da duydum. Yine nasıl?

Disk depolama ile karşılaştığım sorunların neredeyse% 100'ü diskin fiziksel arızası ile ilgili. Verileri bir diskten aynı diskteki bir bölümden diğerine taşırken veya kopyalarken bir diskin düşmesi nedeniyle, bölümlemenin donanım arızasını potansiyel olarak hızlandıracağı iddia edilebilir mi?

Tekneyi çok fazla sallamaya çalışmıyorum, sadece asırlık bir yönetici uygulamasının gerekçesini görmek istiyorum.


Altyapıda Bir Hizmet bulutu olarak, bölümler değişkendir çünkü sürücüler (genellikle birimler denir) bu kadar esnek bir şekilde takılabilir.
Skaperen

Yanıtlar:


41
  • Daha hızlı fsck. Diyelim ki sisteminiz başarısız olmuş, nedense ve yeniden başlatıldığında fsck çalıştırması gerekiyor. Fsck sonsuza kadar sürebilir ve büyük bir bölümü ile tüm sistem fsck bitene kadar sistemde hiçbir şey işe yaramaz. Sistemi böylesine küçük bir bölüme bölüştürürseniz, daha büyük birimlerin fsck'lerinin tamamlanmasını beklerken sistemi çalıştırabilir ve bazı temel hizmetleri çalıştırabilirsiniz.
    • Sisteminizde küçük sürücüler varsa veya sistemde yalnızca bir servis varsa, bu gerçekten önemli olmayabilir.
    • Günlüklü dosya sistemlerinde bu çoğu zaman önemli olmayabilir, ancak bazen günlüklü bir dosya sisteminde bile tam bir fsck çalıştırmanız gerekir.
  • Gelişmiş güvenlik, çünkü bir salt okunur takabilirsiniz.
    • Örneğin, normal kullanım sırasında hiç kimsenin / usr 'a yazması gerekmez. Öyleyse neden sadece dosya sistemini takmıyorsunuz? Dosya sistemlerini salt yazmak zorunda olmadıklarında salt okunur duruma getirmek, bazı kod-çocuk saldırıları önler ve siz de istemediğiniz zaman şeyleri imha etmenizi önler.
    • Bu, sistemi korumayı zorlaştırabilir, çünkü güncellemeleri uygulamanız gerektiğinde okuma yazma olarak yeniden ayarlamanız gerekir.
  • Geliştirilmiş performans, belirli bir servis / kullanım için işlevsellik.
    • Bazı dosya sistemleri, belirli servisler / uygulamalar için daha uygundur veya bazı durumlarda daha iyi çalışabilmesi için dosya sistemini yapılandırmanıza izin verir. Belki çok sayıda küçük dosya içeren bir dosya sisteminiz vardır ve daha fazla inode'a ihtiyacınız vardır. Ya da belki büyük bir kaç büyük dosyayı, sanal disk görüntüsünü saklamanız gerekir.

Çok fazla bölüm oluşturmanın her sistem için yapmanız gereken bir şey olduğunu sanmıyorum. Şahsen, çoğu Linux'ta sunucularımdan yalnızca büyük bir bölüm oluşturdum. Çünkü sistemlerimin çoğu ufacık sürücülere sahip ve tek amaçlı ve bazı altyapı rolleri (dns, dhcp, güvenlik duvarı, yönlendirici vb.). Dosya sunucularımda verileri sistemden ayırmak için bölümler oluşturuyorum.

Verileri bir diskten aynı diskteki bir bölümden diğerine taşırken veya kopyalarken bir diskin düşmesi nedeniyle, bölümlemenin donanım arızasını potansiyel olarak hızlandıracağı iddia edilebilir mi?

İyi bölünmüş bir sistemin herhangi bir başarısızlık ihtimalinin artmış olacağından şüpheliyim.


9
+1 Hem güvenlik hem de felaket hazırlığı katmanlarda yapılır. Bir gemideki bölmelere benzer bölümleri düşünmeyi seviyorum. Oradalar, böylelikle geminin bir bölümünde yıkıcı bir şey olursa, geminin bir bütün olarak risk altında olması gerekmez. Yani dosya sistemi bozulma meydana geldiğinde zarar biraz içerdiği. Aynı şekilde, eğer / evler noexec olarak monte edilirlerse, güvenlik açısından, eğer bir kullanıcı hesabının zayıf bir parola ile ele geçirilmesi durumunda, belirli türden saldırıları önleyebilir.
3dinfluence

1
Sadece noexec veya ro ile monte edilmiş bölümlerde çalışan bilinen istismarlar vardır . gerçek güvenlik bölümlendirme tarafından amaçlanmamıştır, ancak bölümleme hasarın sınırlandırılmasına yardımcı olabilir (cfr. örneğin sel saldırısı kaydeder)
drAlberT

19

/ Home / ayrı tutulmasının bir nedeni, işletim sistemini yeniden yükleyebilmeniz ve kullanıcı verilerini kaybetmekten endişe etmemektir. Bunun ötesinde, her şeyi salt okunur veya noexec'e yerleştirmede çok fazla güvenlik var. Kullanıcılar kod yazabilecekleri herhangi bir yerde kod çalıştıramazlarsa, bu bir daha az saldırı vektörüdür.

Bununla birlikte, yalnızca bir makinede, bir bölümdeki disk alanının tükenmesinin dezavantajı ancak bir başkasında olması ciddi bir sıkıntı olduğu için uğraşırdım. Bunun için, bölümleri kolayca dinamik olarak yeniden boyutlandırabileceğiniz yazılım baskını veya ZFS yapmak gibi yöntemler vardır, ancak onlarla deneyimim yok.


/ home'un ayrılması, bir masaüstü bilgisayarından daha fazlası gibi görünür. Sunucularda veriler sıklıkla / var / www, / srv gibi başka bir yerde bulunur. Fikrinizin, yalnızca / evdeyken değil, depolandığı her yerde kullanıcı verilerini ayırma konusunda daha fazla olması gerektiğini savunuyorum.
Zoredache

Bilimsel işlemede kullanılan makinelerde, çok sayıda insanın kabuk hesabına sahip olması yaygındır. Bu durumda, ayrı bir / ev bölümü oldukça faydalı olabilir.
jay_dubya

Kayda değer sayıda makineniz varsa, / home, yukarıda belirtilen sorunlar nedeniyle / home, kendi bölümünde mantıksal olarak / home'a ​​sahip bir dosya sunucusundan NFS montajı olma sıklığıdır.
Matt Simmons

Kullanıcılar çoğu zaman tüm kullanılabilir alanları kullanır ve bu bir sunucu tarafından sağlanan servislere felaket olabilir. Yalnızca ayrı bir bölüme yazmalarına izin vermek, sunucuyu tam bir kök bölümü nedeniyle başarısızlığa karşı korur. Günlük dosyalarınızı ayrı bir bölüme koymak da aynı şeyi yapar.
Chris Nava

Disk kotaları ve log döndürmelerinin uzay sorununa daha iyi bir çözüm olduğunu düşünüyorum, ancak ayrı bölümler son çare güvenlik mekanizmasını güzel bir hale getiriyor
yarı

13
  • Yedeklemeyi basitleştirme

İstediğiniz şeyleri (dumpfs veya benzerleri aracılığıyla) istemediğiniz şeylerin yedeğini alabilirsiniz. dökümü (1), katrandan (1) daha iyi bir yedekleme sistemidir.

  • Bölümleri dolduruyor

Bu da bölümleme için bir argüman. Kullanıcılar ana sayfalarını dolduruyor, sunucuyu mahvetmiyor, web sunucusunu kapatmıyor, günlüklerin oluşmasını engelliyor, kök giriş yapmıyor, vb.

Ayrıca, verilerinizin bir bölümünü (/ / örneğin) başka bir diske daha şeffaf bir şekilde taşımanıza olanak tanır: kopyalayın, takın. Gölge kopyalara / anlık görüntülere / her şeye izin veren bir şey kullanıyorsanız, canlı olarak bile yapabilirsiniz.


9

Her zaman ayrı bir bölümde tutmam / değiştirmem öğretildi, bu nedenle kontrol dışı bir günlük dosyası alırsanız sürücünün tamamı değil tek bir bölümü tıkayacaksınız. Sistemin geri kalanıyla aynı alandaysa ve diskinizin% 100'ünü doldurursanız, çökebilir ve kötü bir geri yükleme yapabilir.


1
Bir yandan, 15 yıl boyunca (ne? Öyle değil!) Kariyerimde bir sistemi kaybettiğimde kaçtığım için güvenebilirim çünkü run-away bir günlük dosyası (veya her neyse) bir makineyi kapattı. Öte yandan, bu yıl şu ana kadar kaç kez stymied oldum çünkü birisinin asla 1GB’den daha büyük olmaya karar vermeyeceği ve yanlış olduğu için 005’e kadar serbest bırakmaya karar verdim. GB in / opt, ki hepsi de bana yaptıkları iyilikler için ayda olmuş olabilir. (Bölümlemeye
karşıyım

Hem Linux hem de Windows makineleriyle aynı deneyimleri yaşadığı için David ile aynı fikirdeyim. Aksi taktirde zorlayıcı bir sebep olmadıkça, her disk (veya baskın dizisi) bir bölüm alır.
John Gardeniers

Eh, bu hafta finnaly bir Windows sisteminde oldu. McAfee büyük bir güncelleme yayınladı. Bundan hoşlanmayan yaklaşık 5-10 sistemimiz vardı. Anti-virüs kurmaya, 35 MB günlük dosyası oluşturmaya ve tekrar denemeye çalışır. 1,500 kez sonra 0KB ücretsiz ve giriş yapamadığım bir sistem vardı.
Skaughty

8

Zoredache’ın öne sürdüğü tüm argümanlar geçerlidir; biri ayrıntılarla biraz başa çıkabiliyor (bir makineyi daha hızlı çalıştırmak, böylece diğer dosya sistemlerini fsck'lemek, sistemin ilk etapta var olmasının sebebi bu diğer dosya sistemlerinde ise çok işe yaramaz). ; Bununla birlikte, hepsi gerçekten biraz haklı çıkar.

Gerçekten eski okul günlerinde, ayrı bölümlerde dosya sisteminiz yoktu - diskleri ayrı diskler üzerine yerleştirdiniz, çünkü diskler gerçekten çok küçüktü. 10 MB'ı düşünün. (1) Böylece küçük / bölüm, a / var disk, / usr disk, a / tmp disk ve a / home diskiniz oldu. Daha fazla alana ihtiyacınız varsa, başka bir disk satın aldınız.

Ardından "büyük" 50 MB'lık diskler ay programından daha düşük maliyetli olmaya başladılar ve birdenbire tüm sistemi kullanılabilir bir kullanıcı alanı olan tek bir diske koymak mümkün oldu.

Yine de, disk boyutları bilgisayarın üretilebildiğine kıyasla küçük olduğundan, / var ve / opt ve / home'u yalıtmak, böylece doldurma bilgisayarı aşağıya çekmemenin hala iyi bir fikir olduğunu belirtti.

Bugün, bir işletme durumunda, işletim sistemlerini bölümlendirmiyorum. Veriler, özellikle kullanıcı tarafından oluşturulmuşsa bölümlenir; fakat bunun nedeni çoğu zaman yüksek hızlı ve / veya fazladan disk dizilerinde olmasıdır. Bununla birlikte, / var ve / usr, / ile aynı bölümde yaşıyor.

Bir ev ortamında, aynı şey - / home muhtemelen ayrı bir diskte / dizide olmalıdır, böylece işletim sistemi lezzetleri ne istenirse yüklenebilir / yükseltilebilir / bozulabilir / düzeltilebilir.

Bunun nedeni, / var veya / usr'nız ne kadar büyük olursa olsun veya ne tür bir ağaç alacağınız önemli değildir - ya komik bir şekilde yanlış olacaksınız ya da gülünç bir şekilde aşırı bağlı kalacaksınız. Eski (l) okul kolejlerimden biri bölümlere ayırdığına yemin ediyor ve yarattığım bir sistemde 180 günlük bir süreçle oturduğunda hep ondan keder duyuyorum. Fakat bir yandan bir yandan tüm kariyerim boyunca bir şeyin ne kadar doldurulduğunu / ve sistemin ne kadar yıkıldığını, bir yandan da bu yıl o zamana kadar birisinin sayılabildiğini ve birinin çalıştığı bir sisteme baktığımı sayabiliyorum. karar verilmiş / var hiçbir zaman 1GB'tan fazla (yani) 1GB'tan fazla olmayacaktı ve yanılmış oldu, beni her şey için de ayın içinde olabilecek tam / var ve '00'larda serbest GB'lere bakıyordu. iyi onlar beni yapıyor.

Günümüzün büyük disk dünyasında, işletim sistemi ağacını bölmek için herhangi bir gerçek neden olduğunu görmüyorum. Kullanıcı verileri, evet. Ancak / var ve / usr ve / var / spool etc vs etc için ayrı bölümler var mı? Hayır.


(1) = ve sadece bu büyüklüğü seçerek biliyorum, yorumlarda 10 MB diyen birini bulacağım ? Lüks. Neden disklerimiz sadece ...


": Ne olacak daha fazla bellek XXX FooBytes Aslında 10 MB disk boyutu şimdiye kadar birileri duydu ilk kez hiç ! Gerek." Her ne kadar bir gencim olsa da, bu 1982 dolaylarındaydı. Diğer değerler 40 MB, 320 MB, 2,5 GB, 40 GB olmuştur ... veriler mevcut depolamayı doldurmak için genişler.
dmckee

5

Buna cevap olarak:

Bölünmenin, bir bölümün doldurulma olasılığını büyük oranda arttırdığı, diğerlerinde ise çok fazla boş alan olduğu görülüyor.

Bir Linux makinesinde, bunu önlemek için LVM (mantıksal ses yönetimi) kullanılır. Çoğu dosya sistemi yeniden boyutlandırmaya izin verir (bazıları çevrimiçi bile). Farklı kullanımlar için farklı bölümler oluşturuyorum ve bunları farklı dosya sistemlerine biçimlendiriyorum (yani: hızlıca silebileceğim büyük indirme dosyaları için xfs). Daha fazla alana ihtiyaç var? Yeni bir sürücü takın, verileri ona taşıyın, sonra verilerin olduğu yere bağlayın. Kullanıcılar ve uygulamalar için tamamen sorunsuz.

LVM ile, birim grubuna diskler veya bölümler ekleyebilir, ardından o grupta mantıksal birimler oluşturabilirsiniz. Birim grubunda boş yer bırakırsanız, daha sonra doldurulan bölümleri büyütebilirsiniz. Dosya sistemi destekliyorsa (ext3, ext4, reiserfs), üzerinde tahsis ettiğiniz bir bölümü küçültebilirsiniz.

Örneğin: / dev / sda1 üzerinde bir önyükleme bölümü yapın, ikinci (biçimlendirilmemiş) bir bölüm / dev / sda2 yapın

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

/ İndirme işlemlerinde daha fazla alana ihtiyaç duyduğunuzda (dosya sistemi monte edilmişken):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

Ve şimdi 150GB indirme bölümünüz var. Ev için benzer. Aslında bugün sadece ext4 lvm "bölüm" yeniden boyutlandırdı. Öte yandan, mantıksal ciltler gerçekten bölümler değildir ve bölümler sizin kişisel deneyimlerime göre yanlış büyüklükteki jöleler (söylediklerinden daha fazla sorun).


4

Geleneksel Unix bölümlendirme şeması kesinlikle eskisi kadar kullanışlı olmayan eski bir okul uygulamasıdır. Unix sistemi çalışma süresinin yıllarca ölçüldüğü güne ve kabukları ile dolaşıp dolaşan onlarca yüzlerce kullanıcınız olduğu zaman, sistemi salt okunur olarak takmak / kullanmak ustaydı. Şimdi yama yapmak için dosya sistemlerini yeniden monte etmek daha emek yoğun ve pek kullanışlı değil gibi görünüyor.

Eski zamanlardaki üniversitemde Unix kümeleri, standart unix araçlarıyla salt okunur bir dosya sistemine sahipti ve eklenti uygulamaları bir NFS ve daha sonra bir AFS dosya sistemi olan / usr / local konumundaydı. Bunun bir kısmı kolaylık oldu ... yüksek hızda, 4Mb veya 10Mb bir ağ üzerinden uygulamalar çalıştırabildiğiniz zaman kümedeki bir düzine kutudaki yazılımı tekrar derlemek isteyen? Bugün, iyi paket yöneticileri ve çok sayıda ucuz diski olan bu kadar önemli değil.

Düşünce süreçleri benim için Sun box'larda Veritas Volume Manager ile 1999 yıllarında değişmeye başladığını ve bu sayede disklerin etrafındaki dolaşımın önemli ölçüde azaldığını düşünüyorum.

Bugün, bölümlemeyi düşündüğümde veri koruması ve performans açısından düşünüyorum. Açıklayıcı örnek:

  • Tier 1 SAN çok hızlı, çok uygun (5 9), çoğaltılmış ve çok pahalı. Görev kritik Veritabanları veya işlem günlükleri orada yaşıyor.
  • Tier 2 SAN hızlı, kullanılabilir (4 9), pahalıdır. Uygulamalar veya daha düşük öncelikli veriler burada yaşar.
  • Tier 3 SAN ucuzdur (4 9). Performansa duyarlı olmayan şeyler orada yaşıyor.

Bu düşünceler Windows için de geçerlidir. 40 bin civarında müşteriyi yöneten bir SCCM sunucumuz var. Veri tabanı ve kayıtlar IBM DS8000 diskinde mega bulunur. Yazılım paketleri, GB başına% 60 daha düşük maliyetli, büyük, yavaş SATA diskli bir EMC Celerra'da bulunur.


2

Bu sorunun işletim sistemine özgü olmadığını anladım, değil mi?

Windows altında, tüm makinelerime mümkün olduğunca az bölüm, ancak ikiden az olmamak üzere eğilim gösteriyorum - SYSTEM ve DATA. Makine iki fiziksel diske sahipse, biri (daha küçük) SİSTEM, diğeri DATA olacaktır. Sadece bir disk varsa, onu iki bölüme ayırdım.

Bunun nedeni sadece bir tane - makineyi yeniden yüklemem gerektiğinde (ve böyle bir zaman olacak), SİSTEM bölümünün içeriği hakkında endişelenmeme gerek yok - sadece tam bir format yapıyorum ve temiz kurulum. Elbette bu, Belgelerimin (ve tercihen Masaüstü'nün de) DATA'daki bir klasörle eşleştirilmesi gerektiği, ancak özellikle Vista ve sonraki sürümlerinde yapılması kolay bir işlem olduğu anlamına gelir.

Daha fazla partitons yapmayı da (GAMES, MUSIC, MOVIES, vb.) Yapmaya çalıştım ama bu sadece bazılarının başkalarına taşmasına ve düzenden daha fazla karmaşa yaratmasına neden oldu.


Bu sunucularda yaparken daha da geçerlidir.
SpaceManSpiff

2

Ben koymak (tek büyük bir disk kullanılabilir varsayarsak) homeve varayrı bölümlere "kontrol [kullanıcı | log dosyası] uygulamasından tüm uzay dolduruyor" kontrol etmek sorunu ve dokunaklı evsiz kolay bir işletim sistemi yükseltmeleri izin vermek, ama bırakın birlikte dinlen.

Eski donanımlarda boot, çekirdek görüntünün önyükleyici için erişilebilir olduğundan emin olmak için ayrı bir bölüme sahip olmak gerekliydi .


2

Nedenleri Ben bölümünün biri - - O belli bölümleri sağlayabilirsiniz çünkü diğer boş alan varken tek bir diskin dolum söz yok doldurmak. Kontenjanların yönetilme şekli eskiden olmasına rağmen, tüm kullanıcılara diğer bölümlere 0 kota atamanız gerekir, sadece bir dizin bulmayı başardıklarında dosyaları gizlemeye başlamadıklarından emin olmak için yazabilir.

Yedeklemeyi basitleştirmeye gelince - her bölümün maksimum boyutunun ne olacağını biliyorsanız, tek bir kasete düzgün şekilde sığacak ve sabit bir sürede tamamlanabilecek bir boyut olduğundan emin olabilirim.

Güvenilirliğe gelince, düşünebildiğim tek şey izlemektir - belirli bir bölümün olması gerekenden daha fazla büyüdüğünü daha kolay görebilirim ve bana bakmam için sebep verebilirim.

... şimdi, bunların hepsi söyleniyor, paylaşılan bir makinede her 20 MB'lık küçük kota verildiği günlerden çok uzaktayız. Eski alışkanlıklardan bazıları bir anlam ifade etmiyor - ama bir süreciniz çılgınca ve doldur / değişiyor, ki bu da bunları dolduruyor / dolduruyor ve işler durma noktasına geldiğinde, üretim makinelerinde bu kadar kötü bir koruma söz konusu değil. .

Ev için bölümlerim var, ancak yalnızca kurulu işletim sistemlerini yönetmeyi kolaylaştırmak için.


1

Şahsen ben sadece çocuğumun bilgisayarlarında bölümleme kullanıyorum. İşletim sistemi için büyük bir bölüm ve işletim sistemi bölümünün görüntüsü için küçük bir bölüm oluşturuyorum; böylece makine tıkandığında hızla görüntüden geri yükleyebilirim.

Bir kurumsal ortamda, bölümleme için zorlayıcı bir argüman hiç duymadım.


1

Denetimdeki her şey iyi bir şeydir - bir hata olduğunda sorunları izole etmek için iyi bir araç olabilir - disk doldurma veya dosya sistemi bozulması gibi.

Donanım arızasıyla karıştırmayın - bunlar donanım yedekliliği (RAID) ile ele alınmalıdır

Bu günlerde dosya sistemlerinin daha az başarısız olduğunu söylemiştik - hatta çevrimiçi bütünlük kontrolleri bile yapılıyor (ZFS gibi). Yani umarım çevrimdışı fsck bir noktada ortadan kalkar ...

Öte yandan, bunun aşırı yapılması sadece sonunda (sizin ve ekibiniz için) daha fazla iş anlamına gelir - sadece ölçülü olarak yapın ve mantıklı olduğunda ...

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.