New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"zpool remove" on a log device being silently ignored #6677
Comments
referencing: #1422 zpool remove on mirrored logs fails silently #1530 Removing cache device fails For reference (FreeNas): |
To be fair to the "repo collaborator" (me) that closed your issue the first comment stating the issue is "stale" is dated Nov 8, 2016. The issue was closed on Jul 9, 2017, almost one year later, which is a lot of time to provide more information or even simply add a comment stating you're still experiencing the issue. The fact your other account shows no activity in 2 years doesn't help either. As a side note, you can also comment on closed issues and ask for them to be re-opened. |
Thanks for your clarifications @loli10K. I didn't receive any warning that the issue was marked "Stale", nor was I aware that such a marking meant I was required to provide more information, lest it be closed. As per commenting on the previous issue and asking for it to be reopened, I would rather open a new one as the reason for closing the previous wasn't clear to me. Anyway, as you can see the problem is still happening, and not only with me: see for example here: http://list.zfsonlinux.org/pipermail/zfs-discuss/2017-September/029413.html In case you require any more information, please say so and I will oblige. |
I too have the problem of a ZFS log vdev that I cannot remove for the life of me. I initially tried to remove it over a year ago, at which time it resided on a mirror of 2 SD partitions. Removal of the mirror return without error, but the log was still there. While recovering from a system disk failure a few days ago I was afraid I had lost the pool. I moved it to another system (minus the log which was on the system disk and which I thought had been lost) and was startled to have zpool import find all the data vdevs but report that the pool was unrecoverable because there where known to be other disks needed, but they could not be identified. After some googling and hand holding from folks on the internet, including Durval, who started this thread about a similar problem he faces, I tried import -m and thankfully the pool came right up. So, I once again tried to remove the now single log device (last year I had removed one of the pair in hopes that I could then remove the other). I tried the following, all of which appeared to work, but failed to remove the device
I looked at the ZIL device info with zdb So, the system thinks it is being removed. Based on various old posts I’ve seen scattered around the net, it appears that the removal is not occurring because somewhere space is still in allocated for the ZIL even though there are no active ZIL entries. I ran across someone who recompiled ZFS to remove the checks that caused this to block the deletion and was able to remove his “stuck” log. It has been too many years in the past that I did such things so I’m not sure I want to give that a try (and the post was about 2 years old) I assure the ZoL developers that this problem is in no way closed and hope something like a -f flag can be implemented to allow this vdev to finally be removed without requiring user to cook up their own special purpose ZoL version. My most recent attempt to remove the log was on a Kubuntu 16.04 system, the latest "Long Term Support" version of Kubuntu. It is about 18 months old, so it is possible it is not running the most recent ZoL, but Durval, who has the same issue is running the latest and greatest. So, it is seems this problem that dates back years is still with us. Lest I sound like a complainer. Please accept my most hearty thanks for making ZoL available. I use it every day and truly appreciate this wonderful software. Sure, I am dying to have encryption supported and would love for this bug to be fixed, but I am thankful that I have ZoL to protect my data. In the years I have been using ZoL I have never lost any data or sleep over the prospect of doing so. Thank you. Thank you, |
Confirmed! |
Just following it up, with ZFS 0.7.3-1 the problem continues exactly the same (ie, "zpool remove" on the log device returns with status code zero and prints no messages) but the log device remains in the pool. I stand available to help fix this, as I haven't yet recreated the pool. |
Closed by mistake (slippery finger on the "Close and comment" while zooming/panning on my cell screen) and then reopened. Sorry about that. |
Also having this problem on FreeBSD 11.1 |
Are you sure about that, @mrpippy ? In fact, I fixed this pool a few days ago by rebooting the machine from a pendrive with FreeNAS 11.1U4 (which is based on FreeBSD 11.1-STABLE), importing the pool, and removing the device using the exact same This IMHO seems to indicate that this issue does not happen in FreeBSD 11.1 and is rather restricted to ZoL. |
My pool started on Solaris and then FreeBSD 11.1 and 11.2, I've never used it with ZoL. I tried removing the log device months ago, it still shows up in I haven't exported/imported the pool since, that would be worth a try. zdb from FreeBSD 11.2:
|
Sadly the error also still exists on Linux. For some reason both SSDs in the log mirror died. Romving the mirror does not work even after offlining the disks. It silently fails. Any idea? ` pool: zroot
|
Forget to tell. Already tried the patch in the old thread. Does not seem to work. |
this is a bug tracker, not a support forum. please use the email list |
Sorry, for the confusion. But pool remove exiting with 0 status, despite not working seems like a bug to me. Especially since this was already happening for quite some time. Please let me know, what more input is needed to solve the bug. If there is no intention of fixing it, the bug issue should probably be closed. |
you haven’t shared the command that failed, so it is not clear that there is a bug in your case. also, the return code for zpool and zfs commands is not an indicator of success or failure. |
Oh, I'm very sorry. Please find the command and the status afterwards. As the remove fails silently I believe it is the very old bug.
|
OK, i reworked the patch from the old issue to ignore the device not being offline. It was removed this way. |
Can you share? |
Or better yet, make a PR? |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
Hello,
As my original issue (#4067) was closed by a repo collaborator, I can't reopen it; so I'm opening this new one.
Just to be clear, this issue is pretty much alive; the commands and output below are from Springdale EL6 (RHEL 6 clone) running kernel 4.1.12 (based off Oracle's UEK package) with ZoL 0.7.1-1:
Please let me know if you need anything else, and I would appreciate being contacted before closing this again as "stale" with no further request to (or input from) me.
Thanks in advance,
-- Durval.
The text was updated successfully, but these errors were encountered: