mboost-dp1

Linux
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Jeg kan godt se hvordan alle med større og mere krævende netværk kan få gavn af dette, men er det virkeligt nødvendigt at have det i kernellen? Der er jo ingen desktopbrugere som vil få gavn af det.
Omvendt - hvis denne feature klarer sig markant bedre ved at blive implementeret i kernellen, end hvis den installeres efterfølgende, kan jeg bedre forstå det.
Men umiddelbart lyder det som noget man burde lade linux distributørerne om at vælge at inkludere...
Omvendt - hvis denne feature klarer sig markant bedre ved at blive implementeret i kernellen, end hvis den installeres efterfølgende, kan jeg bedre forstå det.
Men umiddelbart lyder det som noget man burde lade linux distributørerne om at vælge at inkludere...
coday (2) skrev:Hvad gør det, udover høj oppe tid?
Det synkroniserer to servere, således at hvis den ene går ned, kan den anden tage over med det samme.
Altså live-sync af en art, men med automatisk fail-over.
Der er ikke så meget mere i det end dét...
Læs evt. den side der linkes til i artiklen.
Det inkluderes vel bare som et modul, hvis du saa vil bruge det skal du tilfoeje en linje i en konfigurationsfil, for at loade modulet.
Saa undgaar almindelige brugere andet bloat end et par MB til kernen og dem der skal bruge moduler tilfoejer bare den noedvendige linje.
Eller kernen tager nok 10 ms mere at indlaese fra harddisken til ram O_O
EDIT:
#6
Nej det er ikke det samme som MS DFS, da det ikke distruberer samba shares mellem servere, men logiske volumes, saa du kan have hele partitioner synkroniseret mellem dine servere.
Saa undgaar almindelige brugere andet bloat end et par MB til kernen og dem der skal bruge moduler tilfoejer bare den noedvendige linje.
Eller kernen tager nok 10 ms mere at indlaese fra harddisken til ram O_O
EDIT:
#6
Nej det er ikke det samme som MS DFS, da det ikke distruberer samba shares mellem servere, men logiske volumes, saa du kan have hele partitioner synkroniseret mellem dine servere.
Har brugt det tidligere (drbd 7.3) i et projekt hvor det var påkrævet at 2 geografisk adskilte servere skulle fungere som 'backup' af hinanden. Det var blandt andet apache og andet godt. Det hele blev bundet sammen af heartbeat.
DRBD blev valgt på paritionsniveau og det har fungeret supergodt.
Går den ene server ned skifter heartbeat til den anden der har en fuldstændig identisk kopi (det er endda muligt at synce helt ned på sessionniveau). Når den anden server kommer op igen, sørger DRBD selv for at synce det hele op igen.
Tænk lidt på det som RAID over TCP/IP på serverniveau i stedet for på harddiskniveau.
DRBD blev valgt på paritionsniveau og det har fungeret supergodt.
Går den ene server ned skifter heartbeat til den anden der har en fuldstændig identisk kopi (det er endda muligt at synce helt ned på sessionniveau). Når den anden server kommer op igen, sørger DRBD selv for at synce det hele op igen.
Tænk lidt på det som RAID over TCP/IP på serverniveau i stedet for på harddiskniveau.
Der er et par ting som ikke er helt klart for mig. Kan to systemer mounte filsystemet fra samme blockdevice på én gang? Det er vel stort set umuligt at gøre med mindre filsystemet er designet til det.
Og hvordan afgører de hvilken af de to replika, der er primær? Hvis netforbindelsen mellem dem forsvinder, så kan de jo begge tro, at den anden er død, og de selv er primær.
Der er jo ingen der er tvunget til at bruge det.
Der findes mange branches som i kortere eller længere tid har en modificieret udgave af kernen som er tilpasset et formål. Men som regel er det blot indtil man finder ud af, hvordan man får det ind i mainstream kernen på en måde som er passende for alle.
Du kan stadigvæk vælge features til og fra når du bygger kernen, og mange features kan bygges som moduler så valget kan træffes i det øjeblik du har brug for en feature.
Og hvordan afgører de hvilken af de to replika, der er primær? Hvis netforbindelsen mellem dem forsvinder, så kan de jo begge tro, at den anden er død, og de selv er primær.
Jo, men det var i forbindelse med kernens forbrug af cache hukommelse. Det havde intet at gøre med udvalget af features i kernen. Features der koster performance hele tiden, også når de ikke er i brug, er en skidt ting. Så længe en feature ikke går ud over performance for dem der ikke bruger den, tror jeg ikke han betragter det som bloat.Daniel-Dane (1) skrev:Var det ikke Torvald, der i sin tid fortalte, at Linuxkernen er blevet bloated?
Og? Blot fordi der findes nogle personer, der ikke har brug for en feature betyder det jo ikke, at den ikke bør være der. Hvis man kun måtte implementere features, som alle havde brug for, så ville man jo ikke kunne implementere noget som helst.jakobdam (3) skrev:Jeg kan godt se hvordan alle med større og mere krævende netværk kan få gavn af dette, men er det virkeligt nødvendigt at have det i kernellen? Der er jo ingen desktopbrugere som vil få gavn af det.
Der er jo ingen der er tvunget til at bruge det.
Omvendt - hvis denne feature klarer sig markant bedre ved at blive implementeret i kernellen, end hvis den installeres efterfølgende, kan jeg bedre forstå det.Der er tale om en block device driver, den slags hører til i kernen.
Men umiddelbart lyder det som noget man burde lade linux distributørerne om at vælge at inkludere...Selvfølgelig kan de vælge ligesom de kan vælge hvilke af de tusindvis af andre features, der skal med. Og DRBD lyder som om det sagtens kunne laves som et modul der kan indlæses i kernen efter behov. Så distributørerne kan bygge det som et modul og lade brugerne vælge.
Ja, det ville være helt tosset. Der er jo mange features som begge får glæde af, og dem man ikke har brug for kan man blot unlade at bruge.Theis (10) skrev:Ville det være helt tosset at dele linux kernen op i to projekter? Et til desktop og et til server.
Der findes mange branches som i kortere eller længere tid har en modificieret udgave af kernen som er tilpasset et formål. Men som regel er det blot indtil man finder ud af, hvordan man får det ind i mainstream kernen på en måde som er passende for alle.
Du kan stadigvæk vælge features til og fra når du bygger kernen, og mange features kan bygges som moduler så valget kan træffes i det øjeblik du har brug for en feature.
Det ville da ikke være særligt brugbart. Desuden kan BSOD snildt implementeres i user mode, ingen grund til at lægge det ind i kernen.spangsberg (12) skrev:Hmm, læste overskriften som "linuxkernen udvides med BSOD"....
Nu er det jo ikke Linus Torvald der sidder på tronen og bestemmer hvad der skal med og ikke skal med.......jaja, han har da nok en smule indflydelse, men ikke mere end andre.......
jakobdam (3) skrev:Jeg kan godt se hvordan alle med større og mere krævende netværk kan få gavn af dette, men er det virkeligt nødvendigt at have det i kernellen? Der er jo ingen desktopbrugere som vil få gavn af det.
Omvendt - hvis denne feature klarer sig markant bedre ved at blive implementeret i kernellen, end hvis den installeres efterfølgende, kan jeg bedre forstå det.
Det er nødvendigt at have sådan noget liggende i kernelen, man kan dog sagtens have sådan noget liggende i userspace (Over kernen), men hvis du vil have og mærke performance skal det så langt ned og tæt på kernen som muligt.
ZFS filformatet lider af dette i Linux, da licensproblemer gør at driveren ikke må ligge i kernen. GPL og Suns CDDL licens er ikke kompatible, så selvom der ikke er en teknisk begrænsning for at inkludere det i kernelspace, så må man ofre performance og placere det i userspace.
Jeg tror ikke det har nogen direkte fordel at DRBD er inkluderet direkte i kernen, men det gør det lettere for andre at benytte sig af det, og andre udviklere at holde øje med når de ændrer ting.
nold-i-spolen (17) skrev:Nu er det jo ikke Linus Torvald der sidder på tronen og bestemmer hvad der skal med og ikke skal med.......jaja, han har da nok en smule indflydelse, men ikke mere end andre.......
Så vidt jeg har forstået det er det Linus selv der med hård hånd styrer hvad han vil lukke ind, og hvad han vil lade blive ude.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.