sommerfeld good stuff:)

Woodstock: thanks for swtpm

Just curious, has anyone tried illumos (or related) on a 45 drives system?

Didn't the old Thumper ship with that many? I'll have to check...

45drives is a company in Canada that ships thumper-like boxes but with their own version on the theme.

Yeah...

the thumper had 48 drives, IIRC.

I'm talking about the product from the company called 45drives.

they ship with Linux.

Oh... sorry, was finding the wikipedia link while you were clearing things up. Sorry.

np

Up until about ... maybe 8 months ago ... I was running FBSD on thumpers. They were good to the end.

They're selling turnkey boxes (they even have a wannabe-Oxide box, it looks like). Would be interesting to try that.

Yeah. It would be nice to give silicon mechanics some competition for our next fileserver.

but I don't want to run Linux on my fileservers, I want some heterogeneity in my environment.

They look like a Racktop competitor as well (Racktop uses their own illumos, and you see their folks on illumos community places).

Hmm. I must be finding the wrong company. I'm seeing lots of noise about a security system but nothing about file servers.

Their initial customer base was govt. so that makes sense (racktopsystems.com). Sorry for not catching that.

please stop apologizing :)

Just means I don't need to consider them for our fileserver needs. :)

[illumos-gate] 16838 libefi: efi_auto_sense should use sector size -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16833 smbsrv: array subscript 12 is above array bounds -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16844 pci_prd: array subscript 0 is outside array bounds -- Toomas Soome <tsoome⊙mc>

hrm... i'm guessing truss is probably the best (though not authortative) source of ioctl values, isn't it?

i don't think it'd rise to needing an IPD, but all major I/O transports (SATA, SCSI, NVMe) support the notion of security protocol I/O

basically you can send and receive chunks of data for some security protocol (which I realize is very generic)

I can't tell what you're asking, about ioctl values

e.g. TCG has protocols for things like self encrypting drives

well mostly about trying to pick a set of values that aren't going to collide

truss does not have them all:)

so for whatever protocol you're trying to use (this -- at least in theory -- is more than disks)

truss is probably a convenient view of many things, but I don't think it's complete

TCG, IEEE1667 (I think that's the one), there's even a spec for doing IKEV2 to encrypt your I/O PDUs

yeah, but in terms of 'best guess'

I'm not sure we have a convenient symbol to search for either

mostly what people do is take a (set of) characters into the high bits, and use the low bits for their codes

could just create another couple of DKIOC values, but since it could also be used with say tape drives (for those using them), using a DKIOC value seems wrong..

yeah, but still want to at least try to make sure they don't conflict

so mdd(4d) would maybe do `#define MDD_IOC ('m' << 24) | ('d' << 16) | ('d' << 8)` and `#define MDD_IOC_RINGBELL (MDD_IOC | 1)`

this is not advocacy, I just think the historical way things are, as opposed to _IOC() macros and such

e.g. if I picked 'S' << 24 | 'E' << 16 | 'C' << 8 and did say SECURE_IN (SEC_IOC | 0) and SECURE_OUT (SEC_IOC | 1)... my luck it'll end up stomping on something semi-obscure that no one notices for a while :)

I think the chances of collisions on a given device node are probably pretty tiny