Umsdos runs piggy back on top of the MsDOS fs of linux. Umsdos could be reusable to play the same game on top of another fs (hpfs) but there is different small quirk msdos specific in it. And off course it calls few msdos fs function directly. We will present some specs of the msdos fs here. It is not that much related to the design of Umsdos but it might be one day.
[linux/fs/msdos/buffer.c,20]
#Specification: msdos / strategy / special device / dummy blocks
Many special device (Scsi optical disk for one) use larger hardware sector size. This allows for higher capacity.
Most of the time, the MsDOS file system that sit on this device is totally unaligned. It use logically 512 bytes sector size, with logical sector starting in the middle of a hardware block. The bad news is that a hardware sector may hold data own by two different files. This means that the hardware sector must be read, patch and written allmost all the time.
Needless to say that it kills write performance on all OS.
Internally the linux msdos fs is using 512 bytes logical sector. When accessing such a device, we allocate dummy buffer cache blocks, that we stuff with the information of a real one (1k large).
This strategy is used to hide this difference to the core of the msdos fs. The slowdown is not hidden though!
[linux/fs/msdos/file.c,60]
#Specification: msdos / special devices / mmap
Mmapping does work because a special mmap is provide in that case. Note that it is much less efficient than the generic_mmap normally used since it allocate extra buffer. generic_mmap is used for normal device (512 bytes hardware sectors).
[linux/fs/msdos/file.c,79]
#Specification: msdos / special devices / swap file
Swap file can't work on special devices with a large sector size (1024 bytes hard sector). Those devices have a weird MsDOS filesystem layout. Generally a single hardware sector may contain 2 unrelated logical sector. This mean that there is no easy way to do a mapping between disk sector of a file and virtual memory. So swap file is difficult (not available right now) on those devices. Off course, Ext2 does not have this problem.
[linux/fs/msdos/buffer.c,68]
#Specification: msdos / special device / writing
A write is always preceded by a read of the complete block (large hardware sector size). This defeat write performance. There is a possibility to optimize this when writing large chunk by making sure we are filling large block. Volunter ?