Bug 268741
Summary: | mkdumprd incorrectly reports remote filesystem space | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Maarten Broekman <maarten> | ||||||||||||||
Component: | kexec-tools | Assignee: | Cong Wang <amwang> | ||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||
Priority: | medium | ||||||||||||||||
Version: | 5.1 | CC: | rkhan | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | All | ||||||||||||||||
OS: | All | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2011-04-18 10:41:44 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: | |||||||||||||||||
Attachments: |
|
Description
Maarten Broekman
2007-08-30 19:49:50 UTC
Created attachment 181721 [details]
command output
Created attachment 181761 [details]
patch to make df output posix compliant in ssh case
I think this is what you need. Please use it to patch mkdumprd and let me know
if it fixes your problem. Thanks
Created attachment 181921 [details]
Patch (method 1)
The simplest patch is a 1 character change from -f10 to -f11.
Created attachment 181941 [details]
Patch (method 2)
This is a patch that is based off Neil's patch...it tails the df output before
returning it to mkdumprd (to remove the column headers).
in response to comment 3: Thats also the wrong patch. The column number you cut at will change based on the size of the mounted fs path, since w/o the -P option on df it will insert newlines for readability. in response to comment #4: Why are you tailing this twice? Please just confirm the patch as I provided it to you. Thank you The patch you provided eliminated the warning but did not do the proper comparison. The result of your patch was (running with bash -x): ++ ssh -q -o BatchMode=yes -o StrictHostKeyChecking=no netdump.40.81 df -P /var/crash/tmp.QVTtV28107 + remote_df='Filesystem 1024-blocks Used Available Capacity Mounted on /dev/cciss/c0d1p1 70005824 152748 69141852 1% /var/crash' ++ echo Filesystem 1024-blocks Used Available Capacity Mounted on /dev/cciss/c0d1p1 70005824 152748 69141852 1% /var/crash ++ tail -1 ++ tr -s ' ' '|' ++ cut '-d|' -f4 + available_size=Available + '[' Available -lt 16502136 ']' /sbin/mkdumprd: line 1647: [: Available: integer expression expected The second 'tail' is unneeded. The field that is needed is number 11. This is regardless of the newlines because of the way the output is returned and then echo'd. remote_df may have newlines embedded, but when it is echo'd back for the purporses of tailling, translating, and cutting, the newlines seem to be ignored. (see above output). Several ways around this are to use field 11 (since the newlines don't get echo'd into the pipelined commands in the current incarnation of the code) (aka patch in comment #3)...or to move the tail from the echo $remote_df line to the ssh command (patch in comment #4 minus the second tail)...or to combine the two and do all your pipelining within the ssh command so that the available space is returned from that rather than the whole df output. see attachments Created attachment 183161 [details]
corrected patch (method 2)
Created attachment 183181 [details]
unified patch
this performs all the parsing of df within the ssh command and returns the
available size.
oops, your right, the tail does need to be on the remote side. I'll add the patch from comment 7 to minimize remote side processing. Thanks. This will be available in RHEL5.2 This has been fixed for quite a while. This should be able to be closed now. |