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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
