From Aaron.Wright@nd.edu Mon Apr 16 21:34:34 2012
From: Aaron.Wright@nd.edu (Aaron Wright)
Date: Mon, 16 Apr 2012 16:34:34 -0400
Subject: [OpenAFS-win32-devel] Windows OpenAFS Client Data Transfer Slowness
Message-ID: <8D7ABFEB8540934DB54AECDF259D0D6018779EAF16@ICE-MBX-1.ice.nd.edu>
--_000_8D7ABFEB8540934DB54AECDF259D0D6018779EAF16ICEMBX1icende_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Has anybody experience slowness with transferring data from the AFS Volume =
to local hard on Windows 7 SP1? I am only transferring 300 mb, and it take=
s 7 to 5 minutes to transfer the data. I am using the latest OpenAFS Clien=
t 1.7.9, and I have tried adjusting the AFS cache parameters.
Any suggestions would be great.
Thank you,
V/r
---------------------------------------------------------------------------=
--
Aaron Wright
University of Notre Dame
Systems Engineer
System Services
OIT - EIS/Core Services
Aaron.Wright@nd.edu
(574) 631-2390
---------------------------------------------------------------------------=
--
--_000_8D7ABFEB8540934DB54AECDF259D0D6018779EAF16ICEMBX1icende_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Has anybody expe=
rience slowness with transferring data from the AFS Volume to local hard on=
Windows 7 SP1? I am only transferring 300 mb, and it takes 7 to 5 mi=
nutes to transfer the data. I am using the latest OpenAFS Client 1.7.=
9, and I have tried adjusting the AFS cache parameters.
Any suggestions would be great.
Thank you,
V/r
=
-----------------------------------------------------------=
------------------
Aaron Wright
<=
p class=3DMsoNormal>
U=
niversity of Notre DameSystems Engineer
System Services
OIT – EIS/Core Services<=
o:p>
Aaron.Wright@nd.edu
(574) 631-239=
0
----------------------------------------------------=
-------------------------
&n=
bsp;
=
--_000_8D7ABFEB8540934DB54AECDF259D0D6018779EAF16ICEMBX1icende_--
From jaltman@secure-endpoints.com Tue Apr 17 12:02:43 2012
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Tue, 17 Apr 2012 07:02:43 -0400
Subject: [OpenAFS-win32-devel] Windows OpenAFS Client Data Transfer Slowness
In-Reply-To: <8D7ABFEB8540934DB54AECDF259D0D6018779EAF16@ICE-MBX-1.ice.nd.edu>
References: <8D7ABFEB8540934DB54AECDF259D0D6018779EAF16@ICE-MBX-1.ice.nd.edu>
Message-ID: <4F8D4DD3.9090201@secure-endpoints.com>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig34CDBF66F100303557936BED
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
A SysInternals Process Monitor trace and a Wireshark capture would be
useful in identifying the source of the delays.
What anti-virus solution are you using?
On Monday, April 16, 2012 4:34:34 PM, Aaron Wright wrote:
> Has anybody experience slowness with transferring data from the AFS
> Volume to local hard on Windows 7 SP1? I am only transferring 300 mb,
> and it takes 7 to 5 minutes to transfer the data. I am using the
> latest OpenAFS Client 1.7.9, and I have tried adjusting the AFS cache
> parameters.
>
> Any suggestions would be great.
>
>
>
> Thank you,
>
>
>
> V/r
>
>
>
>
>
> -----------------------------------------------------------------------=
------
>
> Aaron Wright
>
> University of Notre Dame
>
> Systems Engineer
>
> System Services
>
> OIT =E2=80=93 EIS/Core Services
>
> Aaron.Wright@nd.edu
>
> (574) 631-2390
>
> -----------------------------------------------------------------------=
------
>
>
>
--------------enig34CDBF66F100303557936BED
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJPjU3VAAoJENxm1CNJffh4tU4IALr/J841nEepYpJQE9h67dR6
FeDMTRobKH+mXptjTBKEiisOFCLuBUPcBEv6p18AB+UtU13pIowiL2iowJTxhvz1
1Pmdd/G9ny7xFO6U/XNRlgNe05D8kqhAbjCQJjMmvJmizNyn0MPbVlGrLO94QZAn
p4414WuBEJvwJjYO/pHhw6TmtTcsz7YOK+tOeIZVdtph2bm2nVs+MC4pdgfQ8EoJ
YhNFNEBn47kz6sqQdyr7j/eSob+0d0FxNbuPqZWVV/OCV9Jb2dD+HsYc4QpsIWh/
sRof35HVxfyRjYyiESkI51CzL1Eey7Ue1X8W6Yr6xv+hWrlGT6hoylJ2tqrN4Ug=
=vVjO
-----END PGP SIGNATURE-----
--------------enig34CDBF66F100303557936BED--
From Aaron.Wright@nd.edu Tue Apr 17 14:37:07 2012
From: Aaron.Wright@nd.edu (Aaron Wright)
Date: Tue, 17 Apr 2012 09:37:07 -0400
Subject: [OpenAFS-win32-devel] Windows OpenAFS Client Data Transfer
Slowness
In-Reply-To: <4F8D4DD3.9090201@secure-endpoints.com>
References: <8D7ABFEB8540934DB54AECDF259D0D6018779EAF16@ICE-MBX-1.ice.nd.edu>
<4F8D4DD3.9090201@secure-endpoints.com>
Message-ID: <8D7ABFEB8540934DB54AECDF259D0D6018779EB16B@ICE-MBX-1.ice.nd.edu>
SSBhbSBydW5uaW5nIE1jQWZlZSBFbnRlcnByaXNlIDguOCB3aXRoIHRoZSBsYXRlc3QgdmlydXMg
ZGVmaW5pdGlvbnMgZnJvbSAxNUFwcmlsMjAxMi4gICBJIHdpbGwgZ2V0IHlvdSBTeXNJbnRlcm5h
bHMgUHJvY2VzcyBNb25pdG9yIHRyYWNlIGFuZCBhIFdpcmVzaGFyayBjYXB0dXJlcy4NCg0KDQoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBYXJvbiBXcmlnaHQNClVuaXZlcnNpdHkgb2YgTm90cmUg
RGFtZQ0KU3lzdGVtcyBFbmdpbmVlcg0KU3lzdGVtIFNlcnZpY2VzDQpPSVQg4oCTIEVJUy9Db3Jl
IFNlcnZpY2VzDQpBYXJvbi5XcmlnaHRAbmQuZWR1DQooNTc0KSA2MzEtMjM5MA0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmVmZnJl
eSBBbHRtYW4gW21haWx0bzpqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tXSANClNlbnQ6IFR1
ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDc6MDMgQU0NClRvOiBBYXJvbiBXcmlnaHQNCkNjOiBvcGVu
YWZzLXdpbjMyLWRldmVsQG9wZW5hZnMub3JnDQpTdWJqZWN0OiBSZTogW09wZW5BRlMtd2luMzIt
ZGV2ZWxdIFdpbmRvd3MgT3BlbkFGUyBDbGllbnQgRGF0YSBUcmFuc2ZlciBTbG93bmVzcw0KDQpB
IFN5c0ludGVybmFscyBQcm9jZXNzIE1vbml0b3IgdHJhY2UgYW5kIGEgV2lyZXNoYXJrIGNhcHR1
cmUgd291bGQgYmUgdXNlZnVsIGluIGlkZW50aWZ5aW5nIHRoZSBzb3VyY2Ugb2YgdGhlIGRlbGF5
cy4NCg0KV2hhdCBhbnRpLXZpcnVzIHNvbHV0aW9uIGFyZSB5b3UgdXNpbmc/DQoNCk9uIE1vbmRh
eSwgQXByaWwgMTYsIDIwMTIgNDozNDozNCBQTSwgQWFyb24gV3JpZ2h0IHdyb3RlOg0KPiBIYXMg
YW55Ym9keSBleHBlcmllbmNlIHNsb3duZXNzIHdpdGggdHJhbnNmZXJyaW5nIGRhdGEgZnJvbSB0
aGUgQUZTIA0KPiBWb2x1bWUgdG8gbG9jYWwgaGFyZCBvbiBXaW5kb3dzIDcgU1AxPyAgSSBhbSBv
bmx5IHRyYW5zZmVycmluZyAzMDAgbWIsIA0KPiBhbmQgaXQgdGFrZXMgNyB0byA1IG1pbnV0ZXMg
dG8gdHJhbnNmZXIgdGhlIGRhdGEuICBJIGFtIHVzaW5nIHRoZSANCj4gbGF0ZXN0IE9wZW5BRlMg
Q2xpZW50IDEuNy45LCBhbmQgSSBoYXZlIHRyaWVkIGFkanVzdGluZyB0aGUgQUZTIGNhY2hlIA0K
PiBwYXJhbWV0ZXJzLg0KPg0KPiBBbnkgc3VnZ2VzdGlvbnMgd291bGQgYmUgZ3JlYXQuDQo+DQo+
DQo+DQo+IFRoYW5rIHlvdSwNCj4NCj4NCj4NCj4gVi9yDQo+DQo+DQo+DQo+DQo+DQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gLS0tLS0tLQ0KPg0KPiBBYXJvbiBXcmlnaHQNCj4NCj4gVW5pdmVyc2l0eSBv
ZiBOb3RyZSBEYW1lDQo+DQo+IFN5c3RlbXMgRW5naW5lZXINCj4NCj4gU3lzdGVtIFNlcnZpY2Vz
DQo+DQo+IE9JVCDigJMgRUlTL0NvcmUgU2VydmljZXMNCj4NCj4gQWFyb24uV3JpZ2h0QG5kLmVk
dQ0KPg0KPiAoNTc0KSA2MzEtMjM5MA0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0NCj4N
Cj4NCj4NCg0K
From lvoge@dimins.com Thu Apr 19 16:35:06 2012
From: lvoge@dimins.com (Lodewijk Voege)
Date: Thu, 19 Apr 2012 11:35:06 -0400
Subject: [OpenAFS-win32-devel] 1.7.x and large volumes
Message-ID: <4F9030AA.7010604@dimins.com>
hello,
FYI, somewhere between 1.7.4 and 1.7.10, OpenAFS (on Windows 7 x64) appears to
have lost the ability to write to large volumes. with 1.7.10 Windows thinks
such volumes are full and doesn't even try to write anything. the property
dialog shows all available space as used.
OTOH, with 1.7.4 it thinks such volumes are empty, with the property dialog
showing it all as unused, and can then write just fine.
oddly enough, fs diskfree says the same thing for both cases:
C:\Program Files\OpenAFS\Client\Program>fs diskfree y:\
Volume Name kbytes used avail %used
user.lvoge -1 911972623-911972624 -91197262300%
so maybe something changed along the path that that -1 takes to where Windows
decides whether or not to try and write?
Lodewijk
From jaltman@your-file-system.com Thu Apr 19 17:12:09 2012
From: jaltman@your-file-system.com (Jeffrey Altman)
Date: Thu, 19 Apr 2012 17:12:09 +0100
Subject: [OpenAFS-win32-devel] 1.7.x and large volumes
Message-ID:
--_25DFD729-F964-0A21-2F0E-8CDF8978CA1A_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Its a bug in the file server. That patch to fix it was committed via gerri=
t=
--_25DFD729-F964-0A21-2F0E-8CDF8978CA1A_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"
Its a bug in the file server. That patch to fi=
x it was committed via gerrit
From: Lodewijk Voege=
Sent: 4/19/2012 4:36 PM
To: openafs-win32-=
devel@openafs.org
Subject: [OpenAFS-win32-devel] 1.7.x and =
large volumes
hello,
FYI, somewhere between 1.7.4 and =
1.7.10, OpenAFS (on Windows 7 x64) appears to
have lost the ability to w=
rite to large volumes. with 1.7.10 Windows thinks
such volumes are full =
and doesn't even try to write anything. the property
dialog shows all av=
ailable space as used.
OTOH, with 1.7.4 it thinks such volumes are e=
mpty, with the property dialog
showing it all as unused, and can then wr=
ite just fine.
oddly enough, fs diskfree says the same thing for bot=
h cases:
C:\Program Files\OpenAFS\Client\Program>fs diskfree y:\<=
br>Volume Name &=
nbsp; kbytes &nb=
sp; used avail %used
user.lvoge  =
; &n=
bsp; -1 911972623-911972624 -9119726230=
0%
so maybe something changed along the path that that -1 takes to w=
here Windows
decides whether or not to try and write?
Lodewijk
_______________________________________________
OpenAFS-Win32-devel mai=
ling list
OpenAFS-Win32-devel@openafs.org
http://lists.openafs.org/ma=
ilman/listinfo/openafs-win32-devel
=
--_25DFD729-F964-0A21-2F0E-8CDF8978CA1A_--
From Aaron.Wright@nd.edu Fri Apr 20 19:45:09 2012
From: Aaron.Wright@nd.edu (Aaron Wright)
Date: Fri, 20 Apr 2012 14:45:09 -0400
Subject: [OpenAFS-win32-devel] Windows OpenAFS Client Data Transfer
Slowness
In-Reply-To: <4F8D4DD3.9090201@secure-endpoints.com>
References: <8D7ABFEB8540934DB54AECDF259D0D6018779EAF16@ICE-MBX-1.ice.nd.edu>
<4F8D4DD3.9090201@secure-endpoints.com>
Message-ID: <8D7ABFEB8540934DB54AECDF259D0D601877ACA294@ICE-MBX-1.ice.nd.edu>
SmVmZiwNCg0KSSBjcmVhdGVkIGEgcGNhcCBmaWxlLCBhbmQgaXQncyAzNTYgbWIgY29tcHJlc3Nl
ZC4gIEhvdyBkbyB5b3Ugd2FudCBtZSB0byBzZW5kIGl0IHRvIHlvdT8NCg0KVGhhbmtzLA0KDQpB
YXJvbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQWFyb24gV3JpZ2h0DQpVbml2ZXJzaXR5IG9m
IE5vdHJlIERhbWUNClN5c3RlbXMgRW5naW5lZXINClN5c3RlbSBTZXJ2aWNlcw0KT0lUIOKAkyBF
SVMvQ29yZSBTZXJ2aWNlcw0KQWFyb24uV3JpZ2h0QG5kLmVkdQ0KKDU3NCkgNjMxLTIzOTANCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IEplZmZyZXkgQWx0bWFuIFttYWlsdG86amFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbV0gDQpT
ZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjAzIEFNDQpUbzogQWFyb24gV3JpZ2h0DQpD
Yzogb3BlbmFmcy13aW4zMi1kZXZlbEBvcGVuYWZzLm9yZw0KU3ViamVjdDogUmU6IFtPcGVuQUZT
LXdpbjMyLWRldmVsXSBXaW5kb3dzIE9wZW5BRlMgQ2xpZW50IERhdGEgVHJhbnNmZXIgU2xvd25l
c3MNCg0KQSBTeXNJbnRlcm5hbHMgUHJvY2VzcyBNb25pdG9yIHRyYWNlIGFuZCBhIFdpcmVzaGFy
ayBjYXB0dXJlIHdvdWxkIGJlIHVzZWZ1bCBpbiBpZGVudGlmeWluZyB0aGUgc291cmNlIG9mIHRo
ZSBkZWxheXMuDQoNCldoYXQgYW50aS12aXJ1cyBzb2x1dGlvbiBhcmUgeW91IHVzaW5nPw0KDQpP
biBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDQ6MzQ6MzQgUE0sIEFhcm9uIFdyaWdodCB3cm90ZToN
Cj4gSGFzIGFueWJvZHkgZXhwZXJpZW5jZSBzbG93bmVzcyB3aXRoIHRyYW5zZmVycmluZyBkYXRh
IGZyb20gdGhlIEFGUyANCj4gVm9sdW1lIHRvIGxvY2FsIGhhcmQgb24gV2luZG93cyA3IFNQMT8g
IEkgYW0gb25seSB0cmFuc2ZlcnJpbmcgMzAwIG1iLCANCj4gYW5kIGl0IHRha2VzIDcgdG8gNSBt
aW51dGVzIHRvIHRyYW5zZmVyIHRoZSBkYXRhLiAgSSBhbSB1c2luZyB0aGUgDQo+IGxhdGVzdCBP
cGVuQUZTIENsaWVudCAxLjcuOSwgYW5kIEkgaGF2ZSB0cmllZCBhZGp1c3RpbmcgdGhlIEFGUyBj
YWNoZSANCj4gcGFyYW1ldGVycy4NCj4NCj4gQW55IHN1Z2dlc3Rpb25zIHdvdWxkIGJlIGdyZWF0
Lg0KPg0KPg0KPg0KPiBUaGFuayB5b3UsDQo+DQo+DQo+DQo+IFYvcg0KPg0KPg0KPg0KPg0KPg0K
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0NCj4NCj4gQWFyb24gV3JpZ2h0DQo+DQo+IFVuaXZl
cnNpdHkgb2YgTm90cmUgRGFtZQ0KPg0KPiBTeXN0ZW1zIEVuZ2luZWVyDQo+DQo+IFN5c3RlbSBT
ZXJ2aWNlcw0KPg0KPiBPSVQg4oCTIEVJUy9Db3JlIFNlcnZpY2VzDQo+DQo+IEFhcm9uLldyaWdo
dEBuZC5lZHUNCj4NCj4gKDU3NCkgNjMxLTIzOTANCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0t
LS0tDQo+DQo+DQo+DQoNCg==