"David Schwartz" wrote:
> We're talking about the special case of small root partitions, such that
> softupdates inability to make empty space available quickly can make the
> difference between a major operation's success or failure.
>
> This is almost impossible on a 1.8Gb root partition.
[sorry, cannot resist...]
<real-life story>
Once upon a time, a month or so ago, there were ~30G of free space on
our 130G filesystem (with softupdates). An important application that
was going to create a ~35G file was running. It already written out 1G
or so. My colleague called me and sayed: "I removed a 10G of files TWO
HOURS ago and the space didn't free up yet!!! The free space isn't
going to appear!!! What do we do now???"
Well, after I stopped the application with kill -STOP, and temporary
killed off another I/O consuming program, the free space started to
appear and after several minutes there were >40G of free space.
</real-life story>
I think that the problem in this particular case was inability of the
syncer to run as fast as it supposed to. It is assummed that syncer
fsync 1/30 of all files and process the softupdates worklist every
second. If there are several I/O bound processes running, the syncer
will not have enough I/O bandwidth to do this job in the required speed.
Perhaps running several syncer processes could help. (OTOH, the machine
in question is running a quite old version of FreeBSD-CURRENT, it is
possible things are already better. I don't see serious changes in
softupdates code from that moment, tough. It is also possible that the
machine is mistuned in some way, but I don't know how :-()
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
