Re: NFS atime

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Mon, 27 Sep 2004 20:28:43 +0200

On Mon, Sep 27, 2004 at 07:45:33PM +0200, jesk wrote:
> >Atime steht im Widerspruch zum Caching - was nutzt dir ein Cache
> I>nhalt, wenn du auf den Sync der Inode auf dem Server warten musst?
> >Unter anderen aus diesem Grund gibt es einen Attibute Cache und man
> >sieht nicht zwingend sofort die aktuellen Attribute.
> >Klassischer Seiteneffekt ist das Ändern von Permissions auf einem
> >Client - die anderen Clients brauchen dann mitunter einige Zeit, bis
> >die die geänderten Attribute sehen.
> >Ich weiß nicht an welchen Stellen ihr die atime geprüft habt, aber
> >es gibt atime Funktionalität im Source und wenn dieser funktioniert
> >ist die atime zumindest ebenfalls vom Delay durch den Attribute Cache
> >betroffen.
>
> Hi, ich habe das mit Caching zuvor schon getestet. Caching ist zwar in der
> Tat fuer ein Delay verantwortlich, jedoch nicht bei atime, da ist es so,
> dass jegliches Update ignoriert wird und der Server ( so jedenfalls bei
> mir ) nie das Update vornimmt. Anders herum, wenn das Update serverseitig
> stattfindet, dann wird nach ein paar Sekunden bis hin zu mehreren Minuten
> das Update den Clients publiziert..
> sehr strange das ganze.

Stimmt - kann ich so bestätigen - auch mit einem Solaris und NetBSD
als Client.
Das ist nicht mal auf dem Client selber sichtbar, was bei üblichen
Attrib Delays der Fall sein müsste.
Offen gesagt ist mir die Sache mit der atime aber auch ziemlich egal,
da die beim Backuplauf eh für alle Files regelmässig hochgesetzt wird.
Von daher ist es mir ganz recht, dass der unnütze Traffik nicht
stattfinded.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 27 Sep 2004 - 20:30:05 CEST

search this site