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

[Kim Kimball]

Thanks, Jason.

Is the hardware the same as what you tested last year?

Kim


Jason Edgecombe wrote:
> Is this what you need?
>
>   PKGINST:  SUNWsan
>      NAME:  SAN Foundation Kit
>  CATEGORY:  system
>      ARCH:  sparc
>   VERSION:  1.0
>   BASEDIR:  /
>    VENDOR:  Sun Microsystems, Inc.
>      DESC:  This package provides a support for the SAN Foundation Kit.
>    PSTAMP:  sanserve-a20031029172438
>  INSTDATE:  Jan 15 2008 10:37
>   HOTLINE:  Please contact your local service provider
>    STATUS:  completely installed
>     FILES:       22 installed pathnames
>                   4 shared pathnames
>                   1 linked files
>                  11 directories
>                   2 executables
>                 239 blocks used (approx)
>
>
> Running Solaris 9 09/05HW Sparc with Sun SAN foundation.
>
> Jason
>
> Kim Kimball wrote:
>> Hi Jason,
>>
>> Thanks!
>>
>> Can you tell me which flavor of SAN you're using?
>>
>> Kim
>>
>>
>> Jason Edgecombe wrote:
>>> 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.
>>>
>>> I can confirm Robert's observations. I recently tested openafs 1.4.1 
>>> inode vs 1.4.6 namei on solaris 9 sparc with a Sun Storedge 3511 
>>> Expansion tray fibre channel device. The difference is stagerring 
>>> with vos move and such. We have been using the 1.4.6 namei config on 
>>> a SAN for a few months now with no issues.
>>>
>>> Jason
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>>
>>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
>