The latency issue crops up in combination with chattyness and multiple devices in a collision domain.

It just gets greatly magnified over WAN links.

The WAN part of the quote is not the impirtant part anyway. The 64kb max blocksize is.

For most small files of the dos era, this means a single message can contain the entire file, and local caching works just peachy.

The 'do not do this ever!' Admonition, is

'Do not try to mount an .iso or other large disk image directly from an smb1.0 share; the protocol is designed for small files, has problems with cache concurrency without oplocks, saturates the link with protocol control messages and small nibbled datagrams on reads or writes to large files, and hangs up if a transaction 'takes too long', all of which contributes to timeouts and orphaning of the file handle.

DOS block device drivers are not equipped to recover from orphaned/stale handles, and will just give read errors once that happens until you unmount, then remount the image. from their perspective, you drive is having a general read error/damaged.

If you want to work with image files over the lan, you should use a protocol that is better suited.'

elszgensa wrote on 2024-03-29, 09:53:

I'd like to point out that OP didn't specify any protocol/fs, so things like NFS or Novell Netware are still on the table. Though I have little experience with both, at least within DOS, but maybe one of you guys has an idea how appropriate they'd be here?

The few NFS solutions I've tried have similar memory footprints to the SMB client so not very practical.

The NetWare client for DOS is a fair bit more lightweight. With emm386 loaded it only needs around 4K of conventional or upper memory (will load high automatically if it can).