zpool import taking weeks ...

Ulysse 31 ulysse31 at gmail.com
Mon Jan 20 10:23:36 UTC 2014


Hi all,

Finally solved this problem ^^, hope that my answer would help others
have similar problems in the future:
After read some more threads, have confirmed that DDT is stored only
on ARC, and since ARC is only in RAM (not swappable), the import
process on the live cd was starting slowly filling ram and pushing
userland to swap ...
The result was that the system still running without out of swap
message space but zfs simply "stalls" without having enought ram to
continue import ...
I then remember that i had 2 pre-prod servers with 64Gb RAM on each,
scavenged one and added 64Gb on the zfs server (which ended so with
128Gb)
Booted the server normally (native Freebsd) and the import run then
correctly within approximately 12h, taking 90Gb for ARC (not checked
but suppose that it was mainly DDT).
Once booted, destroyed the remotely sync'ed dataset that caused crash,
that took another 30Gb on RAM, loading used mem to 120Gb and something
like 3.5Gb free during about a hour ^^' (finger crossed).
Once dataset was destroy, lot of RAM was free'ed .
Rebooted the server and now it boots normally without wait on import.
Thanks all for the help.

Cheers,


2014/1/16 Freddie Cash <fjwcash at gmail.com>:
> On Thu, Jan 16, 2014 at 11:18 AM, Gomes do Vale Victor <ulysse31 at gmail.com>
> wrote:
>>
>>
>> Le 16 janv. 2014 à 19:14, Stefan Esser <se at freebsd.org> a écrit :
>>
>> > Am 16.01.2014 08:00, schrieb Gomes do Vale Victor:
>> >>> Thanks a lot for this info ! I have read about the "-T" option
>> >>> on import with tgx but it was with ZFS on Linux ... Don't knew it
>> >>> is available on newer implementation under FreeBSD. Will so wait
>> >>> that it ends correctly and will think on upgrading on the system
>> >>> (the rootfs is ZFS also ...)
>> >
>> > Just for the record, since your reply seems to imply that the -T
>> > option is only available on Linux:
>> >
>> > The -T option of zpool import has been present in FreeBSD for years,
>> > but is undocumented (same as in Solaris/OpenIndiana). It has been
>> > mentioned in some ZFS recovery guides (most written for Solaris) and
>> > it actually works quite well (I used it to recover an inconsistent pool
>> > and helped somebody else who has lost access to his ZFS file-systems).
>> >
>> > Regards, STefan
>>
>> Sorry if you understood that. It was not what I meant. I wanted to say
>> that I only found one thread talking about that option (the import with the
>> -T option) and that thread was about ZFS on Linux, and since I ain't found
>> no mention of it on the actual man of my FreeBSD version I have here, I
>> tough it was only available on newer ZFS versions (like v5000) under
>> FreeBSD.
>> Thanks for the info, so do you think I could use this method to recover my
>> pool that is on ZFS v28 ?
>> Also, the import is now running without crash for 8 days now, and still
>> does not have finished, and I do not see any revelant activity on disks, nor
>> any load under CTRL+T on the zpool process (sometimes goes to 0.16/0.08 but
>> quickly returns to 0.00 and stays there a while) do you think I should
>> interrupt it, reboot and restart again ? Or directly test with the -T option
>> ?
>
>
> I'd try a reboot to restart the process.  Let it run for a day.  If you
> still aren't seeing any disk activity, then try the -T and/or the -F import
> options.
>
> --
> Freddie Cash
> fjwcash at gmail.com



-- 
Ulysse31


More information about the freebsd-fs mailing list