Date: Sat, 11 Jan 1997 14:59:31 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: stesin@gu.net (Andrew Stesin) Cc: terry@lambert.org, scrappy@hub.org, hackers@freebsd.org Subject: Re: mount -o async on a news servre Message-ID: <199701112159.OAA24261@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95.970112015625.4758B-100000@trifork.gu.net> from "Andrew Stesin" at Jan 12, 97 02:17:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The INN history file would probably need to be rebuilt after each crash > > God save me! as I told earlier. :-) > > Just for now I consider that "noatime" mount option > is the best balance between reliability and performance > on FreeBSD, right? Probably; considering that you don't have make dependencies. It *may* result in some articles being prematurely expired following a crash; not a real problem. The "access time" option is mostly security related, and for data migration to an archive ...neither one of these should be a big problem on a news server. There is some confusion, I think, between "shall be marked for update" vs. "shall be updated" vs. "shall have updates committed to stable storage" when people try to interpret POSIX. I think most of the wins you get from noatime could come without the sacrifices if "shall be updated" was interpreted to mean something other than committing the date stamps to stable storage (a sync write in the current code, each time a directory or file is accessed). Barring hacking on the code, "noatime" is a good compromise soloution for using the existing code without modifiecation. If I were running a big site, I would be tempted to run a reading host and a *seperate* posting host. A reading host would be, by definition, a passive news spool with no locally generated data; I'd run the FS for the news spool in async mode. Using a seperate server for posting, I could run the posting host with atime and sync... so my users postings would not be lost because of a crash. Depending on how the client software operates, you might have to run a request forwarder (ie: the posting host may have to pretend to be a full nntp server to let your users read from the same host, but it would forward all nntp read requests to the passive news spool, while satisfying write requests locally. Articles posted by users would be spooled to the reading host as "just another feed". In event of a crash, the lost data can be recovered from all feed hosts... including the posting host. If the news had not been propagated priior to the crash, it would still be propagated after recover. Ideally, a near future version of FreeBSD will have soft updates, and you will no longer get better speed from running async (soft updates give you speed equal to async and reliability equal to sync). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701112159.OAA24261>