On Mon, Apr 05, 2010 at 03:40:56PM -0700, Bill Sommerfeld wrote: > On 04/05/10 09:59, Nicolas Williams wrote: > >Will F. suggests that setting sync=barrier on /var should yield an > >unsupported system. I'd be happy with that too. > > In PSARC contexts, I generally prefer to avoid using words like > "supported" and "unsupported", since they are statements about the > likely future behavior of support personnel rather than direct > promises about the behavior of the system. > > How about: > > "Setting sync=barrier on the currently active root or /var > filesystem may result in out-of-spec behavior, application data loss > and increased vulnerability to replay attacks".
Yes, I like that. Datasets are cheap, so I wouldn't mind an actual /var/krb5/rcache dataset. > Another instance where sync=barrier could subtly cause trouble is > for any SMTP listener (sendmail or alternative). SMTP requires that > the receiver have the message in stable storage before sending the > "ok" to the sender, so that in the event of a crash, messages get > duplicated rather than dropped. Yes. Here too we could use having separate datasets for sendmail (and freinds) from the rest of the system. It'd be very nice if POSIX had always had an fbarrier()/fsync() distinction. Alas, it does not. > But, on the other hand, it seems like it might be clever to > temporarily set sync=barrier during package operations on a > freshly-cloned alternate BE -- if the package operation doesn't > complete, you have to torch the BE, anyway. :) sync=barrier on home directories will also help, but you also get into the mail delivery problem in cases where you download e-mail onto local folders, immediately deleting the copies on the server. Nico -- _______________________________________________ opensolaris-arc mailing list [email protected]
