Re: Hmmmm.

From: Mark Treacy <>
Date: Wed, 19 Mar 1997 11:11:47 +1100

> If unlinking expired objects is time consuming because of the constant
> inode metadata updates, it might be an idea to suggest to people with busy
> caches to 'mount -u -o async /cachedir' on those OSs that support it.
yep. The caveat being that the filesystem is less hardened against system
failures. If you have a system that stays up for a year at a time, then
it probably doesn't matter.

We use "prestoserve" cards in our caches, and it is definately beneficial
to performance, up to a limit. That limit is when you have so many writes
to the disk that the (prestoserve) cache fills up. The system will them
become limited by the rate at which the disk drives can sustain writes.
The (prestoserve) cache coalesces some of the writes, but it can't eliminate
all of the writes.

The same will apply to filesystems that asynchronously write the
inode/directory blocks. Eventually you run out of memory and the system
has to write back the dirty blocks, at this point you become write limited.
i.e. sync
                unlink() rate = n * disk_wps
with cache/async
                unlink() rate = m * disk_wps
and you should see m > n. Where you see "unlink() rate" you can substitute
"creat() rate", "stat() rate" etc.

Anyway, decoupling the unlinks to separate processes and/or making
the filesystem update operations asynchronous will reduce the variation
in time spent in routines like storeGetSwapSpace() (over high water mark),
storeMaintainSwapSpace(), and even storeDoRebuildFromDisk(). This is
desireable because these variations cause the number of active file
descriptors to grow which exacerbates the problem as non linear routines
like comm_select then take longer to run which causes the number of active
file descriptors to grow, and so on.

> Linux does not need this, apparently, because ext2fs defaults to async
> mode. Async mode causes the inode metadata to be written to disk at the
> next sync(), rather than immediately.
This can cause nasty periodic delays on some systems.

 - Mark.
Received on Tue Mar 18 1997 - 16:22:41 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:43 MST