[OpenAFS] Windows cache problem revisited...
Jeffrey Altman
jaltman@columbia.edu
Thu, 04 Dec 2003 14:06:03 -0500
This is a cryptographically signed message in MIME format.
--------------ms040605070302030601060206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Rodney:
You mis-read some of what I said. The file cache is memory mapped not
in one huge chunk (if that was true allocating a 256MB cache would
result in an instantaneous 256MB memory allocation) but in N chucks of
the specified chunk size. I think the default values are 20MB and 32KB
chunks. Hence, the allocation of up to 640 handles.
I haven't looked at all of the specifics but ... when you write data
into the cache a chunk is allocated and mapped to the disk file. This
chunk remains in memory for some period of time to avoid the need to
re-read the data from the cache into memory. When you are copying a
huge file the process is sequential and hence all of the data is
processed once and then ignored. Hence for some period of time the
entire backing store ends up in memory. Eventually those cache pages
will time out due to lack of use and be flushed.
There are many things lacking in the cache management. Off the top of my
head these are the two big ones:
1. there is no distinction between the disk cache size and the in
memory cache size
2. application as part of the open mode for a file have the ability
to provide hints regarding the access usage: sequential, random
access, etc. these hints are not seen by the AFS cache and
therefore cannot be used to optimize the memory usage
<flame on>
On a personal note, I must say that I am getting a bit tired of your
rants. They are not in the least bit constructive. Insulting the work
of the people who wrote and designed the original code does not help.
You sound like a spoiled child. "I want ...", "I want ...", "Why can't
I ...", "Who's idea was it to ...".
<flame off>
We are all aware that the design of OpenAFS for Windows is not
appropriate for the Windows 2000/XP/2003 environments with multiple
(perhaps simultaneous) users per machine with roaming profiles and
integrated Kerberos authentication. The work that must be done is
substantial and for the most part should not be done piece meal.
Instead, a significant re-design of the architecture must be performed
to better integrate AFS into Windows and its local security architecture.
I certainly understand your frustration. OpenAFS on Windows has
certainly been the hand me down sibling of the Unix counterpart. Rants
will not change this. The only thing that will is a commitment of
resources and money. A really rough estimate of the work to be done
falls somewhere between $750,000 and $1 million range. Clearly none of
the individual organizations which use OpenAFS on Windows are can afford
to put up that kind of money. Perhaps smaller chucks collected from a
number of organizations would allow an appropriate team of developers to
be put together either to perform the work or at least to design an
architecture and manage a team of volunteers to do the work.
I would ask that anyone who would be interested in contributing either
money or a substantial number of developer hours over an extended period
of time to contact me directly.
Jeffrey Altman
Rodney M Dyer wrote:
> All,
>
> I've been thinking a bit more about the problem I'm having with
> OpenAFS on Windows 2k/XP. When transfering large files to and from
> AFS the Windows OS performance can slow down considerably, all most to
> the point of non-usability. To alleviate this problem I've been told
> not to use a large AFS cache because the client service opens a real
> memory buffer that is the same size as the cache file. On closer
> examination I find this to be ridiculous and intolerable. The point
> of the AFS cache is to eliminate multiple network reads for files that
> haven't changed on the network by grabbing them off the local disk
> cache. We should be able to, and most people do, use very large
> caches. I'm familiar with people using gig sized caches these days.
> Granted, depending on what your are doing, there will be a point of
> diminishing returns with larger and larger cache sizes. But that is
> for me to decide!
>
> I want to know why the AFS client service uses a real memory buffer in
> the first place? I want to know why you can't turn this 'feature'
> off? Who decided that the in-memory buffer would be a good idea? Can
> we get this changed?
>
> Thanks ahead for any feedback (sorry for the rant),
>
> Rodney
>
> Rodney M. Dyer
> Windows Systems Programmer
> Mosaic Computing Group
> William States Lee College of Engineering
> University of North Carolina at Charlotte
> Email: rmdyer@uncc.edu
> Web: http://www.coe.uncc.edu/~rmdyer
> Phone (704)687-3518
> Help Desk Line (704)687-3150
> FAX (704)687-2352
> Office 267 Smith Building
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
--------------ms040605070302030601060206
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
HAYJKoZIhvcNAQkFMQ8XDTAzMTIwNDE5MDYwM1owIwYJKoZIhvcNAQkEMRYEFCmWNJpcLEwQ
hRQvWtUvbEqvx1o1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3
EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK
MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg
MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAbuUaw3QWL94pogOQR5Lt9I5pu8sA
nTVZJHJIjNcBahelU9B2QL1w7q6IM15JIRxzI7PUeLAnbHa856X0HMZ/AKfWO2+fMMcX83Fu
n72pQnsKU6wkgpXig4OuDX1myIFbBlmDC5E4gI8Jjz7qkJePJfsdgyhPK01ebm4Kw7oiNHLa
jTaqUKmsK8MTkSgDMSiqg7T2QfMeRVYIc0JCvPrBExWijtBUqmZfRMkFsFEMiU1muF71+A8h
aRLul2Q0XFSd8J00PF8Zb/1VpAGPseIBxPXL36IjI64sTMMYH8JkYbQ5cqOO/iL0VhOeSRw+
q1eMTbusfiGj+LAlvXOG6gM1QwAAAAAAAA==
--------------ms040605070302030601060206--