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. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
