Intelligent File System - Terminology summary



The goal of this document is to roughly define how Intelligent File System should be splitted in layers. You mainly have 4 layers: physical layer (a kind of HAL), blocks layer (how are sector grouped into files), files layer (how are kept metadatas like filename, length, etc.) and application layer (how do we define file formats).

Comments are welcome on clicker developers forum or by e-mail to Pype


block device
Oldly called a "disk unit", this is a driver that will provide the block-device interface to the rest of the file system. That interface mainly offers the ability to read and write chunks of datas (called sectors by hardware manufacturers and blocks by OS designers) of a given device.
It requires the client of the interface to give a block number identifying (with the device-id) the chunk of datas uniquely. All blocks of a given device have the very same byte size, but blocks size may be different between two devices.
p
h
y
s
i
c
volume
Looks roughly like a Partition. It has the total control over a set of blocks from one or many devices. It will define how the blocks are organized to form logical structures and decides which block is free and which isn't (for its internal use). It can therefore be seen as a collection of several components:
  • the blocks allocation unit that maintains a pool of free blocks
  • the logical units that provides interfaces to access datas blocks for reading/writing. Those interfaces deal with collections of blocks - looking like files having no name except that you can only read/write with block granularity (thus still hardware-dependent). Writing with some parameters may lead to implicit allocation of some new blocks in the collection.
  • the splitter unit that can select a contiguous area of blocks within its own blocks and delegate their management to another volume instance that could have specific organisation.


B
l
o
c
k

s

o
r
g
a
n
i
s
a
t
i
o
n

data nodes
Also called data blocks , are some disk blocks used to store pure datas and that are directly accessible for reading/writing by higher levels through one of the volume's logical unit.
index nodes
Or index blocks, are disk blocks used internally by the logical unit to organize data blocks. It mainly stores pointers to those data blocks with some search informations (if needed) and pointers to other index blocks of the same blocks collection. One of them - the root block - is used for collection identification. It's usually the first of a chain or the root of a tree - depending on how the collection is organized (as a set, an array, a list ...).

both data and index nodes are related to the volume interface.
file handle
This entity manipulates the blocks content to provide byte-granularity access to the file (like what you usually used to do with seek/read/write) or record-granularity if it's a record-based file (for databases, etc). File handles is the layer where pid of the requester are checked and where caching usually occurs.
It will also perform mapping between file-system objects (files & directories) and root index nodes
f
i
l
e
s

m
a
n
a
g
e
m
e
n
t


groups
This entity provide a naming service, using directory classes to retrieve informations (and, among others, root index node) and create file handles from a filename. To do so, it uses special blocks called informations nodes that collect everything related to a file that is not file content.
information nodes
Also called i-nodes, are blocks (usually standalone) that hold everything you want to remember about a file and that is not pure application datas, like the last modification date, the content-size, the mime type, and possibly more custom informations. You can ask to a inode file-system object to be produced from a filename by a group, so that you can read out or modify such so-called metadatas.
Some interresting meta-datas are the root index node identifier and the file class identifier.
file class
Application-defined metadatas holder. This is a place to store infos about how the file's datas and metadatas can be interpreted by applications, improving the usual file service in a stronger service. It defines how the file classes database can be accessed and how it is structured. The FileSystem doesn't really care what you put in your file classes, except that it will check that the custom metadatas you put in inodes is coherent with your file class definition.
a
p
p
l
i
c
a
t
i
o
n
s
group class
Holds informations about how to interpret specific directory classes when found. This is rather a kind of auto-pluggin feature for the file system (first time you encounter a Zip file, you check its group class and resolve it to find the proper plug-in, then you load that plugin and you're ready to interprete Zip files as directories).
Virtually any file class could also be a group class (this is, have a group plugin in the file system modules) if it make sense, which allow you to define custom metadatas (compression level, release notes, etc.) with a directory. This means groups also have a inode and can be read/written on a record basis ...