On 11/18/2011 09:33 PM, Trond Myklebust wrote:
On Fri, 2011-11-18 at 20:19 +0100, John Hughes wrote:
On 11/18/2011 07:35 PM, Trond Myklebust wrote:
You need a big fat warning somewhere that enabling this option WILL
cause data corruption...
Why?
Because some process may get the EACCES error half way through it's
operation.
No. Because the process can receive a reply to the write() syscall that
indicates that the data is safe,
There is no reply from "write(2)" that says the data is safe.
but the EKEYEXPIRED error will cause
the data to be lost when the client tries to actually commit the data to
disk.
The traditional Kerberos/AFS way was to behave the old way, and use
krenew to keep the ticket from expiring if a process needed to be run
overnight.
Which is just wrong: the general intention of kerberos security is to
ensure that the _user_ has ACKed an operation. Renewing tickets without
user input would circumvent that intention. If you need to have the job
run overnight, then ask for a longer lifetime for your ticket.
Ok, so no need for the hang on ticket expired then.
(Although I don't think renewable tickets and krenew are a figment of my
imagination).
What other way is there of fixing the problem if we are going to keep
the "hang 'till a ticket turns up" behaviour? (rewrite gnome and kde
seems kind of a big job).
Notify the kernel that a ticket is about to expire so that the kernel
can decide to block the process on the next NFS-related syscall.
I don't understand. How is it a win to block processes *before* the
ticket has expired?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
