I am not anxious to get into debugging the Linux kernel.
OTOH, I have developed a lot of load test applications for testing high
transaction count systems.
Are your regression tests in CVS, and if so how hard is to write an additional
The test I have been using is simple pair of shell scripts, so it does not seem
that it would take much to tie it into your framework.
I have been monitoring it for failures manually, but it should not be too hard
to put some kind of timeout around the lvcreate --snapshot test and report an
error if it exceeds x minutes.
Obviously, I would rather give you guys a way to duplicate the problem that can
be incorporated into your regular regression testing than simply working with
you to debug this one instance, and then not feel confident that future
releases have not reintroduced the problem.
Deployment and Integration Specialist
Compaq ASE - Tru64 v4, v5
Compaq Master ASE - SAN Architect
The Norcross Group
>> On Thu, 2002-08-22 at 16:43, Greg Freemyer wrote:
>> > All,
>> > I have not been successful at getting reliable Read-Only snapshots of
>> XFS via LVM. Since XFS is being used in Enterprise quality applications,
>> I suggest this is a major shortcoming that should be prioritized.
>> > BTW: Are there any snapshot related tests in the XFS regression tests?
>> No, there aren't. Frankly, snapshot has not gotten a lot of attention
>> > When a failure occurs the lvcreate --snapshot command will freeze up.
>> If that's the failure, looking at a kdb backtrace of the "stuck" process
>> would be helpful, and might give us an idea of where to look.
>> Testing a CVS kernel for the same behavior would also be a good
>> > A manually entered xfs_freeze -u will release the lvcreate. (The
>> VFS-lock patch effectively is calling xfs_freeze -f internally prior to
>> starting the snapshot process.)
>> > FYI: Adrian Head believes that the VFS-lock patch is more reliable than
>> not having it and wrapping the lvcreate --snapshot call with explicit
>> xfs_freeze calls. I have not tried that.
>> If things are working as intended, that should not be the case - the end
>> result should be that xfs runs the same code, whether you did it via a
>> manual userspace command, or the automatic vfs-lock patch.
>> Sending some debug output from kdb would help - but also, take a look at
>> that list of work Steve posted today, and realize that there are lots of
>> things going on at the moment. :)
>> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
>> sandeen@xxxxxxx SGI, Inc. 651-683-3102