DragonFly bugs List (threaded) for 2008-07
Re: hammer snapshot blocks on high file system activity
:I'm doing a "cpdup /usr/src /hammer/src" and a "hammer snapshot
:/hammer/snap-%Y" at the same time. "hammer snapshot" takes as long as
:"cpdup". Indeed, it does not return until the "cpdup" is completed.
:I think it's a problem in "hammer sync". But taking a snapshot is
:useless if one has to wait until no more file activity happens (which is
:rarely the case on a server).
It isn't waiting for the activity to stop, it is trying to sync out
the caches. It should be able to do that in parallel with running
activity but /usr/src is only ~450MB or so and it is likely that
a large chunk of the target copy will have been cached, depending
on how much memory you have.
It is possible to query the last synchronized transaction id
and generate a softlink based on that, without doing a new sync.
This would give you a snapshot as-of 0-60 seconds ago verses 'now'.
That is not usually what the user desires, though.
You'd need to copy more data, on the order of a few gigs, to measure
how long it takes snapshot to stage out the caches. There could be
a bug there but I'm pretty sure it is coded properly.
Remember that hard drives cannot do 70MBytes/sec worth of random I/O,
they can only do that rate when reading or writing large linear swaths.
When you get into more random I/O the data rate will drop to