BSD/UnixBSD/UnixDen åpne puben

[endrebjo]

Så port-treet er i utgangspunktet helt uavhengig av release-nummer? Sånn med tanke på at portsnap henter ned det nyeste av det nyeste, uavhengig om det er merket 8.2-release eller ikke?

 

 

Og det kanskje ikke nødvendig å oppdatere en Release i det hele tatt?

[tingo]

Yes, det er viktig å skille mellom FreeBSD som er selve OSet, og ports, som er tredjeparts programvare.

FreeBSD kan oppdateres med freebsd-update, eller ved hjelp av csup / make world.

 

ports-treet har ingen "releaser"; det er oppdatert til en dato, og det er det (dog skal det sies at de har begynt å tagge end-of-life for FreeBSD releases, slik at du kan finne et punkt for siste oppdatering som virket med FreeBSD 6.4-stable, for eksempel).

Endret 16. april 2011 av tingo

[endrebjo]

Så hva vil være den greieste rutinen for å vedlikeholde dette her da? Skal jeg bare holde meg til ports-treet som fulgte med 8.2-Release og drite i å oppdatere tredjeparts programvare? Det jo strengt tatt ikke så mange ports jeg trenger (stort sett bare nano, samba og squeezecenter), men det er så mye dependencies ute og går.

Det virker som om antallet tilgjengelige packages (pre-compiled) er større for det gamle treet enn et ferskt tre. Er det riktig?

 

Og vil

# pkg_add -r [pkg_name]

spørre serveren etter nyeste-nyeste versjon (ser at den går til ftp://.../packages-8.2-release/Latest/[pkg_name] noen ganger), eller henter den versjonsnummeret i ports-treet mitt?

[tingo]

pakker lages generelt til hver release, så ja det er nok slik at det er flest nye pakker ved release.

[NgZ]

endrebjo: Jeg sa jo det. csup og release tag.

[Zerge]

Nå er det slik at de binære pakkene er produsert fra ports, så det går fint ann å installere en binærpakke for senere å holde den oppdatert med ports.

 

# freebsd-update fetch

# freebsd-update install

# portsnap fetch update

# cd /usr/ports/ports-mgmt/portmanager/ && make install

# portmanager -u

 

Vips har du et fint og patchet miljø du kan jobbe videre i

[endrebjo]

endrebjo: Jeg sa jo det. csup og release tag.

Jeg fant det ikke i håndboken da jeg leitet som en gal i går, men i dag fant jeg det plutselig med Google. Da får jeg se om det blir ordnings. http://www.freebsd.org/doc/handbook/cvs-tags.html

 

Nå er det slik at de binære pakkene er produsert fra ports, så det går fint ann å installere en binærpakke for senere å holde den oppdatert med ports.

 

# freebsd-update fetch

# freebsd-update install

# portsnap fetch update

# cd /usr/ports/ports-mgmt/portmanager/ && make install

# portmanager -u

 

Vips har du et fint og patchet miljø du kan jobbe videre i

Det er greit nok, men når jeg gjør dette blir systemet stående og kompilere i eeeeevigheter (selv på en moderne Pentium G6950 (Xeon) med 8 GB RAM). Det er dette jeg føler er så unødvendig, spesielt siden oppdateringene ikke nødvendigvis går på sikkerhet/bugs, men på funksjonalitetsutvidelse. Jeg ønsker en branch som er frozen, og det ser det ut til at jeg kan få med CVSup. Så håper jeg at disse portsene stort sett har packages tilgjengelig.

[endrebjo]

endrebjo: Jeg sa jo det. csup og release tag.

Jeg fant det ikke i håndboken da jeg leitet som en gal i går, men i dag fant jeg det plutselig med Google. Da får jeg se om det blir ordnings. http://www.freebsd.org/doc/handbook/cvs-tags.html

A.7.1 Branch Tags

All of these' date=' with the exception of HEAD (which is always a valid tag), only apply to the src/ tree. [b']The ports/, doc/, and www/ trees are not branched.[/b]

Så da nytter det vel ikke å bruke CVSup til å hente security/bugfix for ports? Å legge inn release-tag blir vel det samme som å beholde ports-treet fra 8.2-RELEASE-platen?

[tingo]

Men det er viktig å ikke blande FreeBSD (selve OSet) og ports når man forsøker å forstå hvordan dette henger i hop.

# freebsd-update fetch

# freebsd-update install

Dette oppdaterer FreeBSD, og har ingenting med ports å gjøre.

 

# portsnap fetch update

# cd /usr/ports/ports-mgmt/portmanager/ && make install

# portmanager -u

Og her oppdaterer du ports.

 

Begge deler er like viktige, men som sagt, de er separate ting.

[tingo]

For de som bruker ZFS: zfs v28 (har dedup) er nå merget til 8.2-stable:

http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062900.html

[Zerge]

Det er greit nok, men når jeg gjør dette blir systemet stående og kompilere i eeeeevigheter (selv på en moderne Pentium G6950 (Xeon) med 8 GB RAM). Det er dette jeg føler er så unødvendig, spesielt siden oppdateringene ikke nødvendigvis går på sikkerhet/bugs, men på funksjonalitetsutvidelse. Jeg ønsker en branch som er frozen, og det ser det ut til at jeg kan få med CVSup. Så håper jeg at disse portsene stort sett har packages tilgjengelig.

 

Husk at du kan tune argumenter til make slik at den faktisk benytter flere kjerner under kompilering, da går ting en del raskere. Hvis du så etter 1. gangs oppdatering holder systemet oppdatert med jevne mellomrom, så tar det ikke allverdens tid.

[Rusma]

"OpenBSD 4.9"-sangen er litt kul da

 

ftp://ftp.openbsd.or...ongs/song49.ogg

[quarkey]

Noen som vet hvorfor I/O trafikken min fra /dev/zero til disk strupes 93.8% av total MB/S ved to DD inputs? UFS, solaris 5.10.

 

1 input = 100MB/S

2 inputs = totalt 6.2 MB/s

 

Virker som disken går i 100% busy mode...?

[Sokkalf™]

Høres vel ut som disken plutselig blir nødt til å søke frem og tilbake, og ikke skriver rent sekvensielt lenger, noe som vil redusere hastigheten drastisk.

[quarkey]

Høres vel ut som disken plutselig blir nødt til å søke frem og tilbake, og ikke skriver rent sekvensielt lenger, noe som vil redusere hastigheten drastisk.

Hmm, må være noen settings en plass.. Har 4 forskjellige raid og 4 forskjellige sun-blader som problemet oppstår på.

[Sokkalf™]

Vel, det jeg prøvde å si var at dette er normalt.

 

Når disken (eller RAIDet) skriver én datastrøm, kan den gjøre det sekvensielt, og det går raskt.

 

Når den må skrive to eller flere, må den søke frem og tilbake for å "multiplexe" datastrømmen, og man må plutselig ta diskens søketid med i beregningen. Med mange hopp frem og tilbake, som det naturlig nok blir når det skrives større datamengder på to plasser samtidig, så vil ytelsen falle dramatisk.

 

SSDer har god nok søketid til å ikke bli hardt rammet av dette, men på harddisker har man typisk mellom 6 og 15ms på enkeltdisker, og litt lavere eller litt høyere avhengig av raidkonfigurasjon.

[quarkey]

Ser det svinger noe jævlig med iostat, alt fra 0.1 til 100MB/s med to DD prosesser.

 

F.eks hvis jeg kopierer fra to forskjellige tapedriver med total hastighet på 10MB/s ut ifra begge driver, blir resultatet 3MB/s.

 

 

Kjedelige greier. hehe.

Endret 17. august 2011 av quarkey

[Zerge]

Hvilken block size setter du i DD ? Dette kan ha veldig mye å si på ytelsen du opplever

[quarkey]

Hvilken block size setter du i DD ? Dette kan ha veldig mye å si på ytelsen du opplever

Alt fra 8000b (UKOOA P1/90) til 128k, ikke så mye forskjell egentlig

[Zerge]

Ok, du kan jo teste med 512k og 1024k bare for å luke det helt ut..