Den frie kafeen

[Marsan]

Marsan:

Hva er det som står i xorg.conf fila da? Jeg har aldri hatt problemer med å installere nvidia sine drivere, mener det var noe lettere tull men det gikk helt fint til slutt. Fear not!

 

Jeg prøvde til og med en tidligere "verson" av xorg.conf uten hell. Jeg reinnstallerte, heldigvis hadde jeg egen partisjon for /home

[olear]

Sikkerhetshull funnet

 

Sikkerhetshull patchet

 

Tok ikke lange tida det

 

Lykke til lukka systemer med å fikse ting i denne farta

Problemet ble introdusert i 2.6.17, og ble ikke fikset før nå. Jippi!

[Dy§no]

Er dette trygt å gjøre? (lage mer plass på ext3 partisjoner).

[DeadManWalking]

Hmm jeg ville aldri giddet å installere et helt system på nytt pga feil med en modul. Uansett, angående den sikkerhetsfeilen. Ja, patchen ble inkludert først nå. Men det har vel vært mulig å patche før nå?

[olear]

Sikkert, bare glad for at jeg kjører den stabile kernelen (2.6.16) på serverene

 

Slike problem er ungåelig når man legger til nye features hele tiden.

[Langbein]

Er dette trygt å gjøre? (lage mer plass på ext3 partisjoner).

Ja, jeg har selv gjort det på de fleste ext3-partisjoner. Default reservasjon for root er som sagt satt til 5%, noe som kan være i meste laget - særlig på store partisjoner. Og hvis du har flere partisjoner på systemet, er det trolig bare / hvor det er noe vits å reservere plass uansett.

 

(På den annen side er det aldri anbefalt å fylle en partisjon helt pga. økt fare for fragmentering, men akkurat det gjelder jo uansett om filer lagres av root eller andre)

Endret 16. februar 2008 av Langbein

[Håvard]

Er det mulig å bruke f.eks aalib til å rendre bilder i en terminal?

[huf]

Ja, du rendrer til ASCII.

[atlef]

2.6.25-rc2, "A Winner"

 

"Ok, this kernel is a winner," began Linux creator Linus Torvalds, playfully announcing the 2.6.25-rc2 kernel which gained the name "Funky Weasel is Jiggy wit it". He continued:

 

"Just to show how _much_ of a winner it is, it's been awarded a coveted 'weasel' series name, which should tell you just how good it's going to be. It's a name revered in Linux kernel history, and as such this brings back the good old days where if you find a bug, you're almost certainly simply mistaken, and you probably just did something wrong. But hey, you can try to prove me wrong. I dare you."

 

Linus went on to describe some of the changes using 'git dirstat', "in particular, it shows that almost exactly half of the updates are to drivers, with network drivers alone being a third of the whole patch. And of the remaining half, about half was architecture updates, notably to SH." He then noted, "I'm optimistic that this release cycle won't be anywhere near the pain of what 24 was, which is why I'm just going to go off for the long weekend and stay at the beach."

 

atlef.

[kyrsjo]

Jeg merker stor forskjell når jeg spiller av for eksempe FLAC. Med Samba hakker det, med NFS går det helt fint.

Dette er veldig viktig for meg. Tror da jeg går for NFS.

 

For meg ble det i hvert fall rot å ha norske sær-tegn på filnavn da jeg brukte Samba, det problemet har jeg ikke hatt med NFS, så lenge klient og tjener kjører samme locale

Enda et pluss til NFS.

 

Takk til dere som hjalp meg med å finne noen flere svar

 

En fordel med alt-annet-enn-NFS, er at du sliter dersom du mister forbindelsen til serveren med NFS, uten å ha mounta ned skikkelig...

 

 

Jeg har testet litt tider med ulike protokoller/måter, ved å sende en samme fil på størrelse 2.53gig. Tok tiden med stoppeklokke(så 100% nøyaktig er det ikke).

 

scp:3.45

SSHF:3.50

NFS med async:3.45

NFS med sync: 3.51

smb:7.25

cifs:5.10

rsync:3.51

 

Og så har vi Vista maskin til en WHS: 4.41

 

Jeg tror det er mulig å få NFS enda raskere, det finnes guider for det uten at jeg har forsøkt noe mer enn med og uten sync.Det som overrasket meg var forskjellen i cpu bruk for de ulike overføringsmåter.Jeg fikk også inntrykk av at NFS er bedre når man sender flere forskjellige filer(fra server til desktop og fra desktop til server), enn SSHFS.

 

Har skiftet ut ruteren nå, så nå går det så raskt at det ikke spiller noen rolle hvilke jeg velger.

 

For meg ble det i hvert fall rot å ha norske sær-tegn på filnavn da jeg brukte Samba, det problemet har jeg ikke hatt med NFS, så lenge klient og tjener kjører samme locale

Hva mener du med det?

 

Morro at de krypterte protokollene (=> masse CPU-spising i tillegg til nettverk) er raskere enn CIFS etc. ...

[Sokkalf™]

Testet litt selv.. både med 100Mbit og 1Gbit-klienter.

Testet SSH, Samba og NFS.. på 1Gbit testet jeg i tillegg FTP.

Alle testene er gjort mot serveren min, som har disker som skal kunne maxe teoretisk hastighet på Gigabit-nett.

Når jeg har lastet filer ned fra serveren, har jeg så langt det lar seg gjøre skrevet dem rett til /dev/null, for å unngå lokal disk som flaskehals.

 

Samba-shares er mountet som CIFS i alle testene.

 

100Mbit

SSH inn : 10.30M/s

SSH ut : 8.36M/s

 

NFS inn : 10.87M/s

NFS ut : 10.44M/s

 

Samba inn : 8.00M/s

Samba ut : 6.82M/s

 

1 Gbit

SSH inn : 33.40M/s

SSH ut : 29.49M/s

 

NFS inn : 69.78M/s

NFS ut : 57.38M/s

 

Samba inn : 35.82M/s

Samba ut : 23,33M/s

 

(FTP-testen ble gjort til lokal disk og ikke /dev/null)

FTP inn : 73.49M/s

FTP ut : 82.35M/s (!)

Her ser det faktisk ut som det er disken som begrenser meg! 82M/s er helt max av hva den lokale disken leverer. EDIT: gjorde ftp-upload-testen igjen fra RAM-disk.. resultat : 96.75M/s

 

Har brukt litt forskjellige filer til å teste med, men alle har vært rundt 1GB-1.5GB i størrelse.

 

NFS vinner ganske så soleklart over Samba, men jeg syns Samba er litt lettere å jobbe med enn NFS.

 

Jeg trodde jeg kanskje fikk litt dårlige resultater pga. dårlige kabler (stort sett CAT 5, ikke 5E), men med FTP-resultatet ser det jo ut som det ikke er noe stort problem..

Endret 17. februar 2008 av Sokkalf^

[huf]

Finfin test Sokkalf^.

Kva disker vart brukt her? Raptor?

[luser32]

Jeg merker stor forskjell når jeg spiller av for eksempe FLAC. Med Samba hakker det, med NFS går det helt fint.

Dette er veldig viktig for meg. Tror da jeg går for NFS.

 

For meg ble det i hvert fall rot å ha norske sær-tegn på filnavn da jeg brukte Samba, det problemet har jeg ikke hatt med NFS, så lenge klient og tjener kjører samme locale

Enda et pluss til NFS.

 

Takk til dere som hjalp meg med å finne noen flere svar

 

En fordel med alt-annet-enn-NFS, er at du sliter dersom du mister forbindelsen til serveren med NFS, uten å ha mounta ned skikkelig...

Prøvd lazy unmount?:

umount -l /foo/bar/unreachable

 

man-sidene er ofte til stor hjelp, om man vil få det ekstra ut av GNU/Linux-boksen=)

Endret 17. februar 2008 av luser32

[Sokkalf™]

Finfin test Sokkalf^.

Kva disker vart brukt her? Raptor?

 

Diskene i serveren er 5x500GB Western Digital 7200rpm SATA-disker i et raidZ ZFS-array. Lokalt på serveren klarer de ~150MB/s les og ~225MB/s skriv.. hvorfor skrivehastigheten er såpass mye større enn lesehastigheten er jeg ikke sikker på.. men skal ikke klage.

 

Disken i den stasjonære er en enkelt disk av samme type.

 

Testet 100Mbit på laptopen, men da kjørte jeg alt til /dev/null, så diskytelsen er ikke særlig relevant her (og disken hadde vel neppe hatt noen problemer med 100Mbit hastighet uansett)

[A!1]

Sokkalf^:

Kjører du Solaris eller fungerer ZFS og Raid-Z i linux? (Via FUSE?)

 

Og ifølge denne siden klarer ikke ZFS "Grow a raid5/z", hva gjør du om du vil legge til en disk til arrayet?

[Langbein]

Morro at de krypterte protokollene (=> masse CPU-spising i tillegg til nettverk) er raskere enn CIFS etc. ...

Med kjapp CPU kan man nok oppleve det ja, men på min treigeste server går det vanvittig treigt å overføre filer med SSH sammenliknet med NFS. Dette skyldes selvsagt krypteringen.

 

Men alt til sitt bruk - selv benytter jeg primært NFS på lokalnett (av og til Samba hvis det er snakk om Windows-klienter), mens jeg bruker SSH når jeg kobler meg opp fra andre steder. Har også benyttet FTP, da gjerne PureFTPd som støtter TLS-kryptering.

Endret 17. februar 2008 av Langbein

[Sokkalf™]

Sokkalf^:

Kjører du Solaris eller fungerer ZFS og Raid-Z i linux? (Via FUSE?)

 

Og ifølge denne siden klarer ikke ZFS "Grow a raid5/z", hva gjør du om du vil legge til en disk til arrayet?

 

Bruker OpenSolaris.

 

Stemmer at det ikke er helt trivielt å legge til disker med ZFS, ja.. ihvertfall ikke i nåværende versjon. Men ZFS er såpass genialt i forhold til at jeg har prøvd i linux at jeg syns det er verdt det uansett. Det man evt. kan gjøre med ZFS er å bytte ut diskene en og en med større disker. F.eks ta ut en 500GB disk, sette inn en 1TB-disk, og kjøre en "resilver", så data blir opprettet på disken igjen. Når man har byttet alle diskene på denne måten, får man full kapasitet uten å miste noe data.

 

Ellers fungerer det lett som bare det å legge til disker til en zpool, men de blir ikke en del av raidz-arrayet. Om man legger til et nytt raidz i tillegg, eller mirror etc, blir dette også sett som en del av den totale lagringsplassen i en pool.

[huf]

Kor godt fungerar ZFS i G/L via FUSE eigentleg? Nokon som har erfaringar? Er det relevant å samanlikne ytelsen opp imot eit vanleg kjørt filsystem?

 

Bruken av ntfs har vel også auka i bruk no etter ntfs-3g vart stable. Den brukar vel FUSE for å montere...

Endret 17. februar 2008 av huf

[Sokkalf™]

Kor godt fungerar ZFS i G/L via FUSE eigentleg? Nokon som har erfaringar? Er det relevant å samanlikne ytelsen opp imot eit vanleg kjørt filsystem?

 

Bruken av ntfs har vel også auka i bruk no etter ntfs-3g vart stable. Den brukar vel FUSE for å montere...

 

Har ikke prøvd selv, men fant en test her.. Den sammenligner JFS, XFS, NTFS-3G og ZFS-FUSE.

 

Begge de to sistnevnte bruker FUSE, så ZFS-FUSE bør ha en del å gå på når man ser hvor gode resultater NTFS-3G oppnår.

[huf]

Interessant å sjå at FUSE-system kan matche så bra eit kjernesystem på den måten.

 

Må seie at NTFS-3g har vorte virkeleg bra. Har brukt det mykje sjølv, og har enda til gode å oppleve kritiske feil ved den. Ytelse gitt med tal kan eg ikkje uttale meg om.