-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
extreme delays when running zpool import -FX #1128
Comments
@micia The delay is expected in your case. ZFS is basically attempting to rollback through previous TXGs until it finds a good one and this can take some time depending on how far back it needs to go. The more concerning issue is that this was required in the first place. Usually this sort of issue means your hardware isn't properly honoring cache flush commands. As for the dmesg output that has been fixed in the latest ZoL source and is harmless. It will be fixed once Sabayon picks up the latest ZoL packages. |
@behlendorf I pushed updated ZFS code into Sabayon's kernel source tree earlier today. It should be included with the next kernel update that the Sabayon developers do. |
According to the zpool import -fFX -R /mnt/sabayon rpool output, there have been 30 seconds of lost transactions, the command still took the same amount of time to complete, if that's expected then there is no problem, what made me think that it could have been a bug is the dmesg output that is apparently a completely different issue. By the way, wouldn't it be nice to include some documentation about the -X option (that did manage to get my system up and running again) in the man page? |
@micia It's undocumented because if your hardware is behaving correctly it should never be needed. That said, with us pushing ZFS in to Linux there's no avoiding it running on a wider variety of misbehaving hardware than ever before. So we probably should add the option to the man page with a nice description of why this shouldn't be needed, but if it is how to use it as a last resort. |
According to @micia in IRC, he was removing a large quantity of files when the power outage occurred. It might be possible to reproduce his failure in a VM. |
I'm having similar problems and currently trying to recover two disks forming a mirrored pool. The original machine had memory errors so I am trying to recover on a different machine but with the same version numbers for most software. So far the zpool import command does not help me. Even worse: when I look at vmstat -d, the counters do not add up, they stay at the same number. Can I post dmesg output here? Should I open a new issue? I could really use some help, guys. |
@slacks42 I began an outline of an un-importable pool diagnostic procedure on the zfs-discuss mailing list which you can see at https://groups.google.com/a/zfsonlinux.org/d/msg/zfs-discuss/LuxsAqaK6AM/sQNz8mVohNMJ. Unfortunately, memory errors can be very toxic because the ZFS code is filled with a ton of asserts and other internal consistency checks. |
Due to a power outage I've been forced to try some recovery tool to restore my ZFS pool.
The ZFS pool, named rpool, is located in the /dev/sda disk, which is entirely formatted with ZFS, it contains the root for my installation (Sabayon 10 amd64, kernel 3.6).
These operations have been performed in live mode, on a netbook with limited amount of RAM (1GB) and no swap at all.
Output for importing the rpool ZFS pool was:
My first attempt has been the -F option to recover the pool, output from:
zpool import -nfF -R /mnt/sabayon rpool
was none, it simply executed the command and returned me to the prompt, running the command without the n option wasn't successful:
My next attempt has been adding the -X option to the command, running:
This operation hanged for about 40 minutes before completing.
Dmesg output was:
Output of free -m during the "stall" condition was:
Mem: 982 858 123 0 5 43
-/+ buffers/cache: 809 172
Swap: 0 0 0
The text was updated successfully, but these errors were encountered: