USB memory size limitations

What are the limitations of memory size when using USB memory sticks?

I would love to see an overall summary, including:
- various flavours of RISC OS (eg v4.02, v4.39, v6.20, v5.22 & v5.23).
- various machines (eg RISC PC, Iyonix & other 32bit machines, VRPC and RPCEmu).
- various disc formats (eg ADFS/Filecode, FAT12/16/32).
- when is Fat32FS useful (or required) for discs over 2GB?
- can sticks be partitioned? (eg using Windows).
- what are the performance considerations?

Is there such a summary anywhere?
If not, please can anyone add any clues to this thread?

What are the limitations of memory size when using USB memory sticks.

Same as for any hard disc

when is Fat32FS useful (or required) for discs over 2GB?

Its useful for Fat32 discs > 2GB old OS, 4GB new OS

can sticks be partitioned? (eg using Windows).

No they have exactly the same limitations as any hard disc.

what are the performance considerations?

slow compared to sata / pata

Interesting question, a detailed answer would probably take a few A4 pages.

Machines with RISC OS 5 (i.e. Castle USB stack) and real hardware USB: Filecore 256GB, FAT via DOSFS 2GB (don’t know if anyone has tested 4GB with Sprow’s filecore updates), FAT via Fat32FS 1TB.

Emulators: directly accessing memory sticks is not possible, must be done via mounting the host’s drive. Only possible with V-RPC AFAIK, since RPCEmu only has one hardcoded HostFS drive. I am sure that, on Linux, something clever with hard-/softlinks can be done to circumvent this.

I would always prefer Fat32FS compared to DOSFS.

Partitioning won’t get you anywhere at the moment, RISC OS sees only the first partition. Hmmm. On the other hand, Fat32FS could in theory handle multiple partitions…

I would always prefer Fat32FS compared to DOSFS.

Don’t use DOSFS for devices greater than 2GiB.

Later versions are capable; the problem is older versions will happily mount and display the content of devices larger than it can handle; just expect the filesystem to be irreparably trashed the moment the (earlier) DOSFS touches it.

via Fat32FS 2TB, but only if accessing drives via SCSIfs.
If using drives on anything else then is restricted to 256GiB.

That’s because the SectorDiscOp command can only address this much. SectorDiscOp64 doesn’t work. SCSIFS supports a partition SWI which allows Fat32fs to access the drive in 256GiB chunks.

If using drives on anything else then is restricted to 256GiB.
*4 partitions or for the 4 partitions?

The good point is that on a 1 TB disk, you can make a 128 GB ADFS volume, then a 896 GB FAT32 volume, and access both (or up to 4 smaller FAT32 partitions). Perhaps that FAT32Formatter could detect the size of the ADFS volume, to avoid any overlap?

It would be interesting too to get a tweaked version of Fat32FS for RISC OS, even if not compatible any more with FAT32 :) Just for speed and space. For example it could become a bit faster, and manage more than 4 primary partitions (and so use smaller clusters size).

Anyway, I love this tool.

*4 partitions or for the 4 partitions?

You can only access the 1st 256GiB of the drive when it’s not on the scsifs, irrespective of where the partitions are.
(You can only use a 29 bit sector address as the upper three bits are the drive number)

and manage more than 4 primary partitions

Already does – although only one at a time.

although only one at a time.

I did not see this limit. Not a big problem anyway for a non system disc…

I know very little about filing systems for USB sticks, but perhaps it’s interesting to know that I ordered two 256Gb USB 3.0 PNY sticks from Conrad (Germany), for around £80 each. Not only they work out of the box on my ARMiniX, but they even are a great lot faster than the USB 2 sticks that I already had, while USB 3 is not yet supported by RISC OS!