Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 1996 13:32:29 -0700
From:      David Greenman <davidg@Root.COM>
To:        Terry Lambert <terry@lambert.org>
Cc:        rashid@rk.ios.com (Rashid  Karimov), davidg@Root.COM, jgreco@solaria.sol.net, hackers@FreeBSD.ORG
Subject:   Re: Breaking ffs - speed enhancement? 
Message-ID:  <199605292032.NAA02323@Root.COM>
In-Reply-To: Your message of "Wed, 29 May 1996 13:24:37 PDT." <199605292024.NAA14236@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> > >Am I just totally whacked out, or is this perhaps a reasonable thing to do,
>> > >given that I'd really rather not have to absorb the extra write activity on
>> > >the filesystems...  does anybody else perceive any value along these lines
>> > >of thought?
>> > 
>> >    I added an option "noatime" to mount/fstab and implemented a special
>> > per-mount flag for this in the kernel. I was only interested in disabling
>> > the access time; I wanted the inode change time and modify times to still
>> > work correctly. My application, of course, was wcarchive - a machine with
>> > millions of files that spends about 1/3-1/2 of all of it's disk I/O just
>> > updating the access times in the inodes.
>> 
>> 	David, could you submit those patches ? May be we can even add
>> 	this as an OPTION to the kernel config file? 
>
>There is a school of thought that says "shall be updated" in POSIX is
>not the same as "shall be committed to stable storage" (the traditional
>BSD implementation).
>
>This would let access times be updated in core, but only scheduled to
>be written at a later time (not forced out immediately).

   They already are updated in-core and only written out during sync. The
problem is that on busy machines, *thousands* of inodes have to be written
out during the sync, and this can take 10+ seconds. With sync occuring every
30 seconds, this means the machine spends 33% of it's disk I/O time *just*
writing out inodes. The access time is almost completely useless on a busy
fileserver, so this is just a waste.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605292032.NAA02323>