On Fri, 2011-11-18 at 23:08 +0100, John Hughes wrote: > 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. Read the rest of the thread... Jim and Nick already made this point, and I've replied. The fact of the matter is that most application writers remain blithely oblivious of the need to fsync() as the ext4 people know all to well: see the attempts to impose the fully posix-compatible 'data=writeback' mode as the default and the catastrophe that occurred when 'data=ordered' semantics changed for the rename() syscall. Adding new failure modes needs to be done with care, or GNOME will crash and/or your word processor _will_ lose your last hour or so of work. > > 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). They are a workaround to the problem of users failing to plan ahead and/or jobs not running as quickly as originally scheduled. You can run them if you feel safe doing so, but they should not be a mandatory feature to ensure data isn't lost during normal operation. BTW: instead of trying to change existing kernel and gssd semantics, why not concentrate on adding the equivalent of krenewd/kstart? > >> 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? So that the kernel can flush out any dirty data while the ticket is valid, and block further asynchronous read/write operations (either by making them synchronous, or by returning an appropriate error). We may also want to consider closing open file state and possibly freeing up locks so that other processes with valid credentials may still access the data. IOW: that allows for an _orderly_ failure mode instead of the current catastrophic mode. The application gets a chance to deal with any errors _before_ the data is lost. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
