Re: Bestanden delen via NFS
Op 19-09-12 18:04, Wouter Verhelst schreef:
> On Tue, Sep 18, 2012 at 02:54:57PM +0200, Paul van der Vlis wrote:
>> Hallo,
>>
>> Ik loop tegen wat problemen aan bij het delen van bestanden via NFS, dit
>> gaat om Debian stable (zowel client als server).
>>
>> Als ik een bestand open op de ene PC (met OpenOffice) en daarna weer
>> sluit, kan ik hem soms alleen nog maar read-only openen op de andere PC.
>> Ik heb nog geen oplossing anders dan de server rebooten.
>
> Dat lijkt op problemen met NFS locking. Gebruik je NFSv3 of NFSv4?
In dit geval NFS3.
Maar zoals ik al schreef in antwoord op Bjorn, heb ik wellicht een test
fout gemaakt door een foute umask.
>> Een ander probleem waar ik tegenaan loop is dat de lijst met bestanden
>> in b.v. Nautilus niet ververst wordt. Als er door een ander een nieuw
>> bestand geplaatst wordt, dan zie ik dat pas nadat ik een refresh
>> uitgevoerd heb. Weet iemand daarvoor een oplossing?
>
> Neen.
>
> Zo'n bestandlijsten gebruiken dingen als inotify and dnotify,
> Kernel-APIs die de applicatie een melding geven als een andere
> applicatie een wijziging doorvoert in een directory waar de eerste
> applicatie naar "luistert". Daardoor zijn die wijzigingen in jouw
> nautilus ook "onmiddelijk" zichtbaar: nautilus moet niet pollen, maar
> krijgt een bericht van de kernel:
>
> schrijvende applicatie -> kernel -> nautilus
>
> Om de wijzigingen nu te laten zien, moet nautilus aan de kernel vragen
> wat er gewijzigd is sinds de vorige keer (of misschien geeft inotify dat
> meteen mee door; daar ben ik even niet zeker van). Da's niet zo veel
> data; en vermits de kernel het toch net weggeschreven heeft, zit dat nog
> in de cache, dus dat gaat redelijk snel.
>
> Zoiets over het netwerk doen wordt redelijk complex. Als een bepaalde
> applicatie op de ene client een wijziging wilt doorvoeren die gezien
> moet worden op een tweede client, dan is er flink wat meer nodig:
>
> schrijvende applicatie -> kernel client 1 -> NFS server -> kernel client 2 -> nautilus
>
> Ik sla hier eigenlijk nog wat stappen over, vermits je NFS server ook
> een kernel heeft, maar da's effe minder belangrijk.
>
> Uiteraard heeft de tweede client-kernel het op dat moment nog niet in de
> cache zitten, dus moet dat nog van de NFS-server gedownload worden. En
> als er nu 100 machines zijn in het netwerk die allemaal "luisteren" naar
> die directory, dan moeten die allemaal een berichtje krijgen van de
> NFS-server dat er een wijziging is (met eventueel de daadwerkelijke
> wijziging). Dat worden heel wat berichtjes, en da's niet zo goed voor je
> performance.
>
> En dan heb ik het nog niet over wat er zou gebeuren als er meerdere
> applicaties zijn die allemaal via NFS en inotify "luisteren" naar een
> directory om dan aan de hand daarvan andere wijzigingen naar dezelfde
> directory te schrijven... op één machine is dat allemaal geen probleem,
> maar over netwerk wordt zoiets snel een packet storm.
Bedankt voor je verhaal. Zoiets kan ik me voorstellen. Maar wordt dom
pollen dan niet toch weer een optie? Of iets als een timeout op de cache?
Ik kreeg nog een hint van Alexander Larsson van Redhat dat dit vroeger
met "fam" kon maar ook dat de code slecht wordt onderhouden, en het maar
de vraag is of het nog werkt. Fam lijkt in Debian te zitten, en daar ook
wel onderhouden te worden:
http://packages.debian.org/squeeze/fam
Met vriendelijke groet,
Paul van der Vlis.
--
Paul van der Vlis Linux systeembeheer, Groningen
http://www.vandervlis.nl
Reply to: