ZS 1.1 - fw 1.2.0 - image "not contiguous", "slow transfer" in logs, and device errors from OS

[vom513]

I assume the two are connected...

I'm trying to use this on a Sun Sparcstation 20. Initial install of NetBSD 9.3 goes fine. Works fine for a few days / week. After a while I get very nasty SCSI errors from the OS and it panics / won't boot. I take my latest backup of the image, put it on there in it's place, and I'm back in business. It seems like some combination of hardware / zuluscsi / OS are "eating" the image ? The SD card itself doesn't throw errors, the ExFAT FS seems fine. I've tried two different brands of (micro) SD cards so far. Same issue on both.

No idea if the "not contiguous" and messages about slow transfer are related to this.

I made my "blank" images from dd if=/dev/zero, it's exact size is 9056690176. I don't get errors in the ZS log about geometry so I think I'm okay there ? My ini settings:

[SCSI]
Debug = 1
SectorsPerTrack = 248
HeadsPerCylinder = 19

A snip of the log. No other "bad errors" that I can see. Unfortunately I don't have a log of when the image seems to kill itself and the OS panics. I'll leave Debug = 1 to capture this the next time it happens.

[368ms] Finding HDD images in directory /:
[368ms] -- Opening /HD30_512-ss20-nbsd9.3-20230209.hda for id:3 lun:0
[369ms] ---- WARNING: file /HD30_512-ss20-nbsd9.3-20230209.hda is not contiguous. This will increase read latency.
[370ms] ---- Read prefetch enabled: 8192 bytes
[382ms] SCSI ID:3 BlockSize:512 Type:0 Quirks:0 ImageSize:8844424kB
[883ms] SCSI PHY operating mode: GREENPAK_DMA
[883ms] Initialization complete!

[PetteriAimonen]

The file contiguousness shouldn't affect anything except random access speed. It just means that when computer accesses a sector outside the current ExFAT extent, it needs to look again in allocation tables to find the data.

Usually reformatting the SD card and then copying the file to it makes it contiguous.
A notable exception is if you are using the old fuse-exfat driver on Linux, because it has a bug in allocation logic.
Because Linux kernel nowadays has built-in exfat support, that driver is no longer needed.

And yes, 9056690176 is evenly divisible by 248×19×512, so that is fine also.

A log from the corruption would be interesting, as would be a comparison of the good vs. bad image files.

Is there anything special that you are doing at the time of the problem, or does it just happen randomly?

Which ZuluSCSI variant are you using, and which firmware version?

[vom513]

It's a ZS 1.1. It was on 1.0.8 I think - it's now on 1.2.0.

It just happened randomly on a bootup (NetBSD 9.3).

One thing I'm thinking - is that I also have another card where I installed Solaris 8. I had to set some geometry in the ini to make Solaris happy. I have/had:

SectorsPerTrack = 248
HeadsPerCylinder = 19

When I did NetBSD - I carried this over. So same "blank" HD image and same ini. I feel like that isn't necessary on NetBSD and might have tripped it up.

And yes I have debug on now - and if it happens again I will certainly capture the log.

[PetteriAimonen]

Since 1.0.8 there has been #126 rework that fixed write corruption on some devices that weren't prepared for any pauses during a write operation. In issue #90 that was quite random and some people got the problem and others didn't.

Geometry is indeed a problem sometimes, as while SCSI command set doesn't care about it, some operating systems try to optimize their filesystem layout based on it. The surest way is if you find information online on what kind of drive the system was originally used with, and imitate the geometry. But in practice, geometry problems usually show up as error messages immediately on boot, installation or when running diagnostics tools, not as random corruption.

[aperezbios]

@vom513 any updates here? It's been over a month since your last reply.

[vom513]

Sorry for the delay...

Since posting - I made the following changes to my setup (this is a Sparcstation 20).

• Removed the SectorsPerTrack + HeadsPerCylinder from the config. I simply made a nice even 8gb blank file for my image. NetBSD creates it's own "geometry" and seems fine. Haven't tried Solaris again - I have a feeling I will need to make a disk of a certain geometry for that though.
• It seems like if I format (exFAT) my SD card on macOS - I get more issues (especially non-contiguous warnings). I switched to formatting on Linux with the "-f" flag to force a full format. I seem to get much better behavior after this.
• I'm keeping up with the stable firmware releases. Always running the most recent stable.
• I also keep debug on for ID 3 (boot HDD).

Thanks for all your help on this. We can close this discussion/issue.

[MeTalOneOEight]

Maybe consider formatting them with the official SD Association formatter?
See
greiman/SdFat#406 (comment)