Date: Tue, 8 Oct 2002 20:38:36 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: Oliver Fromme <olli@secnetix.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Mount option "nomtime"? Message-ID: <20021008183835.GA65525@falcon.midgard.homeip.net> In-Reply-To: <200210081717.g98HHxjp051029@lurza.secnetix.de> References: <200210081717.g98HHxjp051029@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 08, 2002 at 07:17:59PM +0200, Oliver Fromme wrote: > Hi, > > The mount(8) manpage doesn't mention it, so I assume that > there is no such thing as a "nomtime" option (analogous > to the "noatime" option) to prevent the mtimes of inodes > from being updated for each write access. > > But maybe is there some other way to achieve that? > > For example, updating of mtimes is not neccessary on a > file system that contains a news spool, or the content of > a web cache, or similar transient data. Disabling those > updates might prevent quite some superfluous overhead. > > I'm tempted to try implementing "nomtime" myself, but I > would prefer hearing some opinions first before wasting > time on something completely stupid. :-) Since I suspect that most writes occur when you are first creating the file and that modifications in existing files are fairly uncommon I think any performance gains would be quite minor. Also since the most common file modification operation is probably to append data at the end of the file, rather than modify data in the middle of the file, the inode would still have to be changed to reflect the changed size of the file, it can't be very expensive to update the mtime at the same time. Also various sorts of file caches (like news spools or web caches) probably uses the mtime (and sometimes atime) to determine which files are oldest and therefore should be deleted first when diskspace is running low. Not updating the mtime on such files could lead to "interesting" results as the wrong files are flushed. Considering the above I think that a "nomtime" option would be much more likely to create problems than to solve any problems. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021008183835.GA65525>