Drops N’ Roses : Drop File System

Hello !

It is time for me to explain you how our drop file system (Deluxe Rather OPerational File System = DROP FS) will work. First of all, we need such file system because we will use a flash memory. We don’t want to rewrite always at the same place (it would wear the memory out). We also want to have a structure to know where we can find the data we want to read without scanning all the memory. We also want to have an erase strategy. If you want to consult our flash documentation, to better understand how the memory works, you can !
But before, I should remind you our architecture :


One drop contains different boxes. A box gathers together messages with same parameters and properties. As an example, a box “guest book” would be accessible for both reading and writing operations for everybody. The box will store messages which will have no timeout, but when the box would be full of messages, old messages would be erased and new messages would replace them. Another example is an “administration box” where messages would be statistics such as how many visitors pass next to the drop is stored, etc… This box would be accessible only for administration who would have to be authenticate before acessing the box. So, some parameters of the box are reading/writing rights, if messages stored into it should be spreadable, or if they would have an expiration date, …

Capture d'écran 2014-04-08 15.15.39

Our memory is cut into pages of 528 bytes. We decide in a first estimation to consider that we want to store messages 512 bytes long.
Some pages will work as files. They will be an index, to store all addresses of box. Then, a box page will store all addresses of messages it contains. In addition to the address, a byte for each address would be added : it is for knowing if the address written leads to a valid page or if is leads to a page with an indirection, or a page which can be erased. It will serve to know when the box contains a lot of messages with indirection or which should be delete, and launch specific operations to clean the memory.
On the schema, you can see that the index contains only one box. This box contains three messages. The first one has been edited. To avoid to use prematurely the memory by writting everytime in the same place, when you edit a message, you recreate it in the “next free page” and you store the address of the indirection in the metadata of the page (on the bottom of the page on the schema). The message three can be deleted. And the message two is valid, without any indirection.

I am sorry if it is not really clear. Don’t hesitate to ask questions if you have any.

1 comment to Drops N’ Roses : Drop File System

  • Blyste

    This afternoon, after my post, we thought about some problems trigger by this organisation of memory. So we discuss about erase strategies and storage strategies. So… It would probably change. I will update this post tomorrow to correct it.
    Sorry :'(