FatFileSystem (unnecessarily) requires a minimum allocation of 64K

[NeilMacMullen]

For testing purposes, it's useful to be able to create RAM drives on smaller devices where the amount of available RAM is limited. The following code on a Nordic RF52 will show an error (-5) on the format operation. Interestingly if BLOCKS is increased to 128, the format and subsequent file operations will complete although presumably once the filesystem grows too large the system will fail unpredictably.

Target: UBLOX_EVK_NINA_B1
Toolchain: GCC_ARM
Mbed: 5.4.5

#include "mbed.h"
#include "FATFileSystem.h"
#include "HeapBlockDevice.h"

Serial pc(USBTX, USBRX);
//RF52 doesn't have 64K of RAM so try using a more sensible size....
#define BLOCKS 32
#define BLOCKSIZE 512
HeapBlockDevice bd(BLOCKS * BLOCKSIZE, BLOCKSIZE);
FATFileSystem fs("fs");

int main()
{
  pc.format(8, Serial::None, 1);
  pc.set_flow_control(Serial::RTSCTS);
  pc.baud(115200);
  int error = FATFileSystem::format(&bd);
  pc.printf("RAMdisk %d bytes, Error code from format %d\r\n", (BLOCKS*BLOCKSIZE),error);
  while (true);
}

[theotherjimmy]

Hi @NeilMacMullen,

Thanks for reporting this issue. @geky are we hitting the smallest size allowable limit of FAT here?

P.S. I updated your markdown to show the code better

[NeilMacMullen]

Thanks @theotherjimmy Just to be clear, I'm sure there is an internal lower limit of 64K but what I'm really questioning is whether this really needs to be enforced or is desirable. Clearly the filesystem can operate with much lower amounts of actual RAM if you lie to the format operation (HeapBlockDevice uses demand-allocation). If the 64K assumption is too baked into the current implementation then it would be desirable to offer a simple RamFileSystem as an alternative. I'm mainly interested in testing my application semantics in terms of file operations and out-of-space errors so the fact it's FAT is less interesting. I also suspect that other people would find a small RAM-disk a good model for structured data that doesn't need to persist through a reset.

[geky]

We did recently put up a pr that reduces the minimum storage needed for the FATfs to 32KB by removing the MBR (related pr #3936). Unfortunately I don't think we can push it much smaller than that.

The FAT filesystem needs to be compatible with PCs, so it's design is a bit inflexible. Here's the standard layout of the FAT filesystem at its smallest (FAT12) for anyone curious. The layout needs at least 64 blocks (32KB) to really do anything useful:

A RamFileSystem would be a great idea, but we don't have plans to develop the feature at the moment. We wouldn't turn down an implementation if someone provided one though.

[NeilMacMullen]

Thanks @geky. I can see that trying to enforce a 'top down' size limit would be tricky. I guess that if the HeadBlockDevice returns a failure at any point the FFS is likely to just be marked as corrupted so I can't practically enforce a 'bottoms up' limit ?

A RamFileSystem would be a great idea

I assume such a thing would have to inherit from FileSystem? I'm a little unclear how mount is supposed to work though - the Fat implementation is quite 'deep' and uses a lot of FATFS specific calls. If I were to write my own FileSystem, how to I get it mounted so that the standard C file I/O calls work?

[geky]

Sorry for the late response,

Unfortunately the FATFileSystem doesn't understand corrupt blocks, so running out of heap would probably just crash the filesystem.

To add a RamFileSystem, you will need to inherit from FileSystem and implement all of the virtual functions that return ENOSYS:
https://github.com/ARMmbed/mbed-os/blob/master/features/filesystem/FileSystem.cpp

The trick to binding the filesystem into the C library is to call the FileSystem constructor with the name of the mount point. The inheritance of the FileSystem class should take care of the rest.

You will probably want something like this in your class:

class RAMFileSystem : public FileSystem {
public:
    RAMFileSystem(const char *name = NULL)
        : FileSystem(name) {
    }

    // ... other filesystem functions ... 
}

[NeilMacMullen]

Thanks @geky - I hadn't realised mounting would be so simple :) A bit busy right now but if I come up with something I'll submit it here.