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

[Jason Edgecombe]

Yes, we are running Solaris 9. Our Solaris footprint is shrinking, so 
there hasn't been much of a push to upgrade to Solaris 10. Our Linux 
footprint has been growing slowly, so it might make more sense to 
migrate to Linux.

Jason

Dale Ghent wrote:
>
> Note the you only need SUNWsan if you're running Solaris < 10.
>
> Why one would run Solaris < 10 these days is beyond me, but...
>
> /dale
>
>
> On Mar 20, 2008, at 3:40 PM, Kim Kimball wrote:
>
>> 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