Brooks Davis wrote:
> While moving a large (1GB) file from one parition to another today, I
> noticed an odd, reproducable pause. Basicly you create a large file
> somewhere and then delete it like so:
[ ... ]
> Within the next minute or so, I see a pause where the whole system stops
> for 5-10 seconds. There is a burst of disk activity accompanying this.
> It's easiest to observe this in X with some active dock apps or monitors
> running so you'll see them stop updating.
>
> Is this something that cane be fixed or is it just life with
> softupdates? I ask in part because I'm considering a new backup
> architecture which will generate files in the range of several 100GB so
> I'd hate to find out this hang is going to be proporational to file
> size.
It's the write data, not the delete, that's being sync'ed out by
the soft updates clock.
Basically, you've written more data than you can actually write
in that period of time, so there is a bottleneck on the sync
operation.
It's actually avoidable, with tuning, but there are limits on that
that are imposed by the amount of buffer memory, etc., which are
impossible to exceed (e.g. do this with enough data, and nothing
you can do can prevent the pause). See also:
/usr/src3/sys/ufs/ffs/README
...specifically, the long description of the following tunables:
debug.max_softdeps - limit on any given resource
debug.tickdelay - ticks to delay before allocating
debug.max_limit_hit - number of times tickdelay imposed
debug.rush_requests - number of rush requests to filesystem syncer
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
