From owner-freebsd-hackers Tue Oct 8 12:59:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0956437B401 for ; Tue, 8 Oct 2002 12:59:33 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 897D343E65 for ; Tue, 8 Oct 2002 12:59:32 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g98JxOvU036374; Tue, 8 Oct 2002 12:59:28 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210081959.g98JxOvU036374@gw.catspoiler.org> Date: Tue, 8 Oct 2002 12:59:24 -0700 (PDT) From: Don Lewis Subject: Re: Mount option "nomtime"? To: olli@secnetix.de Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <200210081908.g98J809u055938@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8 Oct, Oliver Fromme wrote: > I should have been more specific in my examples. Sorry. > > Think about INN with using cycbuffers (CNFS) when storing > news articles (which is pretty standard on fullfeed news > servers). Those cycbuffers are a bunch of large files. > Their size never changes, but a lot of data is written to > them all the time. The same goes for the overview data > when using the so-called buffindexed storage. INN itself > does not need the mtime information of the buffer files. > > Another example would be "oops", which is a very fast, > lightweight web proxy. It uses cyclic buffer files to > store the cached data, similar to INN's CNFS. > > I think in the above cases, a "nomtime" option would indeed > save some unnecessary overhead. Probably not much, especially if you are using soft updates. The in-kernel copy of the inode will get updated on every write, but the on-disk copy will only get written when the soft updates timer for it goes off, which I think would be once every 10 seconds and is tunable. I don't think you'll see much reduction in load compared to all the other I/O that's going on. Noatime won't help much in your examples either. It only buys you a lot if the data is spread over a large number of files. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message