From owner-freebsd-hackers Sun Jan 12 11:03:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA11228 for hackers-outgoing; Sun, 12 Jan 1997 11:03:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA11223 for ; Sun, 12 Jan 1997 11:03:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA25856; Sun, 12 Jan 1997 11:51:35 -0700 From: Terry Lambert Message-Id: <199701121851.LAA25856@phaeton.artisoft.com> Subject: Re: mount -o async on a news servre To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Sun, 12 Jan 1997 11:51:35 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <199701120209.VAA09833@crh.cl.msu.edu> from "Charles Henrich" at Jan 11, 97 09:09:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > very little time writing, and massive amounts of time reading. Unless im > mistaken, with noatime set, meta data is almost never created, and even then > only updated in the case of the scheduled sync() call. Sorry; you are mistaken. The "noatime" option says not to act on access time update events. The majority of FS updates that result from read activity are the access time being updated on getdents() calls in opendir/readdir; a Minor number of access events are generated for the article files themselves. You seem to be confusing "noatime" with "async". The "async" option acts pretty much as you describe. > For performance reasons you would tend to break apart the standard > "USER newsreader/poster" operation and "newsfeed" operations, both > of which are read/write, both of which have many times the reads as > writes. > > In other words, if you run as suggested back a few lines, there performance > loss of running async should be damn close to zero.. ??? What I suggested is that if you are not writing data that you can't replicated from another news server, you can run "async", and if you crash, you can rebuild your entire news spool (if necessary) by nntp transfer. I also suggested that local article postings are one of the things you *can't* get back this way, *unless* you locally post to a seperate server that *isn't* running "async" and won't need rebuilt. So if all you ever store on the news spool of the "async" server is data that came from the news spool on non-"async" servers, then it's OK to run "async". The problem we are trying to solve is "what happens to local users postings when the news server running 'async' crashes and loses some or all of its data" ...which it *will* do because that's the risk "async" exposes you to. You could rephrase this as "Is there any safe way to run 'async'?", with the answer being "Yes, if you only read from, and never post directly to, the 'async' server". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.