[OpenAFS] Windows cache problem revisited...

Thu, 04 Dec 2003 17:19:12 -0500

This is a cryptographically signed message in MIME format.

--------------ms000209050709070301080002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rodney:

Apology accepted.

Just so you are aware because I do not believe the the Request Tracker 
is working
correctly that bug number 2628 has now been created to address this 
request with you as the requestor.  The points you make are all valid.  
It is simply not reasonable with the
current implementation to compare the Unix and Windows implementations.  
The Windows implementation was designed for much smaller systems.  I 
can't even remember how much
memory my Win95 system had.  Could it have even been 8mb?  The first NT 
system I had
certainly did not have more than 32MB.  Today my PIII laptop has 512MB; 
and the
Pentium M laptop I hope to receive in the next few weeks has 2GB of 
RAM.  We are
talking about completely different orders of magnitude. 

The algorithms used by the the Cache Management code in OpenAFS for 
Windows was
perfectly reasonable when the expected cache size was small.  Times have 
changed.
In order to support an AFS cache of multiple GBs you really need a two 
level cache
architecture.  Perhaps an in-memory cache of up to 8% or 10% of total 
system ram
backed by the file system store of 1GB or 2GB.

Unfortunately, that is not present in today's code.  At some point in 
time, hopefully
sooner rather than later, funding will become available for a complete 
re-write in
which all of the issues you have raised can be addressed.  To make sure 
information
is not lost I have been creating bugs in the Request Tracker in addition 
to the
private lists I maintain myself.

Rob and I are not defending the current implementation.  Since neither 
one of us
have the time or resources to rewrite the code at present, we are simply 
explaining
how it works and its limitations so that you can make the best use of it 
in your
environment.  You are as always welcome to:

    * spend the time learning the current implementation
    * asking questions as needed
    * experimenting with alternatives
    * discussing your results and
    * submitting patches when the work is complete

Jeffrey Altman

Rodney M Dyer wrote:

> Rob, Derrick, Jeffrey,
>
> I'm not sure what the right way to respond is here...so I'll just 
> start in.
>
> Jeffrey, thank you for the polite lesson in mailing list social 
> etiquette.  It may be deserved, maybe not.  I did say ahead of time 
> that I was "sorry for the rant".  Sometimes I use this list to vent my 
> frustrations.  I wasn't directing my frustration toward you at all, 
> and I'm sorry if you may have interpreted it that way.  I do not in 
> the least want to imply that the AFS/OpenAFS developers haven't done a 
> good job in keeping the software alive, especially for Windows users.  
> I am thoroughly pleased with the community at large, that this list 
> exists, and that continued development is being done.  I do however 
> like to make problems known, and sometimes I do this with a manner 
> that probably isn't in some peoples best interests.  Many of the best 
> rants and heated debates take place in mailing lists.  Just look at 
> the Linux kernel mailing list for example.  To think that I might be 
> annoying someone here, how outrageous!  ;)
>
> Moving on...
>
> Rob, Jeffrey, your responses were good in that they are some of the 
> deeper 'technical' information I was looking for.  However, part of 
> the problem is that I'm not overjoyed about these so called 
> 'performance improvements' made by the "memory mapped chunks" because 
> there don't seem to be any.
>
> Yes, reducing the cache has made my life better, if you can call it 
> that.  It is now set to 48 Meg instead of 256 Meg.  The problem now is 
> I don't have enough room to really cache much.  I'm now loading down 
> the network more than I should.  Part of my frustration is seeing that 
> others "can" set their caches to 1 Gig or greater.   See...
>
> http://www.acm.uiuc.edu/wiki/space/Setting+up+your+computer+as+an+AFS+client 
>
>
> So how does the cache implementation differ under the Unix/Linux 
> environment.  Does the 'nix environment use a memory mapped file?  If 
> a 'nix machine has only 256 Meg of real memory, then what do you think 
> a good cache size would be?  What do you guys on the mailing list set 
> your caches to on 'nix, and Windows?  If the cache implementation is 
> different under 'nix/Win then why?  Does 'nix slow down when 
> transfering large files?
>
> My problem isn't always related to copying large files.  Many times I 
> will walk into our student labs and logon with a test account just to 
> do a quick test.  I find that many machines have entered the 'slow' 
> condition and logons take considerably longer than normal as well as 
> application slow downs.  I find this especially curious because we 
> restart the AFS client service every night at 4:00am and delete the 
> cache file.  You would think that our lab machines could take 5 or 10 
> different people logging on and off to do work during the day without 
> entering the 'slow' state.  If I reset the cache down to 48 Meg for 
> those machines it should 'fix' the problem, but then the network will 
> probably be loaded more, which makes the cache kind'a moot.  Granted, 
> we are now getting new machines with a Gig of memory so this problem 
> may not show up as often.  So maybe I should just shut up and throw 
> hardware at the problem right?
>
> In the end, I don't see the efficiency gained by the algorithm used to 
> cache AFS data on Windows.  I'd either like this changed in the 
> future, or given an option to not use any memory mapping.  Windows 
> itself does it's own file caching for recently used files.  Why would 
> AFS need to do it on top of that?
>
> Sorry again Jeffrey,
>
> (Thanks for the moral support Mike!)
>
> Rodney
>

--------------ms000209050709070301080002
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC
AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf
MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h
bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA
sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL
sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A
aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy
DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5
f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB
FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA
DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r
2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6
jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5
MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH
jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd
Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0
zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr
ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe
+QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2
l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S
58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB
AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAzMTIwNDIyMTkxMlowIwYJKoZIhvcNAQkEMRYEFDI1ZHPxTgFc
N75PEy9MqzUI+kTrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3
EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK
MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg
MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAGrgLolDzov7yoSHao/BXJlcDBFf0
5bFsxW5ujKOZ2FUjqgByAf5YKfg5B++wugRhJ4tiaiZXFLrmsgXbwpxWO8+6McvhRbk2rgDU
zlh/BZDOOpLlsJoqzvdO40VKi+RcYH4ZBLCOmxh96rnRakCiUhkZolmkO0CSQ3sHDTEkdcNX
Ls1bBlBnc+SjSAGpKw58PMqdi5GBhmDWIkUAIIFwRSQgin9ddfC9wANdvByDt9ukGG+jrRgE
VZeNPhxcIrGlNvYWfcQd9VR58D5jEx9Do158Xq1fQe0aVvjIdLpvPKYgzz9b/c3vJ4PEoL2Y
oqFcAt0drSnRS66+oCh3gcyL4QAAAAAAAA==
--------------ms000209050709070301080002--