[OpenAFS] Evaluating AFS for in house use, RFCs...
Fri, 03 Feb 2006 12:51:22 -0500
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
Mitch Collinsworth wrote:
> On Fri, 3 Feb 2006, Jeffrey Altman wrote:
>> I don't have hard numbers. Its a simple reality. If you are using an
>> AFS cache manager with anything close to a decent cache size, if you
>> need to access a file more than once, then the second time you access
>> it assuming it has not changed the reads will occur a local disk speed
>> instead of WAN speed.
> That's a lot of if's. If you're generating reams of data today and
> are only going to come back and analyze it tomorrow or next week then
> the cache is not necessarily any help. If you're generating many GB
> of data then the cache still thrashes. Remember the old UMich paper?
90% of users access the same small number of files. Whether they be
application DLLs or data files. Those files fit within a 1GB cache.
Now if you are using AFS to store generated data, then the cache isn't
going to help. The question is:
what is your usage model?
>>> The vast majority of users don't care about any of these operations.
>>> They just want to save data and retrieve it. Or maybe it's save it
>>> and forget about it. While installing the client might be a good
>>> thing, the user isn't going to buy it based on this logic. If we had
>>> numbers to show how much faster it is, that they would buy.
>> Then might I suggest you start running some performance tests.
> That's probably a good idea. My point is that the last time I saw
> numbers on this, AFS/RX did NOT handily beat Samba/SMB. It was in
> fact the other way around. Discovering that this has changed would
> be very helpful in convincing people to give AFS a try.
Using what for testing and in what environment?
If you were testing IBM AFS or OpenAFS 1.2 on Windows against the
built-in SMB client on a LAN then I would agree with you. The Windows
AFS client from those days was so broken not only did performance suck
but it crashes extremely frequently. The scary part is that there are
still so many people using it. I get the crash reports that are sent to
Microsoft. There are literally high hundreds of reported crashes a
month from those AFS clients on Windows.
Since 1.2 there have been significant performance improvements in the
Windows client which I documented in the periodic OpenAFS for Windows
Status Reports I publish.
OpenAFS 1.4 over OpenAFS 1.2:
54% improvement in writes with crypt
125% improvement in reads with crypt
143% improvement in writes without crypt
263% improvement in reads without crypt
OpenAFS 1.4 over IBM AFS 3.6 2.53:
31% improvement in writes without crypt
35% improvement in reads without crypt
(IBM doesn't support crypt mode in the Windows client)
The threading of the RX library has been significantly improved in
OpenAFS 1.4 and a number of race conditions would have resulted in
performance degradation have been fixed.
The OAFW cache manager has been enhanced. The cache is now stored
between AFS Client Service restarts. Rodney Dyer spoke yesterday about
how he is running applications out of AFS on Windows. One of those
applications being run entirely out of AFS is ProEngineer. This
application has an 88MB foot print that must be loaded each time it
starts. It also writes its configuration data to the user's redirected
profile directory which is stored in AFS. The application starts in
approximately 80 seconds via AFS with an empty cache and in 20 seconds
when the cache is populated. This is a big difference for end users
and it makes it possible to run applications such as these out of AFS.
I run Microsoft Office 2003 out of AFS. I would never consider doing
that over SMB. I had experience in a prior company of running
applications off of a Windows 2000 Server via SMB. There was nothing
but complaints from users. The SMB client does not cache and unless
you marked all of the EXE and DLL files so that Windows would copy
them entirely into the paging file, the constant re-reading of the
binary data from the file server made the use of the application
unbearable. With AFS this is not a problem.
However, I go back to the earlier comment about the usage model.
If what you are doing is generating lots of data to write into file
system for archival storage, then the cache manager does not help
you and the default AFS chunk size will hurt as well. The block
size determines how much data is written per StoreData RPC. The default
chunk size for the Windows client in 1.2 and in IBM AFS was 4K. In 1.4
it is now 128K. However, if you are doing a lot of writing of large
quantities of data you will want to increase this to something much
larger. The max chunk size is 1024MB. You can set the default chunk
size as part of a transform you apply to the OpenAFS for Windows MSI.
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature