[OpenAFS-devel] Re: Breaking callbacks on unlink
Jeffrey Altman
jaltman@your-file-system.com
Thu, 26 Jan 2012 13:25:59 -0500
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig894A4974AF3B89BA06F5654D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 1/26/2012 1:03 PM, Andrew Deason wrote:
> I saw some emails to you today that sounded like someone wanted it :)
>=20
> But sure, some people may want something like that. Some people want
> hardmount. (Not saying we need an option for that at this time or
> anything, though.)
That is certainly one interpretation. The other is that they want the
root cause of the data corruption problems to be fixed.
>>> I believe/assume what is being considered "right" is the latter
>>> option.
>>
>> ?
>=20
> I definitely heard some advocacy for this the last time we were arguing=
> about this (how the fileserver-side should make this determination,
> which is true, but...). But yeah, this isn't what went in.
The file server now disable keep alives when performing disk I/O. If
the I/O doesn't return, the clients will timeout. This is in tree.
> Well, I was talking about idledead stuff here, specifically client
> behavior, which isn't going to screw up another client. I think that
> matters much more when you're talking about server behavior, in which
> case, yes, certainly.
Clients that use idle-dead timeouts to cancel and retry RPCs do have
negative impacts on other clients. Repeated retries of RPCs that the
file server cannot process because a vnode is already locked result in
the thread pool becoming depleted. The side effect is that a file
server will enter a state where it can process no requests much sooner
than it otherwise would have.
--------------enig894A4974AF3B89BA06F5654D
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)
iQEcBAEBAgAGBQJPIZq5AAoJENxm1CNJffh4LTMIAJEhwvK/F5P7tY+XBNNh8DXK
z8WAaq1iEPUZozF07hAVN47gF2H48DsodS+AnItbBoNppv3lz3fpGX5/Q+sxDeti
vEbJ9rOFAvNtV8YufhNtN80RVrmjgnJ/bQiKo2XfZRIBhDStShnvFMN/lg2F/SnW
sophWTnPdGrYLMP3wb0OcIDfhm4OaYyQYeBNpWlErLH233cnj7vKfEJMTVSAz/Vl
dzTyVQ1VysqbNHDu60WxnajaFwpf55gdpJBxG7ygCXmuVSC7/X/eeQMARDasppF4
x8LAxfD5KeF6aqpG1JJZaPmsrXZBLyJ2VekHMTWDNedDQxPRiACV1N7MelFln48=
=4eV4
-----END PGP SIGNATURE-----
--------------enig894A4974AF3B89BA06F5654D--