test: Avoid scsi-debug drives for partitions

[mvollmer]

Something is causing partitions on drives backed by scsi-debug to be
permanently busy with kernel 6.9.0-64 in Testing Farm runs. Let's just
avoid them.

[mvollmer]

Oh, no, targetd seems to be affected as well. Is it all of SCSI?

[martinpitt]

@mvollmer For some history: I chose scsi_debug over loop where possible (i.e. just one device) as loop devices are very "special" in the kernel -- wildly different code paths, they don't support partitions very well (you need userspace hacks like kpartx), they can't be hot-(un)plugged (sysfs /remove), often produce different uevents, and so on. I. e. I think scsi_debug is more representative of "real" devices.

However, I realize that all of this is way "below" the API level that Cockpit is concerned about. I guess it's a trade-off between "test the whole stack" and "only test the upper levels", i. e. how much "full stack" gating we want to do. However, I'll defer to your better storage stack judgement for if we should actually land this PR.

I have a feeling this is an actual kernel (or possibly) udisks regression. I'll try to at least reproduce it with local tmt or tmt reserve to get some information. I'll collect info in #20520.

[mvollmer]

I have a feeling this is an actual kernel (or possibly) udisks regression. I'll try to at least reproduce it with local tmt or tmt reserve to get some information. I'll collect info in #20520.

Yes, thanks for doing the right thing!

As it turns out, the TF rawhide instanced do indeed break /dev/sda in general (via bogus symlinks in /dev, see #20520), and avoiding scsi_debug is not necessary.

[mvollmer]

I. e. I think scsi_debug is more representative of "real" devices.

However, scsi_debug doesn't really promise to store your data, and we had to use "target" devices for some tests. Would you be interested in using more of "add_targetd_loopback_disk" and less of "add_ram_disk"? (With a nicer name for add_targetd_loopback_device, of course.)

"Target" devices are real scsi drives and can also be removed. They are not as portable however, unfortunately, and that might have already killed this idea...

[martinpitt]

@mvollmer I'm fine with that, yes. I'd also be happy with "hiding" loop devices behind mdraid or LVM, or anything else.

[martinpitt]

However, "target" devices are iSCSI, no? I don't know how "special" they look from userspace, i.e. if they are more or less special than loop.