Vraag Verkoop partities aan mij


Ik heb me vaak afgevraagd waarom er zo'n passie is voor het partitioneren van schijven, vooral op Unixy-besturingssystemen (/ usr, / var, et al). Dit lijkt geen veel voorkomend thema te zijn bij Windows-installaties.

Het lijkt erop dat partitionering de kans op het vullen van een partitie enorm vergroot, terwijl andere ruimtes veel vrije ruimte hebben. Uiteraard kan dit worden voorkomen door zorgvuldig ontwerp en planning, maar dingen kunnen veranderen. Ik heb dit vaak op machines ervaren, meestal op apparaten die door anderen zijn ingesteld, of op de standaardinstallatie-instellingen van het besturingssysteem in kwestie.

Een ander argument dat ik heb gehoord, is dat het de back-up vereenvoudigt. Hoe vereenvoudigt het de back-up? Ik heb ook gehoord dat dit de betrouwbaarheid verbetert. Nogmaals, hoe?

Bijna 100% van de problemen die ik ben tegengekomen met schijfopslag is met fysiek falen van de schijf. Zou het kunnen worden beargumenteerd dat partitionering potentieel hardwarefouten kan versnellen, vanwege de dreun die een schijf doet bij het verplaatsen of kopiëren van gegevens van de ene naar de andere partitie op dezelfde schijf?

Ik probeer de boot niet te veel te laten schommelen, ik wil gewoon een rechtvaardiging zien voor een eeuwenoude admin-praktijk.


45
2017-09-01 19:19


oorsprong


In Infrastructure As A Service cloud zijn partities moeilijk omdat schijven (meestal volumes genoemd) zo flexibel kunnen worden aangesloten. - Skaperen


antwoorden:


  • Snellere fsck. Laten we zeggen dat uw systeem om de een of andere reden faalt en wanneer het opnieuw opstart, moet het een fsck uitvoeren. Met een echt grote partitie die fsck voor altijd kan duren en niets op het systeem zal werken totdat het fsck van het hele systeem is voltooid. Als u het systeem partitioneert, zodat de rootpartitie vrij klein is, kunt u mogelijk het systeem opstarten en een aantal basisservices uitvoeren terwijl u wacht totdat de fsck van de grotere volumes is voltooid.
    • als uw systeem kleine schijven heeft, of als er maar één service op het systeem is, dan doet dit er misschien niet zo toe.
    • Met gejournaliseerde bestandssystemen maakt dit misschien niet altijd uit, maar af en toe, zelfs met een journaled bestandssysteem, moet je een volledige fsck uitvoeren.
  • Verbeterde beveiliging omdat u een fs alleen-lezen kunt aankoppelen.
    • Niemand hoeft bijvoorbeeld tijdens normaal gebruik naar / usr te schrijven. Dus waarom niet gewoon het bestandssysteem aankoppelen zodat het alleen-lezen is. Als bestandssystemen alleen-lezen zijn wanneer ze niet hoeven te worden geschreven, worden sommige script-kiddy-aanvallen voorkomen en wordt voorkomen dat je dingen vernietigt als je dat ook niet wilt.
    • Dit kan het onderhoud van het systeem bemoeilijken, omdat je het opnieuw moet koppelen als lees-schrijf wanneer je updates moet toepassen.
  • Verbeterde prestaties, functionaliteit voor een specifieke service / gebruik.
    • Sommige bestandssystemen zijn meer geschikt voor specifieke services / toepassingen, of ze laten je toe om het bestandssysteem zodanig te configureren dat het in sommige gevallen beter werkt. Misschien heb je een bestandssysteem met veel kleine bestanden en heb je meer inodes nodig. Of misschien moet u grote enkele grote bestanden, virtuele schijfimages, opslaan.

Ik denk niet dat het opzetten van veel partities iets is dat je voor elk systeem zou moeten doen. Persoonlijk installeer ik op de meeste Linux-servers gewoon één grote partitie. Omdat de meeste van mijn systemen nogal wat drives hebben en slechts één doel hebben en een bepaalde infrastructuur-functie hebben (dns, dhcp, firewall, router, enz.). Op mijn bestandsservers stel ik partities in om de gegevens van het systeem te scheiden.

Zou je kunnen zeggen dat partitionering   kan mogelijk de hardware versnellen   falen, vanwege de dreun a   schijf doet bij het verplaatsen of kopiëren van gegevens   van de ene partitie naar de andere op de   dezelfde schijf?

Ik betwijfel ten zeerste of een goed gepartitioneerd systeem een ​​grotere kans op mislukken heeft.


40
2017-09-01 19:28



+1 Zowel beveiliging als voorbereiding op rampen worden in lagen uitgevoerd. Ik denk graag aan partities die lijken op schotten in een schip. Ze zijn er zo dat als er iets catastrofaals gebeurt in één segment van het schip, het schip als geheel niet noodzakelijkerwijs in gevaar is. Dus wanneer het bestandssysteem corrupt is, is de schade enigszins beperkt. Ook vanuit het oogpunt van beveiliging als / homes is gemount als noexec kan het bepaalde soorten aanvallen voorkomen als een gebruikersaccount bijvoorbeeld wordt gehackt door een zwak wachtwoord. - 3dinfluence
Er zijn bekende exploits die werken enkel en alleen op partities gemonteerd met noexec of ro. echte beveiliging is niet gericht op partitionering, maar partitionering kan helpen bij beperking van schade (zie bijvoorbeeld de aanval op een overstroming) - drAlberT


Een reden om te behouden / thuis / apart is dat u het besturingssysteem opnieuw kunt installeren en u nooit zorgen hoeft te maken over het verliezen van gebruikersgegevens. Buiten dat, is er veel beveiliging te krijgen bij het monteren van alles, hetzij alleen lezen, of noexec. Als gebruikers nergens code kunnen uitvoeren die ze code kunnen schrijven, is het een minder aanvalsvector.

Ik zou me daar echter alleen mee bezighouden op een openbare machine, want het nadeel van het tekortschieten van schijfruimte in de ene partitie, maar het hebben van de andere partitie is een serieuze ergernis. Er zijn manieren om dit te omzeilen, zoals het doen van software-raid of ZFS, waarbij je de grootte van partities eenvoudig dynamisch kunt wijzigen, maar ik heb er geen ervaring mee.


19
2017-09-01 19:33



de scheiding van / home klinkt als iets van een desktop-ding. Op servers staan ​​gegevens vaak op een andere locatie zoals / var / www, / srv. Ik zou willen beweren dat je idee meer moet gaan over het scheiden van gebruikersgegevens overal waar het is opgeslagen, niet alleen als het in / home is. - Zoredache
op machines die worden gebruikt voor wetenschappelijke verwerking is het gebruikelijk dat een groot aantal mensen shell-accounts hebben. In dit geval kan een aparte / home-partitie best handig zijn. - jay_dubya
Als je een aanzienlijk aantal machines hebt, komt het vaak voor dat / home een NFS-mount is van een fileserver, die logisch gezien / home is op zijn eigen partitie, vanwege de bovengenoemde problemen. - Matt Simmons
Gebruikers zullen vaak alle beschikbare ruimte gebruiken en dit kan catastrofaal zijn voor de diensten die door een server worden geleverd. Alleen toestaan ​​dat ze schrijftoegang tot een afzonderlijke partitie hebben, beschermt de server tegen mislukken vanwege een volledige rootpartitie. Je logbestanden op een aparte partitie plaatsen doet hetzelfde. - Chris Nava
Ik denk dat schijfquota en logrotaties een betere oplossing zijn voor het ruimtevraagstuk, maar afzonderlijke partities maken een mooi laatste veiligheidsmechanisme - semi


  • Back-up vereenvoudigen

Je kunt back-ups maken (via dumpfs of iets dergelijks) van dingen die je wilt, niet dingen die je niet wilt. dump (1) is een beter back-upsysteem dan tar (1).

  • Partities vullen

Dat is ook een argument voor partitionering. Gebruikers die hun homedirs vullen, slopen de server niet, nemen de webserver niet mee, houden logboeken bij, houden root van inloggen, enz.

Het biedt je ook de mogelijkheid om een ​​deel van je gegevens (zeg, / home) op een andere schijf op een andere manier te verplaatsen naar een andere schijf: kopieer deze, mount hem. Als je iets gebruikt dat schaduwkopieën / snapshots / wat dan ook toestaat, kun je dat zelfs live doen.


13
2017-09-01 19:43





Ik heb altijd geleerd om / var op een aparte partitie te houden, dus als je een onbeheerst logbestand krijgt, verstop je een enkele partitie en niet de hele drive. Als het zich op dezelfde plek als de rest van het systeem bevindt en u 100% uw hele schijf vult, kan het uitvallen en voor een vervelende restore zorgen.


9
2017-09-01 23:25



Ik kan in mijn 15-jarige loopbaan (het aantal keer dat ik het niet waar is!) Een aantal keer rekenen op het feit dat ik een systeem heb verloren omdat een logbestand (of wat dan ook) een computer heeft weggehaald. Aan de andere kant kan ik het aantal keren dat ik dit jaar tot nu toe heb gerekend, hebben vastgehouden omdat iemand had besloten dat / var nooit groter dan 1 GB hoefde te zijn en niet goed was, waardoor ik naar '00s of free' keek GB in / opt, dat had net zo goed op de maan kunnen zijn voor al het goede dat het mij biedt. (Ik ben tegen partitionering. :) - David Mackintosh
Ik ben het met David eens, omdat ik precies dezelfde ervaringen heb gehad met zowel Linux- als Windows-machines. Tenzij er een overweldigende reden is om iets anders te doen, krijgt elke schijf (of RAID-array) één partitie. - John Gardeniers
Nou, deze week gebeurde het uiteindelijk op een Windows-systeem. McAfee heeft een grote update uitgebracht. We hadden ongeveer 5-10 systemen die er niet van hielden. Het antivirusprogramma zou proberen te installeren, een 35 MB logbestand maken en het opnieuw proberen. 1500 keer later had ik 0 KB gratis en een systeem waarop niet kon worden ingelogd. - Skaughty


Alle argumenten die Zoredache naar voren brengt, zijn geldig; men kan een beetje met de details kibbelen (een machine sneller hebben zodat je andere dingen kunt doen terwijl fsck'ing andere bestandssystemen niet veel goed doet als de reden van het systeem om in de eerste plaats te bestaan ​​op die andere bestandssystemen is) ; maar ze zijn allemaal een beetje een rechtvaardiging-na-het-feit.

Op echt oude dagen had je geen bestandssystemen op afzonderlijke partities - je had ze op aparte schijven, omdat de schijven erg klein waren. Denk aan 10MB. (1) U had dus een klein / partitie, een / var-schijf, een / usr-schijf, een / tmp-schijf en een / home-schijf. Als u meer ruimte nodig had, kocht u een andere schijf.

Toen begonnen "grote" 50MB-schijven minder dan het maanprogramma, en opeens werd het mogelijk om een ​​volledig systeem op één schijf te plaatsen met een bruikbare hoeveelheid gebruikersruimte.

Toch waren de schijfformaten klein in vergelijking met wat de computer kon genereren, isoleren / var en / opt en / home zodat het vullen van een computer de computer nog steeds niet ten goede kwam.

Tegenwoordig partitioneer ik de besturingssystemen niet in een bedrijfssituatie. Gegevens worden gepartitioneerd, vooral als dit door de gebruiker wordt gegenereerd; maar vaak komt dat omdat het op hoge snelheid en / of redundante schijfarrays van een of andere soort is. Echter / var en / usr leven allemaal in dezelfde partitie als /.

In een thuisomgeving zou hetzelfde ding / home waarschijnlijk op een aparte schijf / array moeten staan, zodat men elke gewenste OS-smaak kan installeren / upgraden / breken / repareren.

De reden hiervoor is dat het niet uitmaakt hoe groot je ook je / var of / usr of welke boom dan ook zou kunnen raden - je zult ofwel hilarisch verkeerd zijn of je zult belachelijk te veel committeren. Een van mijn oude (re) school collega's zweert door te partitioneren, en ik krijg altijd verdriet van hem wanneer hij door een 180-dagen-fsck zit op een systeem dat ik heb gemaakt. Maar ik kan aan mijn hele carrière rekenen op het aantal keren dat iets is opgevuld / en het systeem heeft verlaagd, terwijl ik het aantal keren tot nu toe dit jaar kan tellen dat ik naar een systeem sta te kijken waar iemands besliste / var zou nooit meer dan (zeg) 1GB hoeven te zijn en had ongelijk, waardoor ik naar een volledige / var en '00s van gratis GB elders op het systeem staarde, die allemaal net zo goed op de maan konden zijn voor iedereen het goede doen ze mij.

In de wereld van grote schijven van tegenwoordig zie ik niet dat er een echte reden is om de OS-structuur te partitioneren. Gebruikersgegevens, ja. Maar aparte partities voor / var en / usr en / var / spool etc etc etc? Nee.


(1) = en ik weet gewoon door die maat te kiezen, ik ga iemand in de comments laten zeggen 10 MB? Luxe. Waarom onze schijven slechts ...


8
2017-09-01 22:27



Eigenlijk was 10 MB de grootte van de schijf de eerste keer dat ik ooit iemand hoorde "XXX FooBytes: meer geheugen dan ik ooit nodig! ". Hoewel ik een jongere ben, dus dat was rond 1982. Andere waarden waren 40 MB, 320 MB, 2,5 GB, 40 GB, ... de gegevens breiden uit om de beschikbare opslagruimte te vullen. - dmckee


Als antwoord op :

Het lijkt erop dat partitionering de kans op het vullen van een partitie enorm vergroot, terwijl andere ruimtes veel vrije ruimte hebben.

Op een Linux-machine wordt LVM (logisch volumebeheer) gebruikt om dit te voorkomen. Met de meeste bestandssystemen is het formaat wijzigen (sommige zelfs online) mogelijk. Ik maak verschillende partities voor verschillende toepassingen en formatteer ze naar verschillende bestandssystemen (bijv. Xfs voor grote downloadbestanden die ik snel kan verwijderen). Heb meer ruimte nodig? Monteer een nieuw station, verplaats de gegevens ernaar en monteer het op de plek waar de gegevens zich bevonden. Het is volledig naadloos voor gebruikers en applicaties.

Met LVM kunt u schijven of partities aan de volumegroep toevoegen en vervolgens logische volumes in die groep maken. Als je vrije ruimte laat in de volumegroep, kun je partities groeien die vol raken. Als het bestandssysteem dit ondersteunt (ext3, ext4, reiserfs), kunt u een partitie verkleinen die u teveel hebt toegewezen.

Bijvoorbeeld: maak een opstartpartitie aan / dev / sda1 maak een tweede (ongeformatteerde) partitie / dev / sda2

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

Wanneer u meer ruimte nodig hebt / downloads (terwijl het bestandssysteem is gemount):

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

En je hebt nu een 150 GB downloadpartitie. Vergelijkbaar voor thuis. In feite heb ik net de grootte van een ext4 lvm "partitie" veranderd vandaag. Aan de andere kant zijn logische volumes niet echt partities en wat je zegt van partities die de verkeerde grootte hebben, gaat gepaard met mijn persoonlijke ervaring (meer moeite dan ze waard zijn).


5
2017-09-02 00:53





Het traditionele Unix-partitioneringsschema is absoluut een oude schoolpraktijk die niet zo nuttig is als het ooit was. Terug in de tijd dat de uptime van het Unix-systeem in jaren werd gemeten en je tientallen honderden gebruikers rondliep met shells, was montage / usr als alleen-lezen een handige manier om het systeem te beschermen. Het opnieuw monteren van bestandssystemen naar patch lijkt nu arbeidsintensiever en niet zo nuttig.

Op mijn universiteit terug in de goede oude tijd hadden de Unix-clusters alleen-lezen bestandssystemen met de standaard Unix-tools en add-on-applicaties waren in / usr / local, wat een NFS en later een AFS-bestandssysteem was. Onderdeel hiervan was gemak ... wie wilde software hercompileren op een tiental dozen in het cluster wanneer je apps kon uitvoeren via een high-speed, 4Mb of 10Mb netwerk? Vandaag, met fatsoenlijke pakketmanagers en heel veel goedkope schijven, is het niet zo'n probleem.

Ik denk dat de denkprocessen voor mij begonnen te veranderen op Sun-boxes met Veritas Volume Manager rond 1999, waardoor de pijngrens voor het verplaatsen van schijven aanzienlijk daalde.

Vandaag, als ik partitionering denk, denk ik in termen van gegevensbescherming en prestaties. Illustratief voorbeeld:

  • Tier 1 SAN is erg snel, zeer beschikbaar (5 9's), gerepliceerd en erg duur. Hier leven mission critical databases of transactielogboeken.
  • Tier 2 SAN is snel, beschikbaar (4 9's), duur. Toepassingen of gegevens met een lagere prioriteit leven hier.
  • Tier 3 SAN is beschikbaar (4 9's), goedkoop. Spullen die niet prestatiegevoelig zijn, leven daar.

Deze overwegingen zijn ook van toepassing op Windows. We hebben een SCCM-server die ongeveer 40.000 clients beheert. De database en logs staan ​​op mega-buck IBM DS8000 disk. De softwarepakketten bevinden zich op een EMC Celerra met grote, langzame SATA-schijven die 60% minder per GB kosten.


4
2017-09-01 22:21