Bug 62281
Summary: | /sbin/dump hangs system | ||
---|---|---|---|
Product: | [Retired] Red Hat Public Beta | Reporter: | Kris Urquhart <kurquhart> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | skipjack-beta1 | CC: | mharris, sct, stelian |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-04-12 04:58:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 63014 |
Description
Kris Urquhart
2002-03-29 02:45:28 UTC
This is a kernel issue, not a dump issue.... I hope those partitions aren't actually mounted and in use ? My understanding is that dump can handle mounted filesystems. Quoting from the man page dump(8): "files-to-dump is either a mountpoint of a filesystem or a list of files and directories to be backed up as a subset of a filesystem. In the for- mer case, either the path to a mounted filesystem or the device of an unmounted filesystem can be used." In my "Steps to Reproduce" example, I was using the device of a mounted filesystem, which the man page does not claim to support. So I changed "/dev/hdd1" to "/usr2", but I was still able to hang my system on the second try. As a reference point, this does work fine under RH7.2 (kernel 2.4.9-31) and dump 0.4b25. This should be fixed by the patch that went into the tree to fix the invalidate only on last unuse rule Can you try the 2.4.18-0.12 or later kernels in rawhide to see if those fix this issue ? I upgraded to kernel-smp-2.4.18-0.12, but no change. On a whim, I tried the non-SMP 2.4.18-0.12, but it hung as well. Do you still get the "invalidate: buffer busy" messages in your kernel logs with the updated kernel? Unfortunately, yes. I am now on kernel-smp-2.4.18-0.13. Maybe a clue: I made a typo and tried to dump a nonexistant mount point (/usr1), and I still got one "invalidate: buffer busy" message. But I guess this could be from reading /. note that amanda depends on dump working. Umpty-thousand amanda installs all over the world require dump to work on mounted filesystems. Ugly as that is, breaking this behaviour would be Bad. Hmm... I started getting this `buffer busy' message on my laptop too, with kernel 2.4.18-0.13, after I switched to a RAID1 filesystem for root, with the caveat that the RAID1 filesystem is in degraded mode, with a single replica at the moment (my removable disk died the other day :-( Failed to mention: I get these messages on shutdown, right before it marks the md devices clean. Yeah! I just ran up2date and got kernel kernel-smp-2.4.18-0.20. When I run dump, /var/log/messages is still heavily polluted with thousands of busy and dirty buffer messages, but my system no longer hangs ;) I ran my "Steps to Reproduce" a dozen times, and completed a zero level dump of all 9 partitions (18Gb used), and yet my uptime keeps increasing! Progress is always a good thing, wouldn't you say? This should be fixed in our kernels now. Look for it in rawhide in a subsequent kernel build. |