Specification of the Umsdos file system for LINUX

# --linux-.---: the EMD file

The strategy for inode management. UMSDOS lets the MSDOS fs run and does simple transformation to the in core inode content. It also adds information at the end of the inode structure. See /usr/include/linux/umsdos_fs_i.h.

[/usr/include/linux/umsdos_fs.h,47]
#Specification: EMD file / record size

Entry are 64 bytes wide in the EMD file. It allows for a 30 characters name. If a name is longer, contiguous entries are allocated. So a umsdos_dirent may span multiple records.

[linux/fs/umsdos/emd.c,282]
#Specification: EMD file structure

The EMD file uses a fairly simple layout. It is made of records (UMSDOS_REC_SIZE == 64). When a name can't be written is a single record, multiple contiguous record are allocated.

[linux/fs/umsdos/emd.c,183]
#Specification: EMD file / empty entries

Unused entry in the EMD file are identify by the name_len field equal to 0. However to help future extension (or bug correction :-( ), empty entries are filled with 0.

[/usr/include/linux/umsdos_fs_i.h,80]
#Specification: strategy / in memory inode

Here is the information specific to the inode of the UMSDOS file system. This information is added to the end of the standard struct inode. Each file system has its own extension to struct inode, so do the umsdos file system.

The strategy is to have the umsdos_inode_info as a superset of the msdos_inode_info, since most of the time the job is done by the msdos fs code.

So we duplicate the msdos_inode_info, and add our own info at the end.

For all file type (and directory) the inode has a reference to: the directory which hold this entry: i_dir_owner The EMD file of i_dir_owner: i_emd_owner The offset in this EMD file of the entry: pos

For directory, we also have a reference to the inode of its own EMD file. Also, we have dir_locking_info to help synchronise file creation and file lookup. This data is sharing space with the pipe_inode_info not used by directory. See also msdos_fs_i.h for more information about pipe_inode_info and msdos_inode_info.

Special file and fifo do have an inode which correspond to an empty MSDOS file.

symlink are processed mostly like regular file. The content is the link.

fifos add there own extension to the inode. I have reserved some space for fifos side by side with msdos_inode_info. This is just to for the show, because msdos_inode_info already include the pipe_inode_info.

The UMSDOS specific extension is placed after the union.

[/usr/include/linux/umsdos_fs_i.h,10]
#Specification: strategy / in memory inode

Here is the information specific to the inode of the UMSDOS file system. This information is added to the end of the standard struct inode. Each file system has its own extension to struct inode, so do the umsdos file system.

The strategy is to have the umsdos_inode_info as a superset of the msdos_inode_info, since most of the time the job is done by the msdos fs code.

So we duplicate the msdos_inode_info, and add our own info at the end.

For all file type (and directory) the inode has a reference to: the directory which hold this entry: i_dir_owner The EMD file of i_dir_owner: i_emd_owner The offset in this EMD file of the entry: pos

For directory, we also have a reference to the inode of its own EMD file. Also, we have dir_locking_info to help synchronise file creation and file lookup. This data is sharing space with the pipe_inode_info not used by directory. See also msdos_fs_i.h for more information about pipe_inode_info and msdos_inode_info.

Special file and fifo do have an inode which correspond to an empty MSDOS file.

symlink are processed mostly like regular file. The content is the link.

fifos add there own extension to the inode. I have reserved some space for fifos side by side with msdos_inode_info. This is just to for the show, because msdos_inode_info already include the pipe_inode_info.

The UMSDOS specific extension is placed after the union.

[linux/fs/umsdos/emd.c,194]
#Specification: EMD file / spare bytes

10 bytes are unused in each record of the EMD. They are set to 0 all the time. So it will be possible to do new stuff and rely on the state of those bytes in old EMD file around.