Gå til innhold

Den frie kafeen


Anbefalte innlegg

Når btrfs modnes, fjerner ikke det alle argumentene til freeBSD?

Ikke det at det skjer i morgen men..

Det fjerner i hvert fall ikke argumentet for Solaris. Og dessuten, det går nok lang tid før btrfs når det stadiet ZFS nå har. Spørs hva Oracle gjør med btrfs når oppkjøpet av Sun går i orden. Kanskje Oracle bestemmer seg for å satse på ZFS, som allerede har vært stabilt nok for produksjonsmiljøer i 3 år...

 

Edit: nå er det heller ikke lenge før ZFS vil støtte kryptering on-disk. Så i løpet av 2010 vil dette nå produksjonsstatus, altså bli integrert i Solaris 10, den kommersielle utgaven av Solaris UNIX.

Endret av stigfjel
Lenke til kommentar
Videoannonse
Annonse
Edit: nå er det heller ikke lenge før ZFS vil støtte kryptering on-disk. Så i løpet av 2010 vil dette nå produksjonsstatus, altså bli integrert i Solaris 10, den kommersielle utgaven av Solaris UNIX.
Det blir en liten milepæl for flere, tror jeg. FBI og ulovlige nedlastere. :p
Lenke til kommentar
Edit: nå er det heller ikke lenge før ZFS vil støtte kryptering on-disk. Så i løpet av 2010 vil dette nå produksjonsstatus, altså bli integrert i Solaris 10, den kommersielle utgaven av Solaris UNIX.
Det blir en liten milepæl for flere, tror jeg. FBI og ulovlige nedlastere. :p

Ja, hvis krypteringen står i stil til hvor lang tid det tar å opprette et pool, blir det svært lovende.

Lenke til kommentar
Spørs hva Oracle gjør med btrfs når oppkjøpet av Sun går i orden. Kanskje Oracle bestemmer seg for å satse på ZFS, som allerede har vært stabilt nok for produksjonsmiljøer i 3 år...

Nå kjenner ikke jeg til hvor mange som jobber med btrfs som jobber for Oracle kontra de som ikke gjør det, men btrfs er da som de fleste andre open sores prosjekt; hvis Oracle ikke gidder satse på btrfs lengre, vil andre overta. All glory to GPL :p

 

Personlig tror jeg btrfs kommer til å sparke ZFS i rumpa, men det sier jeg selvfølgelig kun for å tulle med stigfjel ;)

 

Anyhoo, meg bekjent har utviklingen av btrfs vært av de raskeste i forhold til andre filsystem.

Pluss linux baserte OS har en større installasjonsbase enn Solaris og *BSD med ZFS støtte (til sammen?).

Sum: btrfs kommer ikke til å forsvinne uansett hva Oracle gjør, og btrfs kommer til å bli en seriøs konkurrent til ZFS innen kortere tid enn hva de fleste tror.

 

Som er bra for alle parter. Plass nok for begge filsystemene i verdenen.

Lenke til kommentar
Rett etter oppstart av ubuntu så viser system-monitor 168 MB minnebruk, men nå står det over 520 MB.

 

Det er ingen programmer i bruk noen gang , så hvordan kan dette skje?

 

Kjør "free -m" i terminalen og post her. Mulig det bare er caching. I så fall er det bare "sunt" (utnyttelse av ressurser for en raskere opplevelse).

Lenke til kommentar
Rett etter oppstart av ubuntu så viser system-monitor 168 MB minnebruk, men nå står det over 520 MB.

 

Det er ingen programmer i bruk noen gang , så hvordan kan dette skje?

Linux vil _alltid_ prøve å bruke alt tilgjengelig minne. Men minne vil bli satt tilgjengelig i tilfelle andre programmer har bruk for denne plassen. Altså caching.

Lenke til kommentar
Rett etter oppstart av ubuntu så viser system-monitor 168 MB minnebruk, men nå står det over 520 MB.

 

Det er ingen programmer i bruk noen gang , så hvordan kan dette skje?

 

Kjør "free -m" i terminalen og post her. Mulig det bare er caching. I så fall er det bare "sunt" (utnyttelse av ressurser for en raskere opplevelse).

 

Jeg skal prøve det neste gang jeg booter opp Linux.

 

Det som er litt rart er at det er første gangen minnbruken har kommet så høyt. Rundt 200 har vært vanlig for Ubuntu.

Lenke til kommentar

Størrelsen på "page cache" vil øke etter hvert som brukeren aksesserer filer (og starter programmer - samme sak). Dette mellomlageret brukes av kjerna til å forbedre adgangstiden når userland ber om de/de samme filen/filene på et senere tidspunkt. Størrelsen på dette lageret hører inn under kolonnen "cached" i utskriften fra free.

 

Du vil også observere en kolonne som heter "buffers". Dette er ikke det samme som "page cache", men noe som brukes av drivere som benytter seg av buffret adgang til blokkenheter. En typisk identifikator for en blokk i "buffer cache" kan være en kombinasjon av blokknummer og blokkenhet. Dette mellomlageret har derfor ikke noe begrep om filnavn eller inoder. Hensikten med dette lageret er kun å utjevne hastighetsforskjellene mellom CPU og I/O-enheter.

 

For å observere fordelene med "buffer cache", så kan du f.eks bruke ls til å liste innholdet i en katalog med mange oppføringer. Første gang dette gjøres så må det sendes en forespørsel til den aktuelle I/O-enheten. Den andre gangen så vil VFS ha katalogoppføringene i "buffer cache", slik at forespørselen kan tilfredsstilles raskere.

 

Kolonnen "free" viser hvor mye minne som ikke er allokert (brukes), men er et misvisende mål på hvor mye minne som kan tildeles til "nyttige oppgaver". Kjerna vil alltid opprettholde et minimum av tilgjengelig minne ("free") som vil være tilgjengelig for umiddelbar bruk hvis enten kjerna eller userland ber om det. Når andelen av tilgjengelig minne ("free") blir for lavt, så vil kjerna blåse page cache. I verste fall så betyr dette at filer må skrives ut til fastlager, men førstekandidatene er selvsagt filer som ikke er merket som "dirty" - endret, men ikke skrevet til disk.

 

Det ville være litt dumt hvis kjerne gikk tomt for minne og samtlige filer i "page cache" måtte skrives til disk, siden dette ville ført til enorme forsinkelser for brukeren og treg minneallokering. Derfor har kjernen en øvre grense på hvor stor andel av minne som kan være "dirty". Denne kan justeres gjennom /proc/sys/vm/dirty_background_ratio.

 

For å observere denne atferden så kan du kompilere og kjøre følgende program:

#include <iostream>

const unsigned int MB=1024*1024;

int main(int argc, char** argv) {
char* buffer = NULL;
unsigned int count = 0;

while(1) {
	buffer = new char[MB];
	for(unsigned int i=0; i < MB; i++)
		buffer[i]=0xFF;
	std::cout << "Allocated " << ++count << " MiBs" << std::endl;
}
return 0;
}

Den resulterende prosessen vil lekke minne helt til kjerna tar livet av den. Med mindre det er satt en "ulimit" på brukerkontoen, så vil dette fortsette helt til man kommer til en alvorlig situasjon der ledig minne er kritisk lavt. OOM-dreperen til kjerna vil da drepe prosesser etter "badiness". Sjansen er tilstede for at heuristikken ikke velger riktig prosess i første omgang. Lagre viktige dokumenter!. Programmet skriver til hver byte som allokkeres. Dette for å unngå det faktum at kjerna benytter seg av "lat allokering" - vi ønsker at RSS skal bli høy! Merk at systemet kan ende opp med å bli svært uresponsivt etter hvert som kjerna begynner å "trashe" som en gal.

Lenke til kommentar

Da har jeg fått kjørt 10.04 på laptopen siden torsdag (Karmic var super, men den funket rett og slett for bra, jeg må ha litt spenning). Nydelig sak, men KDE biten er ikke helt på plass (de sliter litt med å få kompilert opp første beta av KDE 4.4, men den ser nydelig ut så langt). Ellers må jeg si at det eneste problemet jeg har opplevd er nvidia driveren som kødder, ingen 3D. Gidder ikke mikke med å prøve nyere drivere manuelt, begynner nesten å angre på at jeg ikke gikk for ATI på laptopen også.

 

Morsomt med rolling release, her er det nytt snack omtrent daglig.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...