metaslab_load/spa_load messages when multiple pools

Description

Hello,

All steps are done through the web GUI.

On top of my boot-pool, which is a pool of its own:

I create a new pool with two drives (WD80EFBX+ST8000VN004) as mirror:

zpool status says the pool is ok
I reboot, everything is ok.

I create another pool with one drive (SSD370S) as stripe:

zpool status says both pools are ok
I reboot, I have errors for both pools

In the log, events are at 01:05:20 (line 1230-1296).

Using the same three drives, I do three pools of one stripe drive: same issue (log 1022-1135)

Beyond boot-pool, the new pools are empty.

If I go back to one pool, the next startup won't show error on the pool that is left.

I observed this problem in 12.0 U2.1, and I was able to reproduce it in 11.3 U5.

In 11.3 U5, the messages differ, but they happen at the same place in the startup process.

I then imported (but not upgraded) a pool that is a single mirror that is currently running in Nas4Free and that pool also shows the same issues.

The FreeNAS 11.3 U5/TrueNAS 12.0 U2.1 installations are new, drives are new, and pools are new. They are mounted in an HP Microserver Gen 8.

I originally reported my problem in this thread:

https://www.truenas.com/community/threads/startup-give-pool-errors-at-import-when-more-than-one-pool-metaslab_load-spa_load.92103/

Problem/Justification

None

Impact

None

SmartDraw Connector

Katalon Manual Tests (BETA)

Activity

Show:

Seldo 
March 30, 2021 at 10:51 PM

Thanks for your answers.

I’m not sure I understand your answer to question 2.

 

Question was:

2. Does it mean that I do not have to worry until zpool status reports issues (such as DEGRADED)?

You answered:
2. you do, zpool status is still relevant

Should I understand it as I only have to look at these statements (metaslab, sla) if zpool reports my pool as missing or having issues? 

I guess I’d first notice a failed import because I wouldn’t be able to work with my pool. Then I’d check spool, then check these statements in console.log

William Gryzbowski 
March 30, 2021 at 8:18 PM

  1. probably a timing issue between setting up dtrace and how long it takes to import the pools

  2. you do, zpool status is still relevant

  3. Different zfs version and changes on how we perform the import of pools at boot time

  4. they can be ignored completely unless the import fails

  5. its not saved anywhere else

Seldo 
March 30, 2021 at 7:28 PM

: thanks for lifting my worries.

A few questions as a follow up to help me understand.

  1. Why didn't I always see them? After destroying one pool, the next reboot didn't show these messages. (post 5 shows no message but post 6, after a reboot, shows the message).

  2. Does it mean that I do not have to worry until zpool status reports issues (such as DEGRADED)?

  3. Why do the messages differ between TrueNAS 11.3 U5 and TrueNAS 12.0 U2.1? Is it because of different ZFS versions?

  4. So it means these message be ignored unless they include the FAIL string? Is there already some automation that checks for that after the system booted?

  5. The messages displayed in console.log truncated (it stops at 'max size error', but the code shows that there is a couple more statements: https://github.com/openzfs/zfs/blob/master/module/zfs/metaslab.c#L2433

  •  

    • Is there a place where I can read them in full?

William Gryzbowski 
March 30, 2021 at 1:52 PM

This is not an issue.

 

Its simply dtrace message to show report of stage of an importing pool.

Seldo 
March 29, 2021 at 6:42 PM

I uploaded another debug log: 

I realized the pool in the first one was having an iocage in it (most likely a mistake from my side?)

The latest pool, ARCHIVE_POOL_3 is empty.

Behaves as Intended

Details

Assignee

Reporter

Labels

Components

Fix versions

Priority

More fields

Katalon Platform

Created March 28, 2021 at 8:40 PM
Updated July 1, 2022 at 5:12 PM
Resolved March 30, 2021 at 1:52 PM