---

Hej

Jeg har to Debian-maskiner stående (Woody, 2.4.19).

Den ene mounter et filsystem via NFS på den anden og laver daglig
sikkerhedskopiering til dette med tar+bzip2.

Når jeg laver sikkerhedskopien direkte til NFS-filsystemet opstår der
ofte fejl i filen (bzip2 klager over ugyldige komprimerede
data). Fejlen er ikke forudsigelig; den sker tilfældige steder i filen
(når den overhovedet opstår).

Laver jeg sikkerhedskopien direkte til et lokalt filsystem og flytter
den til NFS-filsystemet med mv er der aldrig fejl i filen.

Begge maskiner laver ellers normalt ikke den slags fejl. Nettrafik
imellem dem bliver normalt ikke ødelagt. De går begge gennem
almindelig hardwaretest (memtest86) og giver ikke fejl i andre
programmer; kun NFS+bzip2...

Problemet opstod også, da de begge kørte 2.4.18; nu kører de som sagt
begge 2.4.9.

/etc/exports på NFS-serveren:

/home/backup 172.16.0.3(rw,root_squash,anonuid=1003,anongid=100)

/etc/fstab på klienten:

server:/home/backup /backup/net nfs rsize=8192,wsize=8192,nfsvers=3 0 0

Begge maskiner har RTL8139-kort (ja, jeg ved at det er lowend, men de
skulle jo fungere godt nok bortset fra ydelsen):

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)

00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)

Jeg er helt blank; jeg er slet ikke klar over, hvor jeg skal lede. Er
der nogen, som har gode forslag?

I øjeblikket laver jeg sikkerhedskopien på et lokalt filsystem og
flytter den til NFS-filsystemet bagefter - men jeg ville naturligvis
gerne lave den direkte til NFS-filsystemet...

Pft
/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Windows NT: Insert Wallet into Drive A: and press any key to empty.
--Matt Garrison, MacLine
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:
....
> /etc/fstab på klienten:
>
> server:/home/backup /backup/net nfs rsize=8192,wsize=8192,nfsvers=3 0 0

Er der forskel, om du kører nfsvers 2 eller 3?

Kan du se, om de fejlene nfs filer skyldes at noget mangler
i filerne eller der er forkerte bytes?

Hvis du laver en lokal backup

tar cvf /tmp/bigfile.tar whatever

og så:

bzip2 -c /tmp/bigfile.tar >/backup/net/test1.tar.bz2

går det så altid godt? Du kan evt. prøve at gentage
bzip2 kommandoen og lave en test2.tar.bz2 fil, som
du kan sammenligne.

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Hej igen derude

Så nu har maskinerne brugt en masse tid på komprimering og
dekomprimering (de er kun 300 hhv. 333 MHz)...

Mogens Kjaer <mk@crc.dk> writes:

> Rasmus Bøg Hansen wrote:
> ...
> > /etc/fstab på klienten:
> > server:/home/backup /backup/net nfs rsize=8192,wsize=8192,nfsvers=3
> > 0 0
>
> Er der forskel, om du kører nfsvers 2 eller 3?

Nej, det sker både med version 2 og 3.

> Kan du se, om de fejlene nfs filer skyldes at noget mangler
> i filerne eller der er forkerte bytes?

Jeg er ikke bekendt nok med bzip2 til at kunne sige det med sikkerhed,
men jeg synes, det ligner forkerte data - måske uddata fra bzip2 kan
sige det:

bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

> Hvis du laver en lokal backup
>
> tar cvf /tmp/bigfile.tar whatever

Den er konstateret fungerende - 'tar tvf' giver ingen fejl.

> og så:
>
> bzip2 -c /tmp/bigfile.tar >/backup/net/test1.tar.bz2

Så kommer der som regel fejl i filen. Samme, hvis den ukomprimerede
fil ligger direkte på samme NFS-drev. Komprimering til en lokal fil
giver ikke fejl.

Kan det være kabelfejl (burde almindelig fejlkontrol i netkort såvel
som kerne ikke eliminere det)? Defekte netkort?

Som sagt er det RTL8139-kort - de yder dårligt, men skulle vel ikke
give egentlige fejl i data...

Det sære er, at det kun synes at ske ved komprimering - ikke ved
simpel kopiering...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Expect the unexpected.
- HitchHikers Guide to the Galaxy, Douglas Adams
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:
....
>>og så:
>>
>>bzip2 -c /tmp/bigfile.tar >/backup/net/test1.tar.bz2
>
>
> Så kommer der som regel fejl i filen. Samme, hvis den ukomprimerede
> fil ligger direkte på samme NFS-drev. Komprimering til en lokal fil
> giver ikke fejl.

Hvis du gør det flere gange i træk - ud fra samme bigfile.tar -
og laver test1.tar.bz2, test2.tar.bz2 etc. bliver de så ens?
Samme længde? Fejl samme sted?

Hvor stor er tar filen, komprimeret hhv. ukomprimeret?

Er der også problemer hvis du bruger gzip i stedet for
bzip2?

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> Rasmus Bøg Hansen wrote:
> ...
> >>og så:
> >>
> >>bzip2 -c /tmp/bigfile.tar >/backup/net/test1.tar.bz2
> > Så kommer der som regel fejl i filen. Samme, hvis den ukomprimerede
> > fil ligger direkte på samme NFS-drev. Komprimering til en lokal fil
> > giver ikke fejl.
>
> Hvis du gør det flere gange i træk - ud fra samme bigfile.tar -
> og laver test1.tar.bz2, test2.tar.bz2 etc. bliver de så ens?

Nej, de er ikke ens.

> Samme længde? Fejl samme sted?

Samme længde. Fejl forskellige steder.

> Hvor stor er tar filen, komprimeret hhv. ukomprimeret?

klient# ls -l test.tar
-rw-r--r-- 1 root root 545105920 tir 26 nov 11:04:33 2002 test.tar

server# ls -l test{1,2}.tar.{gz,bz2}
-rw-r--r-- 1 bkup users 343739406 Nov 26 11:56 test1.tar.bz2
-rw-r--r-- 1 bkup users 384536247 Nov 26 20:19 test1.tar.gz
-rw-r--r-- 1 bkup users 343739406 Nov 26 14:50 test2.tar.bz2
-rw-r--r-- 1 bkup users 384536247 Nov 26 20:33 test2.tar.gz

> Er der også problemer hvis du bruger gzip i stedet for
> bzip2?

Ja:

server# md5sum test{1,2}.tar.{gz,bz2}
f4d7bf9f6f65ea709659920b9c7afb2d test1.tar.gz
cf11faec35c927a1fa4e3b4083a94a26 test1.tar.bz2
201541d4e9f573e4f4cba5f198d8f941 test2.tar.gz
d40839327ca2ae7a71c24d7856bc9995 test2.tar.bz2

Jeg er helt blank - jeg har ingen som helst anelse om, hvad der er
galt...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Those who write "Optimized for Netscape" og "Best viewed with MSIE"
never figured out the difference between the WWW and a Word Perfect
4.2 Document.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:

> server# md5sum test{1,2}.tar.{gz,bz2}
> f4d7bf9f6f65ea709659920b9c7afb2d test1.tar.gz
> cf11faec35c927a1fa4e3b4083a94a26 test1.tar.bz2
> 201541d4e9f573e4f4cba5f198d8f941 test2.tar.gz
> d40839327ca2ae7a71c24d7856bc9995 test2.tar.bz2

Det skulle måske nævnes:

klient# cat test.tar.bz2 > ../net/t1
klient# cat test.tar.bz2 > ../net/t2
klient# md5sum test.tar.bz2
a61bc4466814b20621d5734e0a10e317 test.tar.bz2

server# md5sum t?
a61bc4466814b20621d5734e0a10e317 t1
a61bc4466814b20621d5734e0a10e317 t2

Så rå kopiering går fint.

Der er intet at se i dmesg eller logfiler på nogen af maskinerne...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
[ Cancel Cancelled ]
- Pine
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:

> moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:
>
> > server# md5sum test{1,2}.tar.{gz,bz2}
> > f4d7bf9f6f65ea709659920b9c7afb2d test1.tar.gz
> > cf11faec35c927a1fa4e3b4083a94a26 test1.tar.bz2
> > 201541d4e9f573e4f4cba5f198d8f941 test2.tar.gz
> > d40839327ca2ae7a71c24d7856bc9995 test2.tar.bz2
>
> Det skulle måske nævnes:
>
> klient# cat test.tar.bz2 > ../net/t1
> klient# cat test.tar.bz2 > ../net/t2
> klient# md5sum test.tar.bz2
> a61bc4466814b20621d5734e0a10e317 test.tar.bz2
>
> server# md5sum t?
> a61bc4466814b20621d5734e0a10e317 t1
> a61bc4466814b20621d5734e0a10e317 t2

Ovenstående giver samme resultat (dvs. success), hvis der står en
bzip2 i baggrunden og tygger al CPU-kraften i sig, så problemet synes
ikke at være relateret til om CPU'en er belastet eller ej - kun om
CPU'en er belastet af det NFS-skrivende program.

Jeg bliver mere og mere desorienteret...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
If I wanted a blue screen, I would type "xsetroot -solid blue"
- not D:\WINNT\SETUP
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:

> Ovenstående giver samme resultat (dvs. success), hvis der står en
> bzip2 i baggrunden og tygger al CPU-kraften i sig, så problemet synes
> ikke at være relateret til om CPU'en er belastet eller ej - kun om
> CPU'en er belastet af det NFS-skrivende program.
>
> Jeg bliver mere og mere desorienteret...

Men det går galt når du laver en tar uden bzip?
Måske kan du også provokere fejlen med en simpel find?

Det lyder som om det er noget med opslag i directories der ikke helt
virker. Jeg prøvede noget tilsvarende NFS-snask på et cluster med
RedHat, det kørte 2.2.16-22 på serveren og 2.4.18-3(smp) på
clienterne. Hvis jeg lavede en ./configure på en knude kunne jeg ikke
få make til at virke på _samme_ knude, men på de andre knuder kørte
oversættelsen ganske fint.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:

> Men det går galt når du laver en tar uden bzip?
> Måske kan du også provokere fejlen med en simpel find?
>
> Det lyder som om det er noget med opslag i directories der ikke helt
> virker. Jeg prøvede noget tilsvarende NFS-snask på et cluster med
> RedHat, det kørte 2.2.16-22 på serveren og 2.4.18-3(smp) på
> clienterne. Hvis jeg lavede en ./configure på en knude kunne jeg ikke
> få make til at virke på _samme_ knude, men på de andre knuder kørte
> oversættelsen ganske fint.
>

Det ser ikke relevant ud; Rasmus har også problemet,
hvis han først laver en tar fil (som er OK), og derefter
laver en komprimering af denne ene fil til en NFS fil.

Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Rasmus Bøg Hansen wrote:
> Mogens Kjaer <mk@crc.dk> writes:
....
>>Hvor stor er tar filen, komprimeret hhv. ukomprimeret?
>
>
> klient# ls -l test.tar
> -rw-r--r-- 1 root root 545105920 tir 26 nov 11:04:33 2002 test.tar

Tja, så er det ikke et 2G-filstørrelse problem. Nogle gange har jeg
set, at selv om gzip/bzip2 har kunne klare filer større end 2G, så
har der været problemer alligevel, nemlig hvis man piper outputtet.
Men det er ikke relevant hér.

>
> server# ls -l test{1,2}.tar.{gz,bz2}
> -rw-r--r-- 1 bkup users 343739406 Nov 26 11:56 test1.tar.bz2
> -rw-r--r-- 1 bkup users 384536247 Nov 26 20:19 test1.tar.gz
> -rw-r--r-- 1 bkup users 343739406 Nov 26 14:50 test2.tar.bz2
> -rw-r--r-- 1 bkup users 384536247 Nov 26 20:33 test2.tar.gz

Måske skulle du lave et hexdump af test[12].tar.bz2 og
så lave en diff imellem disse to hexdumps? Måske bliver
man klogere, hvis det er én byte, der er forskellig, eller
hvis det er 512, 1024, etc.

Hvad i øvrigt, hvis du laver en bzip2 til din lokale
harddisk på klienten, og derefter laver en

bzip2 -c -d test1.tar.bz2 >/server/test1.tar

er filen så også korrupt?

Hm, det ligner efterhånden et spørgsmål
til nogle NFS-gutter på Linux kerne listen...

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> Måske skulle du lave et hexdump af test[12].tar.bz2 og
> så lave en diff imellem disse to hexdumps? Måske bliver
> man klogere, hvis det er én byte, der er forskellig, eller
> hvis det er 512, 1024, etc.

Eh, hvordan goer jeg det?

server# diff *.hex
diff: memory exhausted

Jeg har 256MB ram i maskinen samt 512MB swap og jeg har netop
tilfoejet to 2GB-swapfiler (saa maskinen har altsaa omkring 4.5GB
virtuel hukommelse) - er jeg noedt til at rode mig ud i kerner med
understoettelse for > 2GB hukommelse eller kan man lave noget smart
med diff (jeg har proevet --speed-large-files med samme resultat)?

> Hvad i øvrigt, hvis du laver en bzip2 til din lokale
> harddisk på klienten, og derefter laver en
>
> bzip2 -c -d test1.tar.bz2 >/server/test1.tar
>
> er filen så også korrupt?

Meget saert - det giver ingen problemer efter tre forsoeg...

> Hm, det ligner efterhånden et spørgsmål
> til nogle NFS-gutter på Linux kerne listen...

Ja, jeg begynder ogsaa at haelde til den vej frem...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Eat right, exercise regularly, die anyway.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:

> Mogens Kjaer <mk@crc.dk> writes:
>
> > Måske skulle du lave et hexdump af test[12].tar.bz2 og
> > så lave en diff imellem disse to hexdumps? Måske bliver
> > man klogere, hvis det er én byte, der er forskellig, eller
> > hvis det er 512, 1024, etc.
>
> Eh, hvordan goer jeg det?
>
> server# diff *.hex
> diff: memory exhausted

Godt saa, nu er jeg lige blevet gode venner med cmp...

Den viser at der 5 steder i filerne er forskellige; alle steder flere
paa hinanden foelgende bytes (men ikke et fast antal, et sted 3 bytes,
et sted ca. 20 bytes, et sted ca. 40 bytes). Intet tydeligt moenster
(jeg kan godt poste det, men det fylder temmelig meget).

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
May the smurf be with you... Always
-- Obi-Smurf Kenobi
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:
> moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:
>
>
>>Mogens Kjaer <mk@crc.dk> writes:
>>
>>
>>>Måske skulle du lave et hexdump af test[12].tar.bz2 og
>>>så lave en diff imellem disse to hexdumps? Måske bliver
>>>man klogere, hvis det er én byte, der er forskellig, eller
>>>hvis det er 512, 1024, etc.
>>
>>Eh, hvordan goer jeg det?
>>
>>server# diff *.hex
>>diff: memory exhausted
>
>
> Godt saa, nu er jeg lige blevet gode venner med cmp...
>
> Den viser at der 5 steder i filerne er forskellige; alle steder flere
> paa hinanden foelgende bytes (men ikke et fast antal, et sted 3 bytes,
> et sted ca. 20 bytes, et sted ca. 40 bytes). Intet tydeligt moenster
> (jeg kan godt poste det, men det fylder temmelig meget).

Jeg er tom for ideer - ud over at poste på LKML.
Der vil de sikkert gerne have en kort beskrivelse af alt
det, du har prøvet.

Mogens

--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> Jeg er tom for ideer - ud over at poste på LKML.

Jeg takker for hjaelpen - jeg gaar til LKML...

> Der vil de sikkert gerne have en kort beskrivelse af alt
> det, du har prøvet.

Jotak, det bliver nok en kaempe epost!

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
[...] Note that 120 sec is defined in the protocol as the maximum
possible RTT. I guess we'll have to use something other than TCP
to talk to the University of Mars.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:

> Jeg takker for hjaelpen - jeg gaar til LKML...

Hvis du finder en løsning må du gerne poste
en followup hér, det kan være, at vi andre
støder ind i det samme problem engang...

Mogens


--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> Rasmus Bøg Hansen wrote:
>
> > Jeg takker for hjaelpen - jeg gaar til LKML...
>
> Hvis du finder en løsning må du gerne poste
> en followup hér, det kan være, at vi andre
> støder ind i det samme problem engang...

Naturligvis!

Indtil videre har jeg på opfordring fra NFS-mesteren selv (Trond
Myklebust) installeret 2.4.20-rc4 på begge maskiner - det lader dog
ikke til at afhjælpe problemet

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Programming is a race between programmers, who try and make more and
more idiot-proof software, and universe, which produces more and more
remarkable idiots.
Until now, universe leads the race.
- R. Cooka
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:
> Mogens Kjaer <mk@crc.dk> writes:
>
>
>>Rasmus Bøg Hansen wrote:
>>
>>
>>>Jeg takker for hjaelpen - jeg gaar til LKML...
>>
>>Hvis du finder en løsning må du gerne poste
>>en followup hér, det kan være, at vi andre
>>støder ind i det samme problem engang...
>
>
> Naturligvis!
>
> Indtil videre har jeg på opfordring fra NFS-mesteren selv (Trond
> Myklebust) installeret 2.4.20-rc4 på begge maskiner - det lader dog
> ikke til at afhjælpe problemet

Til lykke, så er du i gode hænder!

Trond var meget hjælpsom, da jeg stødte ind i det problem,
at man ikke kunne se alle filer på en SGI NFS server
på en Linux klient. Jeg sendte 117 debug udskrifter, og
han fik lavet en patch.

Denne patch er i øvrigt stadigvæk (fejlen var allerede i 2.4.0)
ikke i Linus' standardkerner: Kernefolkene siger, at det
er et glibc problem, glibc folkene at det er et kerneproblem
(problemet kan også løses ved at patche glibc) -
og begge, at det er et SGI problem. Suk.

Redhat har den med i de 117 patches, de lægger ind
i deres kerner - derfor, engang i mellem kan det
betale sig at lade være med selv at hente en kerne
og kompilere den.

Mogens


--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> > Indtil videre har jeg på opfordring fra NFS-mesteren selv (Trond
> > Myklebust) installeret 2.4.20-rc4 på begge maskiner - det lader dog
> > ikke til at afhjælpe problemet
>
> Til lykke, så er du i gode hænder!

Ja, det er også mit indtryk!

> ikke i Linus' standardkerner: Kernefolkene siger, at det
> er et glibc problem, glibc folkene at det er et kerneproblem
> (problemet kan også løses ved at patche glibc) -
> og begge, at det er et SGI problem. Suk.

Åh, det lyder som en noget kedelig mur at komme hen over...

> Redhat har den med i de 117 patches, de lægger ind
> i deres kerner - derfor, engang i mellem kan det
> betale sig at lade være med selv at hente en kerne
> og kompilere den.

Åh ja, det kan du have ganske ret i. Ellers må man lige huske den
bunke patches, man selv skal bruge...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Man invented language to satisfy his deep need to complain.
-- Lily Tomlin
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Mogens Kjaer <mk@crc.dk> writes:

> Trond var meget hjælpsom, da jeg stødte ind i det problem,
> at man ikke kunne se alle filer på en SGI NFS server
> på en Linux klient. Jeg sendte 117 debug udskrifter, og
> han fik lavet en patch.
>
> Denne patch er i øvrigt stadigvæk (fejlen var allerede i 2.4.0)
> ikke i Linus' standardkerner: Kernefolkene siger, at det
> er et glibc problem, glibc folkene at det er et kerneproblem
> (problemet kan også løses ved at patche glibc) -
> og begge, at det er et SGI problem. Suk.

Kan det ikke være denne:

Summary of changes from v2.4.20-pre11 to v2.4.20-rc1
============================================

[...]

<okir@suse.de>:
o Fix NFS IRIX compatibility braindamage

?

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Hidden DOS secret:
add BUGS=OFF to your CONFIG.SYS
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Mogens Kjaer <mk@crc.dk> writes:

> Rasmus Bøg Hansen wrote:
>
> > Jeg takker for hjaelpen - jeg gaar til LKML...
>
> Hvis du finder en løsning må du gerne poste
> en followup hér, det kan være, at vi andre
> støder ind i det samme problem engang...

Trond fattede heller ikke en meter (han kunne ikke reproducere
resultaterne).

Efter adskillige timers komprimering over NFS den ene vej såvel som
den anden vej, viser det sig, at problemet forsvinder, når DMA slås
fra på disken!

Men jeg ser ikke DMA-korruption i anden sammenhæng - og hvorfor pokker
sker det kun, når man skriver langsomt til disken over NFS og ikke,
når man skriver hurtigt til disken lokalt???

Nå, men nu kan jeg da i det mindste tage sikkerhedskopier igen!

Tak for hjælpen.

/Rasmus

(men føj, hvor ydelsen sutter i PIO-mode!)

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
When is it time to reinstall an operation system?
- When booted, the computer prints "Starting Windows..."
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

Rasmus Bøg Hansen wrote:
...
> Efter adskillige timers komprimering over NFS den ene vej såvel som
> den anden vej, viser det sig, at problemet forsvinder, når DMA slås
> fra på disken!

Kan det være, at det i virkeligheden er netkortet,
der driller disk-DMA'en? Kan du prøve med
et andet type netkort?

Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

Mogens Kjaer <mk@crc.dk> writes:

> Rasmus Bøg Hansen wrote:
> ..
> > Efter adskillige timers komprimering over NFS den ene vej såvel som
> > den anden vej, viser det sig, at problemet forsvinder, når DMA slås
> > fra på disken!
>
> Kan det være, at det i virkeligheden er netkortet,
> der driller disk-DMA'en? Kan du prøve med
> et andet type netkort?

Ja, i princippet kan det være problemet. Jeg har dog ikke et løst
netkort at prøve med lige nu og her (det skulle da lige være et
ISA-kort, men *det* vil jeg helst undgå).

Alan Cox foreslog at jeg kunne lege lidt med ram-timing og muligvis
PCI-indstillinger - det kan jeg jo passende bruge weekenden til -
eller alterntivt eksperimentere med PIO-mode på netkortet...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Computers are like airconditioners:
They stop working properly if you open windows.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

moffe@amagerkollegiet.dk (Rasmus Bøg Hansen) writes:

> Mogens Kjaer <mk@crc.dk> writes:
>
> > Rasmus Bøg Hansen wrote:
> > ..
> > > Efter adskillige timers komprimering over NFS den ene vej såvel som
> > > den anden vej, viser det sig, at problemet forsvinder, når DMA slås
> > > fra på disken!
> >
> > Kan det være, at det i virkeligheden er netkortet,
> > der driller disk-DMA'en? Kan du prøve med
> > et andet type netkort?

Godt så, for lige at følge op (nu fungerer det nemlig):

Det gjorde ingen forskel at ændre timing-parametre på RAM'en.

RTL8139-kort har åbenbart et problem med bestemte bundkort, når det
kører i DMA-mode:

--- Configure.help
Use PIO instead of MMIO
CONFIG_8139TOO_PIO
This instructs the driver to use programmed I/O ports (PIO) instead
of PCI shared memory (MMIO). This can possibly solve some problems
in case your mainboard has memory consistency issues. If unsure,
say N.
---

Nu er det slået til, så kortet kører i PIO-mode i stedet for MMIO - og
jeg har nu lavet 4 komprimerede filer over NFS uden fejl (samt en
sikkerhedskopi på 1.6GB komprimeret i nat).

Heldigvis yder kortet i forvejen så dårligt i DMA-tilstand, at det
ikke går langsommere i PIO-tilstand.

Det kunne så lære mig ikke at købe RTL8139-kort i fremtiden!

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
I think the sum of intelligence on the internet is constant.
Only the number of users grows.
- Uwe Ohse in the monastery
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

On 28 Nov 2002 09:57:40 +0100, Rasmus Bøg Hansen wrote:

> Indtil videre har jeg på opfordring fra NFS-mesteren selv (Trond
> Myklebust) installeret 2.4.20-rc4 på begge maskiner - det lader dog
> ikke til at afhjælpe problemet

Årh, sejt, måske har du fundet en ny fejl!


,

--
"This whole business of Santa rewarding good kids and Adam Sjøgren
neglecting bad kids really bugs me." asjo@koldfront.dk

---

spamtrap@koldfront.dk (Adam Sjøgren) writes:

> On 28 Nov 2002 09:57:40 +0100, Rasmus Bøg Hansen wrote:
>
> > Indtil videre har jeg på opfordring fra NFS-mesteren selv (Trond
> > Myklebust) installeret 2.4.20-rc4 på begge maskiner - det lader dog
> > ikke til at afhjælpe problemet
>
> Årh, sejt, måske har du fundet en ny fejl!

Orv, fedt.

Eller noget...

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
Beware of programmers who carry screwdrivers
----------------------------------[ moffe at amagerkollegiet dot dk ] --