Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

06.04.2010, 08:50

Seit Kernel 2.6.33 funktionieren die NFS-Freigaben nicht mehr.

Hallo,

hab meinen Homeserver auf sys-kernel/vserver-sources-2.3.0.36.30.4 (entspricht 2.6.33) aktualisiert.
Mit dieser Version kann ich auf die NFS-Freigaben des Gerätes nicht zugreifen.
Beim Verbindungsversuch kommt nur in die messages:

Quellcode

1
mountd[2069]: authenticated mount request from 192.168.11.50:750 for /usr/portage (/usr/portage)

und es passiert nichts. Der Client meldet dann

Quellcode

1
2
# mount /usr/portage
mount.nfs: mount system call failed


Mit dem alten Kernel funktioniert es nach wie vor.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »bell« (07.07.2010, 23:13)


2

06.04.2010, 16:37

Hi bell
Nur eine spontane Vermutung....
stehen bei Server und Client die gleichen NFS Versionen zur verfügung?
beachte das es da:
NFS version 3
NFS version 4
NFSv4.1 (DEVELOPER ONLY)
gibt.

3

06.04.2010, 18:49

Es wäre schön, wenn ein Problem sich einfach lösen wäre.

Hab es mit NFS3 und NFS4 versucht. Beides ist im Kernel auf beiden Seiten drin.

Hab jetzt folgendes festgestellt. Mit UDP geht es nicht mehr:

Quellcode

1
2
3
4
5
6
7
8
9
10
# mount -v -t nfs4 -o user,sync,soft,rw,udp newmagix:/usr/portage /usr/portage
mount.nfs4: timeout set for Tue Apr  6 18:45:02 2010
mount.nfs4: text-based options: 'soft,udp,clientaddr=192.168.11.50,addr=192.168.11.1'
mount.nfs4: mount(2): Input/output error
mount.nfs4: mount system call failed
turbojet belka # mount -v -t nfs -o user,sync,soft,rw,udp newmagix:/usr/portage /usr/portage
mount.nfs: timeout set for Tue Apr  6 18:45:37 2010
mount.nfs: text-based options: 'soft,udp,addr=192.168.11.1'
mount.nfs: mount(2): Input/output error
mount.nfs: mount system call failed



TCP / NFS4 meldet:

Quellcode

1
2
3
4
5
6
 # mount -v -t nfs4 -o user,sync,soft,rw,tcp newmagix:/usr/portage /usr/portage
mount.nfs4: timeout set for Tue Apr  6 18:46:36 2010
mount.nfs4: text-based options: 'soft,tcp,clientaddr=192.168.11.50,addr=192.168.11.1'
mount.nfs4: mount(2): No such file or directory
mount.nfs4: mounting newmagix:/usr/portage failed, reason given by server:
  No such file or directory


TCP / NFS3 geht:

Quellcode

1
2
3
4
# mount -v -t nfs -o user,sync,soft,rw,tcp newmagix:/usr/portage /usr/portage
mount.nfs: timeout set for Tue Apr  6 18:46:19 2010
mount.nfs: text-based options: 'soft,tcp,addr=192.168.11.1'
newmagix:/usr/portage on /usr/portage type nfs (rw,noexec,nosuid,nodev,sync,user,soft,tcp)


Strange. Ich bleib erstmal beim alten Kernel. UDP gefällt mir schon besser.
Schade nur, dass durch den Aktualisierungsversuch das WLAN zerschossen ist.
Problem bleibt erstmal offen. Hat noch jemand eine Idee?
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

4

07.04.2010, 18:43

Ähnlich schaut es hier auch aus,
Server und Client jeweils mit 33er-gentoo-sources

Quellcode

1
2
3
4
5
6
7
8
9
10
# mount -v /usr/portage/distfiles
mount.nfs: timeout set for Wed Apr  7 16:27:16 2010
mount.nfs: trying text-based options 'addr=192.168.220.105,vers=4,clientaddr=192.168.220.101'
mount.nfs: mount(2): No such file or directory
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.220.105 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17                                                                                                               
mount.nfs: trying 192.168.220.105 prog 100005 vers 3 prot UDP port 55948
mount.nfs: trying text-based options 'addr=192.168.220.105,vers=3,proto=tcp,mountvers=3,mountproto=udp,mountport=55948'
192.168.220.105:/mnt/distfiles on /usr/portage/distfiles type nfs (rw,noauto)

Quellcode

1
2
# mount | grep distfiles
192.168.220.105:/mnt/distfiles on /usr/portage/distfiles type nfs (rw,addr=192.168.220.105)

Ich muss aber gestehen das ich mich mit "nfs4" noch nicht eingelesen hab, afaik hat sich da doch einiges an den exports und mount Syntax geändert!? (Ich werde mich da aber auch noch mal schlau lesen...)
denn auch dieses "mount.nfs: mount(2): No such file or directory" am Anfang ist ja nicht richtig/schön...!?

5

08.04.2010, 00:00

Hallo Josef,
Hat er bei Dir jetzt über UDP oder TCP verbunden? Das kann ich in der Ausgabe irgendwie nicht rauslesen. Poste mal nach dem Mounten

Quellcode

1
fgrep distfiles /proc/mounts
vom Client.
Was mir neu ist: proto=tcp,...,mountproto=udp - Interessant.

Bezüglich NFSv4: Beide Server laufen parallel:

Quellcode

1
2
3
4
5
6
7
8
9
10
~ # ps -ef | grep nfs
root      2225     2  0 19:17 ?        00:00:00 [nfsd4]
root      2226     2  0 19:17 ?        00:00:02 [nfsd]
root      2227     2  0 19:17 ?        00:00:13 [nfsd]
root      2228     2  0 19:17 ?        00:00:00 [nfsd]
root      2229     2  0 19:17 ?        00:00:13 [nfsd]
root      2230     2  0 19:17 ?        00:00:05 [nfsd]
root      2231     2  0 19:17 ?        00:00:03 [nfsd]
root      2232     2  0 19:17 ?        00:00:09 [nfsd]
root      2233     2  0 19:17 ?        00:00:00 [nfsd]

Können da wirklich grosse Unterschiede in der exports sein?

Das Thema ist auf jeden Fall interessant. Poste mal, wenn Du was genaueres weisst. Für mich wäre interessant, ob die nfs4 schneller ist. Sicherheit ist nicht so wichtig, da ich es in einem Netz nutze, wo nur zwei User unterwegs sind: User-Ich und Root-Ich.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

6

08.04.2010, 00:38

Quellcode

1
2
# fgrep distfiles /proc/mounts
192.168.220.105:/mnt/distfiles /usr/portage/distfiles nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.220.105,mountvers=3,mountport=55948,mountproto=udp,addr=192.168.220.105 0 0

Zitat von »"bell"«

Für mich wäre interessant, ob die nfs4 schneller ist.
Oh, das werde ich schlecht beurteilen und testen können, ich hab hier nur ein kleinen 100-Mb Router, afaik sind da nicht mehr wie ca. 12 mb/sec drin?, und die schafft auch nfs3 schon.
Ich werde mich aber mal nach weiteren Infos zu diesem Thema umschauen.

7

08.04.2010, 19:04

Habe jetzt ein Paar Benchmarks gemacht. NFS3/UDP ist bei mir am schnellsten.
Schade, dass es mit dem Kernel 2.6.33 nicht mehr (oder noch nicht) geht.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# mount -v -t nfs -o user,sync,soft,rw,proto=udp newmagix:/tmp /home/user/test
# ls test -l
insgesamt 1033284
-rw-r--r-- 1 root root 1057042432  8. Apr 18:37 test.data

# time cp test/test.data /tmp/

real	0m8.954s
user	0m0.011s
sys	0m1.536s

# rm /tmp/test.data 
# umount /home/user/test
# mount -t nfs -o user,sync,soft,rw,proto=tcp newmagix:/tmp /home/user/test

# time cp test/test.data /tmp/

real	0m9.017s
user	0m0.004s
sys	0m1.587s

# rm /tmp/test.data 
# mount.nfs4 newmagix:/ /home/user/test -o user,sync,soft,rw,proto=udp

# time cp test/test.data /tmp/

real	0m9.048s
user	0m0.011s
sys	0m1.471s

# umount /home/user/test
# rm /tmp/test.data 
# mount.nfs4 newmagix:/ /home/user/test -o user,sync,soft,rw,proto=tcp

# time cp test/test.data /tmp/

real	0m11.531s
user	0m0.008s
sys	0m1.371s
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

8

14.04.2010, 23:21

nur mal eine laienhafter vermutung:

net-fs/openafs- 1.4.11
net-fs/openafs-kernel-1.4.11

sind beide notwendig, aber 2.6.33 kommt damit nicht klar.


probiere mal eine local overlay für


net-fs/openafs- 1.4.12
net-fs/openafs-kernel-1.4.12

zu backen und updaten, vielleicht klappt es dann.

9

08.05.2010, 04:08

Zitat

TCP / UDP
In order to ensure a better reliability over the Internet, NFSv4 only uses TCP.
Quelle: index.php?page=Attachment&attachmentID=2943

10

14.05.2010, 23:54

Das WLAN Problem hat sich mit einem noch neueren Kernel gelöst, das NFS-Problem nicht. Hab jetzt auf TCP (immer noch V3) umgestellt.

Mit der aktuellen Konfiguration (V3 + UDP) habe ich pervormance-Probleme mit vielen kleinen Dateien festgestellt. So ist zB. das Auschecken per SVN auf eine NFS-Platte nicht möglich.
Werde jetzt mit TCP und evtl V4 das nochmal genauer testen.

Dieser Thread ist jedoch jetzt erledigt.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

11

11.06.2010, 21:53

Hi

Ich aktualisiere hier grad mein Notebook mal wieder, hierbei mounte ich meist ein distfiles Verzeichnis vom Desktop Rechner via NFS
Hab hier aktuell auf Server sowie Client Seite ein 34er Kernel laufen, und ich muss sagen NFSv4 funkt hier prima.
Doch anfangs gab es mit portage beim Download der Sources auch eine böse Fehlermeldung (die ich aber leider nicht mehr habe)
nach längeren suchen stellte sich heraus das

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CONFIG_FSCACHE:                                                                                                                                      │   
  │                                                                                                                                                      │   
  │ This option enables a generic filesystem caching manager that can be                                                                                 │   
  │ used by various network and other filesystems to cache data locally.                                                                                 │   
  │ Different sorts of caches can be plugged in, depending on the                                                                                        │   
  │ resources available.                                                                                                                                 │   
  │                                                                                                                                                      │   
  │ See Documentation/filesystems/caching/fscache.txt for more information.                                                                              │   
  │                                                                                                                                                      │   
  │ Symbol: FSCACHE [=m]                                                                                                                                 │   
  │ Prompt: General filesystem local caching manager                                                                                                     │   
  │   Defined at fs/fscache/Kconfig:2                                                                                                                    │   
  │   Location:                                                                                                                                          │   
  │     -> File systems                                                                                                                                  │   
  │       -> Caches                                                                                                                                      │   
  │   Selects: SLOW_WORK [=y]
der Übeltäter war..
Nachdem ich den Kernel ohne CONFIG_FSCACHE neu baute funkt NFSv4 hier soweit ich bisher getestet hab nun einwandfrei.
Evtl. stößt ja mal wer auf ähnliche Probleme und es hilft weiter...

Quellcode

1
2
# fgrep distfiles /proc/mounts
192.168.220.102:/mnt/DISTFILES/ /usr/portage/distfiles nfs4 rw,relatime,vers=4,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.220.101,addr=192.168.220.102 0 0

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »josef.95« (11.06.2010, 22:08)


12

11.06.2010, 22:19

Hab inzwischen auch auf die V4 umgestellt.

@ Josef Hattest Du FSCACHE auf dem Server oder Client?
Bei mir ist es auf dem Client gesetzt, auf dem Server nicht. Bisher noch keine Probleme festgestellt.

Allerdings habe ich ein anderes Problem mit NFSv4: Der idmapd ist nicht mehr optional. Ich will jedoch die IDs nicht mappen. Auf dem Server sind die passwd und group kleiner, als auf dem Client. Dadurch können nicht alle IDs gemappt werden. Das hat zur Folge, dass ein Backup über NFSv4 keine1:1 Kopie mehr ist. Aus diesem Grund ist mein Backup Verzeichnis immer noch NFSv3. Falls jemand eine Idee hat, wie man bei NFSv4 das ID-Mapping und Gültigkeitsprüfung der IDs komplett deaktivieren kann, her damit.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

13

11.06.2010, 22:48

@ Josef Hattest Du FSCACHE auf dem Server oder Client?
Bei mir ist es auf dem Client gesetzt, auf dem Server nicht. Bisher noch keine Probleme festgestellt.
Ich hatte FSCACHE ursprünglich auf beiden Seiten gesetzt und es schien zuerst auch alles OK, das /mnt/DISTFILES/ Verzeichnis lies sich auch problemlos mounten, die Sources waren auf dem Client auch scheinbar verfügbar, zumindest meinte portage die Sources wären da. Doch wenn man dann wirklich ein Paket mergen wollte und die Sources via NFS übertragen werden sollten konnte portage sie nicht runterladen, es brach gleich mit einer bösen (python portage) Fehlermeldung ab, irgendwas passte da dann nicht mit einem lock-file
Ich hatte da alles mögliche versucht und getestet, sogar die distfile Verzeichnisse auf beiden Seiten komplett geleert, es brachte alles nichts.., bis ich nun auf dem Client den FSCACHE deaktiviert habe, seitdem funkt es nun endlich wieder, und das sogar recht gut :)

Mit unterschiedlichen uid ,s hab ich mir auch die Zähne ausgebissen, ich hab da dann irgendwann aufgegeben und habe die ID`s angepasst, das funkt nun wieder einwandfrei bis auf den KDE Dateimanager Dolphin..., da scheint es noch irgendwo vermutlich ein Cache Verzeichnis mit der alten ID zu geben, aber das finde ich auch noch X( ! ;-)

14

11.06.2010, 23:14

Bezüglich Caching habe ich vergessen zu sagen: Ich mounte alle NFS Shares mit der Option "sync", um Inkonsistenzen zu vermeiden. Damit ist die Datei wirklich auf dem Server, wenn der Kernel "fertig mit der Übertragung" sagt.
Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

15

12.06.2010, 00:26

Hm.. nein, "sync" hatte ich nicht dabei...
/mnt/DISTFILES ist bei mir eine Partition die ich für mehrere Rechner/Systeme nutze, aktuell sind da ca. 8 GB drauf, und das obwohl ich grad aufgeräumt habe, teilweise ist da auch gern mal das doppelte drauf..

16

15.08.2011, 23:43

Hallo Leute

Gibt es denn bei euch schon was neues mit dem IDmaping? Ich habe mich jetzt einige Stunden damit herumgespielt, die Manpages kannst vergessen, und Google ist auch nicht wirklich die Große Hilfe. Jedenfalls habe ich es geschafft Distfiles sauber mit NFS4 inkl. IDmaping einzubminden. Die Exports am Server sieht so aus:

Quellcode

1
2
/export 192.168.1.0/255.255.255.0(no_subtree_check,no_root_squash,rw,fsid=0)
/export/distfiles       192.168.1.0/255.255.255.0(async,no_subtree_check,no_root_squash,rw)

Fstab auf dem Client:

Quellcode

1
darkdevil.supertux.lan:/distfiles  /usr/portage/distfiles   nfs4    rw    0 0

So wie das für mich aussieht stellt man jetzt alles nur mehr am Server ein. Optionen wie soft usw, sind am Client nicht wirklich brauchbar, denn fällt der Server aus, wird Client nicht getrennt. Wenn man nur "rw" oder "ro" drinnen hat, wir der Client innerhalb einer kurzen Zeit vom Server getrennt, ohne das was einfriert.

Was ich aber seltsam finde ist das man die Option "no_root_squash" benötigt. Immerhin läd ja Portage das Paket herunter und nicht root. Meine /etc/idmap.conf auf dem Server sieht so aus:

Quellcode

1
2
3
4
...
Domain = supertux.lan
250@supertux.lan = portage
...

Wichtig ist auch das am Client der IDMAP Dienst läuft (Konfigurieren braucht man den nicht), sonst gibts keine Usernamen. Warum auch immer...
Mir ist aber nicht klar wie ich das mit Gruppen mache, ich hab da keinen Anhaltspunkt gefunden, gehen sollte es aber: NFSv4 zwischen einem NetApp-Filer und einem Solaris-Client
Gruppen sind ja wohl das wichtigste! Einzelne User... naja bei Portage hat das schon gepasst. Das IDMAPING finde ich nicht schlecht, wenn die UIDS und GIDS überall gleich sind, aber es wird sich hier wohl eher mehr um LDAP drehen.

lg
boospy
Desto mehr Wissen man bekommt, desto mehr wird einem klar das man kein Wissen hat.
>>>> boospy@jabber.ccc.de <<<<

Verwendete Tags

kernel, NFS, nfs4