Debian Linux, grote bestanden over NFS wegschijven erg traag

[Josefien]

Grote bestanden (van bijv. 3-4GB) wegschrijven via NFS verloopt erg langzaam. Het proces in de bestandsbeheerder (pcmanfm-qt) springt met sprongen richting de 50-60% en lijkt vlot. Vanaf daar wordt het steeds langzamer en hoor ik de schijven in de server flink seeken/"ratelen". Rond 95% blijft het vervolgens een hele tijd hangen voordat het klaar is, terwijl de schijven in de server hard aan het seeken zijn.

Dit probleem (zowel de traagheid als het seeken v/d schijven) doet zich niet voor als ik de share via SMB koppel...

Zowel server als cliënt draaien op Debian Linux 10. Op de server staan de schijven verdeelt over 2 software RAID1-arrays. De share op array 1 lijkt een tikje sneller, maar het probleem is hetzelfde.

Omdat het probleem zich niet voordoet als de share wordt gekoppeld via SMB, vermoed ik dat het geen probleem in de schijven of RAID is.


Ik heb ook nog een cliënt op MX Linux 19.3 draaien, daar speelt het probleem veel minder en het proces in de bestandbeheerder (Thunar) verloopt ook een stuk gelijkmatiger (gaat niet met sprongen vooruit om daarna te hangen en de schijven in de server seeken ook niet als een gek), daar wordt constant zo'n 35MB/s gehaald.

Lezen van grote bestanden kent dit probleem niet, het is alleen schijven. Lezen komt op zo'n 110MB/s.


Wat kan de oorzaak zijn van dit trage schrijven van grote bestanden?


De /etc/fstab op de cliënt:

code:

192.168.117.51:/home /media/nfs/network_homes nfs rw,hard,intr,nosuid,nfsvers=3 0 0
192.168.117.51:/media/network_storage /media/nfs/network_storage nfs rw,hard,intr,nosuid,nfsvers=3 0 0

De /etc/exports op de server:

code:

/home 192.168.117.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
/media/network_storage 192.168.117.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)

Status v/d RAID1-arrays op de server:

code:

root@server1:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]                                                                                                                             
md0 : active raid1 sdc1[0] sdb1[1]                                                                                                                                                                                
      976759936 blocks [2/2] [UU]                                                                                                                                                                                 
                                                                                                                                                                                                                  
md1 : active raid1 sdd1[0] sde1[1]                                                                                                                                                                                
      976628736 blocks super 1.2 [2/2] [UU]                                                                                                                                                                       
      bitmap: 0/8 pages [0KB], 65536KB chunk                                                                                                                                                                      
                                                                                                                                                                                                                  
unused devices: <none>

[Mijzelf]

Josefien schreef op dinsdag 1 februari 2022 @ 10:52:
De /etc/exports op de server:

code:

/home 192.168.117.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)
/media/network_storage 192.168.117.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check)

Ik denk dat je probleem is opgelost als je sync veranderd in async. Nu moet je lokale nfs client steeds wachten tot aan de andere kant de data op schijf staat. Met async kan de disk cache van het server OS gebruikt worden.
Zou het kunnen dat de schijf op de server tamelijk vol is, waardoor je ook nog wordt geplaagd door fragmentatie?

[Josefien]

Mijzelf schreef op dinsdag 1 februari 2022 @ 11:34:
[...]

Ik denk dat je probleem is opgelost als je sync veranderd in async. Nu moet je lokale nfs client steeds wachten tot aan de andere kant de data op schijf staat. Met async kan de disk cache van het server OS gebruikt worden.
Zou het kunnen dat de schijf op de server tamelijk vol is, waardoor je ook nog wordt geplaagd door fragmentatie?

Met async is er toch meer kans op gegevensverlies juist omdat de cliënt niet wacht tot de server de data weggeschreven heeft? Al sinds de Debian 6.0-tijd gebruik ik sync, zou destijds de beste keuze zijn als het om belangrijke data gaat.

De schijven zijn verder niet vol... 1TB schijven die hooguit voor de helft gevuld zijn

Ik heb trouwens net op het Debian-systeem een andere bestandsbeheerder, Thunar, geïnstalleerd. Daarmee lijkt het probleem grotendeels weg, de schijven op de server seeken ook niet als een gek als er een groot bestand wordt weggeschreven... tot 25GB geprobeerd Zou het probleem dan toch in pcmanfm-qt zitten? Maar ja... Thunar is niks met de LXDE-desktop

[Mijzelf]

Josefien schreef op woensdag 2 februari 2022 @ 00:58:
[...]

Met async is er toch meer kans op gegevensverlies juist omdat de cliënt niet wacht tot de server de data weggeschreven heeft?

Dat is het geval met iedere diskcache. Bij stroomuitval of zo blijf je met niet-weggeschreven data zitten.

[Ben(V)]

Welke versie NFS gebruik je.
Als je nog NFSv2 gebruikt zit daar het probleem, die werkt alleen synchroon, pas vanaf NFSv3 werkt het asynchroon.
Dat geeft een enorme performance penalty.

Asynchroon is niets onveiliger dan synchroon, het betekent alleen dat de bron vast het volgende blok data kan gaan inlezen en versturen voordat het vorige blok is weggeschreven naar disk, maar als dat wegschrijven mislukt wordt dat blok gewoon weer opnieuw opgevraagd dus niets onveiliger. dan synchroon.

[Josefien]

De optie "nfsvers=3" forceert versie 3, dus het moet NFSv3 zijn. De optie weghalen betekent voor zover ik weet dat 'ie zelfs default naar NFSv4 gaat. Dat heb ik geprobeerd en het resultaat is hetzelfde

De sync vs. async zal vast uitmaken. Echter, is het toch vreemd dat het probleem zich blijkbaar alleen voordoet met de standaard bestandsbeheerder van LXDE (pcmanfm-qt) en niet met Thunar? En al sinds de Debian 6.0-tijd staat 'ie op async, nooit eerder heb ik dit probleem gehad

[Ben(V)]

Die optie werkt alleen als je NFSv3 hebt, als enkel nNFSv2 geïnstalleerd zal die optie genegeerd worden.
Welke versie je hebt kun je zien met nfsstat

[Josefien]

Het is versie 3.

Ik heb toch even de optie "async" in /etc/exports op de server geprobeerd. De schrijf-performance wordt héél véél hoger. Ik lees echter echt bijna overal dat je "async" alleen moet gebruiken bij data wat niet belangrijk is, omdat bij een crash je data verliest.

In de praktijk, wanneer loop ik extra risico om data te verliezen? Als de netwerkkabel los raakt tijdens het schrijven? De server vastloopt of de stroom er plots van af gaat? Of als de cliënt vastloopt? Van wat ik heb begrepen gaat het om de data die op dat moment nog in de cache zit v/d server en niet meteen naar schijf is weggeschreven. Is dit hooguit enkele secondes na een schrijfactie of (veel) langer?

[Ben(V)]

Er is echt geen verschil in sychroon en asynchroon, het verschil zit gewoon dat als er iets gebeurd je bij asynchroon data hebt overgestuurd die nog niet committed is en dus alleen bij de bron beschikbaar is.
Bij een crash of onderbreking verlies je nooit data, die is altijd bij de bron nog steeds beschikbaar.

Overigens is het beste gewoon geen nfs te gebruiken, het is gewoon onderhand een antiek systeem.
Gebruik gewoon smb (Samba), dat is de huidige standaard.

[Josefien]

Wat gebeurt er dan bij het verplaatsen van een bestand vanaf cliënt naar server (de knippen/plakken functie in de bestandsbeheerder)? De cliënt verwijderd het bestand al op het moment dat de server aangeeft het binnen te hebben, voor zover ik weet.

SMB mounten op een Linux cliënt zorgt er voor zover ik weet voor dat eigenaar/rechten niet meer werken zoals op een lokale ext4-schijf (chown en chmod). Als je een SMB-share in fstab zet hebben ook alle bestanden dezelfde eigenaar, dat is niet de bedoeling.

Ik heb ook Samba draaien op de server, maar da's voor de Windows cliënten.

[ Voor 27% gewijzigd door Josefien op 14-03-2022 01:16 ]

[Brahiewahiewa]

Josefien schreef op maandag 14 maart 2022 @ 01:15:
SMB mounten op een Linux cliënt zorgt er voor zover ik weet voor dat eigenaar/rechten niet meer werken zoals op een lokale ext4-schijf (chown en chmod). Als je een SMB-share in fstab zet hebben ook alle bestanden dezelfde eigenaar, dat is niet de bedoeling.

Dat is een keuze. Als jij inderdaad je SMB shares op anonymous zet dan zal iedere windows of *nix client als "guest" z'n bestanden wegschrijven. Als jij dat netjes via kerberos, LDAP of AD regelt, dan blijven je chown en chmod commands werken zoals je kunt verwachten

[vanaalten]

Ben(V) schreef op zondag 13 maart 2022 @ 22:50:
Overigens is het beste gewoon geen nfs te gebruiken, het is gewoon onderhand een antiek systeem.
Gebruik gewoon smb (Samba), dat is de huidige standaard.

SMB is net zo goed een antiek systeem. Zowel SMB als NFS worden actief gebruikt en ontwikkeld, dus ik zie nog niet zo snel dat NFS er uit gaat.

Heb je een bron die je mening wat NFS betreft ondersteund?

[Ben(V)]

Vele bronnen, maar misschien moet je dit artikel eens lezen.
https://www.cc.gatech.edu...10_fall/papers/nfsOLS.pdf

En op andere dan Unix systemen is het een regelrechte ramp om het te configureren.

[servies]

Ben(V) schreef op maandag 14 maart 2022 @ 09:39:
Vele bronnen, maar misschien moet je dit artikel eens lezen.
https://www.cc.gatech.edu...10_fall/papers/nfsOLS.pdf

Misschien moet je het artikel dan ook volledig lezen:

The previous sections have probably made it abundantly clear that NFS is far from being the perfect distributed file system. Still, in the Linux-to-Linux networking world, it is currently the best we have, despite all its shortcomings.

Daarnaast is het artikel ook al behoorlijk bejaard...

En op andere dan Unix systemen is het een regelrechte ramp om het te configureren.

Is dat de fout van NFS of de fout van die systemen?