[OpenAFS] AFS namei file servers, SAN, any issues elsewhere? We've had some. Can AFS _cause_ SAN issues?

[Kim Kimball]

Would this have affected clone operations as well?

It seems it would.

Thanks.

Kim


Robert Banz wrote:
>
>
> AFS can't really cause "san issues" in that it's just another 
> application using your filesystem.  In some cases, it can be quite a 
> heavy user of such, but since its only interacting through the fs, its 
> not going to know anything about your underlying storage fabric, or 
> have any way of targeting it for any more badness than any other 
> filesystem user.
>
> One of the big differences that would effect the filesystem IO load 
> that occurred between 1.4.1 & 1.4.6 was the removal functions that 
> made copious fsync operations.  These operations were called in 
> fileserver/volserver functions that modified various in-volume 
> structures, specifically file creations and deletions, and would lead 
> to rather underwhelming performance when doing vos restores, deleting, 
> or copying large file trees.  In many configurations, this causes the 
> OS to pass on a call to the underlying storage to verify that all 
> changes written have been written to *disk*, causing the storage 
> controller to flush its write cache.  Since this defeats many of the 
> benefits (wrt I/O scheduling) on your storage hardware of having a 
> cache, this could lead to overloaded storage.
>
> Some storage devices have the option to ignore these calls from 
> devices, assuming your write cache is reliable.
>
> Under UFS, I would suggest that you'd be running in 'logging' mode 
> when using the namei fileserver on Solaris, as yes, fsck is rather 
> horrible to run.  Performance on reasonably recent versions of ZFS 
> were quite acceptable as well.
>
> Anyhow, hope this is of some help.
>
> -rob
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
>