RIOT Filesystem Hierarchy Standard

Development
1

We now have filesystem auto-mounting in RIOT, the question is what mount points should be used by default.

In #17656 I proposed

Variant A

  • SD cards are mounted to /sd
  • soldered Flash devices are mounted to /nvm

If there is more than a single flash device / SD card, /sd0, /sd1 etc could be used.

The drawback here is that there can’t be a generic application that works both on boards with an SD card and with SPI flash as those use different mount points.

So @kfessel suggested

Variant B

  • Create mountpoints strictly alphabetically, first device is /a, second device is /b etc.

A drawback here is that the application now can’t know if a device is an SD card (and thus removable) or not. Maybe this is a minor issue.

In the very first iteration I also had

Variant C

  • Only allow for a single default mount per board and mount it to /.

Every additional device would need a board-specific mount point.

What do you think makes the most sense? Another idea is to provide bind mounts in VFS so devices could be mounted under different names at the same time.

2

I like variant a), but always using a numeric postfix (e.g. /sd0 even when there is only a single sd card). Distinguishing between when there is only one or more than one instances of a specific storage item sounds like extra complexity without real benefit to me.

3

+1

And at some point, provide functions to get some UUID, LABEL or similar from the mounted storages.

4

+1 for variant A, especially with maribu’s note.

Contrasting it to B, I’d expect that applications (through their usage patterns, eg. expecting fast access or expecting almost infinite storage) will have a typical mountpoint class to use, and while switching between them should be possible (to the extent supported by the hardware and atomicity requirements), that might be better left to the user / application designer who is then also aware of this not being used “on its home turf”.

When describing this, it should be pointed out that this is a default that applications can override, and modules need to be prepared to take custom paths.

5

Also +1 for A with the @maribu amendment.

Does it also make sense to have a configurable directory where to auto-mount? So something like /media or just /m for brevity (but keep / by default for now). Not that I see it realistically, but I want to prevent that we run into a cluttered root at some point.

6

The mount point is currently configured by the board, so this all is only a convention.

7 
#ifndef CONFIG_VFS_AUTO_MOUNT_POINT
#define CONFIG_VFS_AUTO_MOUNT_POINT "/"
#endif

/* ... */

VFS_AUTO_MOUNT(littlefs2, VFS_MTD(same54_nor_dev),
               CONFIG_VFS_AUTO_MOUNT_POINT "nvm", 0);

and even the convention becomes configurable (or rather is steered into the right direction via available config parameters) ;-).

But in general, did not want to derail this conversation, mostly just hint that this could be an additional option.

8

Just to clear things up:

  • I think the defaut device should not be / (not Var-C)
  • But should have a common name (not /sd for one type and /nvm for another (sd-cards are also no volatile memory so vm would apply to both))
  • /data would be nice or /d to keep the string short. with my suggestion i did not think about extra devices than the one default (so no /e, /f).
  • The one default device should be choosen either by the Board
    • (e.g. there is nvm on board → nvm is i good default since it is allways there;
    • there is no nvm but a sd-slot sd is a good default -there are mutiple nvm but some are only supplied in some variants → use the one that is allways there

for USEMODULE = vfs_mount_default i would expect a place i know to be able to write to without knowing what board i choose

if there are multiple storrages they can be mounted using the fstab-alike

9

I feel like shortening “/data” and “/media” to “/d” and “/m” is not worth the bytes. so much user visibility and room for confusion. let’s rather take 16 bytes from the default stack size…

10

To take this a step further, we could also have a

#ifndef CONFIG_VFS_AUTO_MOUNT_DATA_DIR
#define CONFIG_VFS_AUTO_MOUNT_DATA_DIR "/nvm"
#endif

that could then be overwritten in board.h.

11

Then let me even escalate further :wink:

#ifndef CONFIG_VFS_AUTO_MOUNT_ROOT
#define CONFIG_VFS_AUTO_MOUNT_ROOT "/"
#endif

#ifndef CONFIG_VFS_AUTO_MOUNT_DATA_DIR
#define CONFIG_VFS_AUTO_MOUNT_DATA_DIR CONFIG_VFS_AUTO_MOUNT_ROOT "nvm"
#endif
12

How about D:/ or M:/ then?

image

13

How about D:/ or M:/ then?

too much potential for confusing D: the media root vs D:, the subdir in the current working dir or D the server whose port is unknown.

i think a not configurable convention is better: if someone does not like that he can easily just not use vfs_default and go for that fstab-alike XFA

14

why convention over configuration: I can find:

  • my X11 config in /etc
  • my logs and system data are in /var
  • my personal data is in /home

…

  • none of these is in /nvme1p1 or /hda1 or /sda1

if i want to add a device i add that info to fstab, but when i install nearly any linux the above holds true, even if my root did not get mounted and i find myself in an initrd / the above hold true

15

It might be good to say that if there is some additional/extraneous to required needs, that it get mounted into something like “/var” (maybe /v), where one could direct debugging.

16

Folks, this is all not about setting a structure in stone, and certainly not about narrowing what an application can do, or about specifying where applications put their data.

The convention is for the benefit of the user, who should be able to make heads and tails of what they get when running the filesystem example, and for the benefit of board-generic demo applications and tutorials where you write “get a RIOT board with an SD card” and the example works, and not “and then look up where your board happens to mount the storage, and adjust the CFLAGS accordingly”.

Where to place configuration, whether file systems even make sense for configuration, and where data of individual users goes is certainly interesting when comparing all this to POSIX, but AIU not the scope of this thread.

An actual application will, until much further ahead, just pick the mount points for the MTDs which it needs anyway.