I'm not sure what you mean by "so you can't hot -plug/-unplug it". If I use it in Windows or Linux, I can eject it like I can any standard non-SSD USB stick. I'm also not sure what issues you've been having with booting from them. I've occasionally used these things to boot Linux LiveCDs without issue. Might be a compatibility issue with your BIOS specifically? I've seen some messed up BIOS's that simply defy all expectation in how they work. Then again, I primarily only use these things to transfer data between machines (primarily games), so all I really care about is their performance.
I also preferably call them USB sticks instead of SSDs, since afaik TRIM isn't supported on them, which makes them significantly worse than any proper SSD.
>I'm not sure what you mean by "so you can't hot -plug/-unplug it"
Only UMS (universal mass storage) devices can be hot-plugged-unplugged without ejecting, while UAS (USB Attached SCSI) devices cannot and need to be ejected beforehand since the OS treats them like an internal drive instead of a removable one.
> I'm also not sure what issues you've been having with booting from them. Might be a compatibility issue with your BIOS specifically?
NO, like I explained before, it's not the BIOS, it's the lack of 512 block support on the USB SSD controller which is very uncommon on traditional USB thumb drives but is needed for UEFI/BIOS boot. USB tools (like Rufus in default mode) create 512B-aligned images, but if the drive is 4Kn-only, GRUB or kernel can't read the filesystem.
The lack of 512 support seems to be a issue on the newer lower-cost USB SSDs which are designed to just do NTFS file transfers on the go and not host an OS for boot.
>I've occasionally used these things to boot Linux LiveCDs without issue.
Because yours have 512 native support like most USB drives. But No 512 support, no OS boot. Simple.
MSC and UAS are SCSI transport protocols and have nothing to do with a device being identified as a removable device, which happens at the higher command set layer.
Specifically, flash drives typically set the removable media bit in their response to the SCSI INQUIRY command, which makes the OS believe they contain a medium that can be removed and replaced, like a floppy, "superfloppy" (Zip, LS-120, SyQuest, etc.), or optical drive.
This is why Windows, in particular, exhibits curious behavior when dealing with flash drives:
It assigns a drive letter to a flash drive even if it contains no partitions — MS-DOS and Windows floppies, "superfloppies", and optical media were traditionally unpartitioned.
It allows you to eject the "medium" from the drive — at which point it typically becomes unusable, like a floppy drive with no disk inserted, unless you have a way to send a START STOP UNIT command with the load eject bit set (e.g., the sg3_utils[1] sg_start command), which directs a removable drive to attempt to load the inserted medium (a tray-loading CD-ROM drive with an open tray will retract the tray and spin up the disc, if present; a tape drive capable of injecting an ejected tape will do so; a flash drive with nothing to physically eject will once again present as a drive with medium present).
Most usefully, it causes Windows to default to more conservative caching behavior that makes surprise removal safer (this can be changed for specific devices via Properties in Device Manager), and therefore doesn't display a warning when the drive is physically disconnected without requesting disconnection from the OS and waiting for the "safe to remove" notification.
> Only UMS (universal mass storage) devices can be hot-plugged-unplugged without ejecting, while UAS (USB Attached SCSI) devices cannot and need to be ejected beforehand since the OS treats them like an internal drive instead of a removable one.
"need" according to what? If this is about writeback caching, you can turn that off manually for the disk. And isn't windows the only OS that disables it by default for removable disks?
> USB tools (like Rufus in default mode) create 512B-aligned images, but if the drive is 4Kn-only, GRUB or kernel can't read the filesystem.
> The lack of 512 support seems to be a issue on the newer lower-cost USB SSDs which are designed to just do NTFS file transfers on the go and not host an OS for boot.
Sounds like a rufus issue to me, rather than a hardware problem. It's been standard practice to align to larger values for a long time for performance reasons.
>Sounds like a rufus issue to me, rather than a hardware problem. It's been standard practice to align to larger values for a long time for performance reasons.
Which EFIs and bootloaders support that though? Everything I tried failed.
I also preferably call them USB sticks instead of SSDs, since afaik TRIM isn't supported on them, which makes them significantly worse than any proper SSD.