On Sat, 2007-08-04 at 17:48 -0400, Theodore Tso wrote:

On Sat, Aug 04, 2007 at 01:13:19PM -0700, Arjan van de Ven wrote:

quoted

there is another trick possible (more involved though, Al will have to
jump in on that one I suspect): Have 2 types of "dirty inode" states;
one is the current dirty state (meaning the full range of ext3
transactions etc) and "lighter" state of "atime-dirty"; which will not
do the background syncs or journal transactions (so if your machine
crashes, you lose the atime update) but it does keep atime for most
normal cases and keeps it standard compliant "except after a crash".

That would make us standards compliant (POSIX explicitly says that
what happens after a unclean shutdown is Unspecified) and it would
make things a heck of a lot faster.  However, there is a potential
problem which is that it will keep a large number of inodes pinned in
memory, which is its own problem.  So there would have to be some way
to force the atime updates to be merged when under memory pressure,
and and perhaps on some much longer background interval (i.e., every
hour or so).

on the journalling side this would be one transaction (not 5 milion)
and... since inodes are grouped on disk, you can even get some better
coalescing this way... 

Wonder if we could do inode-grouping smartly; eg if we HAVE to write
inode X, also write out the atime-dirty inodes in range X-Y to X+Y
(where Y is some tunable) in the same IO..


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>