smb.d core dump repeatedly, 13U4, 2 different systems (same files)

[jenksdrummer]

2 systems, same core dumps. I guess same admin being a potential factor but I don't sense I am doing anything odd here.

Supermicro 11th gen; Silver 4210 192GB ECC RAM, using integrated 3008 SAS controller

Created pool
- 6x Mirror VDEV WD Gold 10TB
- 1x Mirror Special VDEV Samsung 970 Evo Plus 1TB NVMe
- Single Cache VDEV Samsung 970 Evo Plus 1TB NVMe
Set SHA512
Set 1M Stripe Size (mostly archival data)
Set Small IO 16K
Compression LSTD
Create sub dataset "shares"
- Create sub datasets for each share
SMB enabled, SMB min version 3 set

Data copied via robocopy from windows server 2019. This after I had copied around 6TB of data, and was running another pull of robocopy to make sure there wasn't any lingering/changed files before decom of the WS2019 box.

Other system is a Supermicro 5028D; Xeon-D something, 128GB ECC, Intel/on-board SATA
Created pool
- 1x Z2 VDEV 6x WD Red SATA SSD 4TB
- 2x Mirror Special VDEV Samsung 970 Evo Plus 1TB NVMe
- Single Cache VDEV Samsung 970 Evo Plus 1TB NVMe
Set SHA512
Set 1M Stripe Size
Not set small IO as I was...
Deduplication was on
Compression was set as LZ4

This 2nd box became the WS2019 box, no issues while running WS2019. Used Supermicro/LSI 3108 while WS2019 but removed while TrueNAS. System is again back to TrueNAS and about to start copying over data but want to see if I can find out what the issue is with SMB.D

 

[anodos]

2 systems, same core dumps. I guess same admin being a potential factor but I don't sense I am doing anything odd here.

Supermicro 11th gen; Silver 4210 192GB ECC RAM, using integrated 3008 SAS controller

Created pool
- 6x Mirror VDEV WD Gold 10TB
- 1x Mirror Special VDEV Samsung 970 Evo Plus 1TB NVMe
- Single Cache VDEV Samsung 970 Evo Plus 1TB NVMe
Set SHA512
Set 1M Stripe Size (mostly archival data)
Set Small IO 16K
Compression LSTD
Create sub dataset "shares"
- Create sub datasets for each share
SMB enabled, SMB min version 3 set

Data copied via robocopy from windows server 2019. This after I had copied around 6TB of data, and was running another pull of robocopy to make sure there wasn't any lingering/changed files before decom of the WS2019 box.

Other system is a Supermicro 5028D; Xeon-D something, 128GB ECC, Intel/on-board SATA
Created pool
- 1x Z2 VDEV 6x WD Red SATA SSD 4TB
- 2x Mirror Special VDEV Samsung 970 Evo Plus 1TB NVMe
- Single Cache VDEV Samsung 970 Evo Plus 1TB NVMe
Set SHA512
Set 1M Stripe Size
Not set small IO as I was...
Deduplication was on
Compression was set as LZ4

This 2nd box became the WS2019 box, no issues while running WS2019. Used Supermicro/LSI 3108 while WS2019 but removed while TrueNAS. System is again back to TrueNAS and about to start copying over data but want to see if I can find out what the issue is with SMB.D

Can you PM me a debug and the corefile. This is most likely an issue already fixed for U5.

 

[anodos]

This particular issue (SMB_ASSERT() due to client calling FSCTL on an alternate data stream) is already fixed for U5.

 

[jenksdrummer]

Thank you for the analysis! :)