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

[Kim Kimball]

Thanks Rob!

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.
>
That's what I thought.  Todd's message about the changes to code to 
reduce inode creation times aside.

> 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.
>
Right.  We saw significant improvement on the Hitachi 9585 when we 
upgraded to 1.4.6.  The Hitachi USP continues to spew scsi command timeouts.
> 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.
>
Yep, we're running in logging mode.  Unfortunately Solaris doesn't allow 
me to relocate the log -- it has to be on the same partition that is 
experiencing the command timeouts -- and when the UFS log write timeout 
occurs Solaris unmounts the partition and asks for (drum roll) you 
guessed it!  fsk
> Anyhow, hope this is of some help.
>
Tons.  Thanks Rob.

Kim

>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
>