File System

1
File System
2
NETOS 6 File System

• Architecture
• Design Goals
• File System Layer Design
• Storage Services Layer Design
• RAM Services Layer Design
• Flash Services Layer Design
• File Structure
• File and Directory Tables
• RTC support
• Security

3
NETOS 6 File System (p2)

• File System Layer Power Loss Recovery
• Flash Services Layer Power Loss Recovery
• Memory Requirements
• File System API
• Storage Services API
• RAM Services API
• Flash Services API

4
Architecture
5
Design Goals

• Support our existing libraries (FTP and AWS)
• Allow multiple file system volumes for a specific
  media type (RAM or NOR Flash)
• Allow user to install their own device drivers to
  create file system volumes on other types of
  devices (i.e. NAND Flash)
• Power loss recoverable for persistent media
• Background flash sector dirty block removal for
  faster writes
• Optimize for best overall Flash I/O performance.

6
Design Goals (p2)

• Variable block size support
• Dynamic user adjustable file I/O performance

7
File System Layer Design

• File I/O related API functions are asynchronous
  and send a I/O requests to the internal threads
• Up to 8 internal threads to process file I/O
  requests to respective file system volumes
• Each user thread can service up to 8 file system
  volumes of the same media type and block size
  (i.e. 3 RAM volumes with 1K block sizes serviced
  by an internal thread)
• User thread can poll the status of a file I/O
  request or provide a callback function.
• Block sizes supported are 512, 1K, 2K and 4K

8
File System Layer Design (p2)

• User must install the functions for the specific
  medias services driver (i.e. Flash Services API)

9
Storage Services Layer Design

• Storage Services layer is the interface between
  the File System API and the specific I/O services
  layers.
• Maintains an array of pointers to NAFS_IO_INTF
  control blocks which store the pointers to a
  specific I/O services API.
• File system layer passes a number which is the
  index to the array of pointers where the specific
  I/O Services API function pointers are stored.
• Respective I/O Services API function is then
  called.

10
RAM Services Layer Design

• RAM volume must be continuous region of
  statically or dynamically allocated RAM
• File system layer blocks are mapped directly to
  the RAM volume blocks. Thus, the file system
  layers logical block numbers correspond to the
  physical block numbers in the RAM volume.
• Each block in RAM volume has a 20 byte block
  header which includes a CRC32 checksum, a not
  dirty flag and a logical block number.
• Maintains an array of pointers to each block in
  the volume.

11
Flash Services Layer Design

• Flash volume must be at least two consecutive
  and equal size flash sectors.
• File system layer blocks are mapped indirectly to
  the Flash volume blocks. Thus, the file system
  layers logical block numbers do not correspond
  to the physical block numbers in the Flash
  volume.
• Each block in Flash volume has a 20 byte block
  header which includes a CRC32 checksum, a not
  dirty flag, a logical block number and a serial
  number.

12
Flash Services Layer Design (p2)

• Flash volume must have an erased sector available
  at all times to use as the transfer sector.
• Transfer sector is used to copy valid blocks from
  a full sector when the volume has no more empty
  (or erased) blocks.
• After the copy is completed, the source sector is
  erased and becomes the transfer sector and the
  dirty blocks from the source sector are removed.

13
Flash Services Layer Design (p3)

• User selects from two sector transfer algorithms
• Most dirty sector algorithm provides the most
  erased blocks per sector transfer operation
  potentially at the expense of wear leveling
• Random dirty sector algorithm provides better
  wear leveling potentially at the expense the
  efficiency of a sector transfer operation.

14
Flash Services Layer Design (p4)

• Indirectly block mapping requires maintaining 4
  tables
• Physical block status table
• Logical block to physical block table
• Sector block table
• Erased block table

15
Flash Services Layer Design (p5)

• Each Flash volume can have a dedicated background
  sector compacting thread that removes dirty
  blocks and creates erased blocks during idle
  time.
• Improves write performance since Flash sectors
  were erased ahead of time.

16
File Structure

• Based on the Unix I-node file structure
• Directories and files use the same I-node file
  structure
• Up to double indirect addressing is implemented.
• 512 block size allows mapping files over 8MB and
  over 96K files and directories.
• 1K block size allows mapping files over 64MB and
  over 768K files and directories.
• 2K block size allows mapping files over 512MB and
  over 6400K files and directories.

17
File Structure (p2)

• 4K block size allows mapping files over 4096MB
  and over 52224K files and directories.
• Group ID security feature is implemented.
• Max file or directory name is 64 chars
• Max directory path is 256 chars

18
Directory and File Tables

• Each volume has a directory and file table to
  track open files and directories associated with
  open files.
• Doubles as a directory and file cache since it
  remembers the location of previous accessed files
  and directories.
• File is opened with exclusive rights. It cannot
  be opened more than once.
• Opened file cannot be deleted or renamed.
• Directory where the opened file is located cannot
  be deleted or renamed either.

19
RTC Support

• SNTP (Simple Network Time Protocol)
• Hardware RTC
• File system uses time() to get raw time data
  which is number of seconds since 01/01/70
• File or directory's timestamp needs to be
  converted to calendar time using the C library's
  time related functions.
• No RTC option forces file system to not use
  time(). Files and directories are created with a
  timestamp of 0 and is incremented whenever file
  or directory is changed.

20
Security

• 8 Group ID levels
• Can be used as 8 owner IDs where a user can only
  access files and directories created by itself.
• Can be used as group IDs where different users
  have different read/write access different
  groups. For example, User 1 has read and write
  access to Group 1, but only read access to Group
  2.
• Can be used as combined owner and group IDs. For
  example groups 1 to 4 are used as owner IDs and
  groups 5 to 8 are used as group IDs.
• Users can use this feature as required.

21
Security (p2)

• Group IDs are defined by NAFS_GROUP1 to
  NAFS_GROUP8 bitmasks. When a file or directory
  is created, it will have one of the above group
  IDs.
• Root directory has a group ID that is the bitwise
  OR of the above group ID bitmasks. Any user can
  see the root directory, but can only access files
  directories that it has access permissions.
• Group access read masks are defined by
  NASYSACC_FS_GROUP1_READ to NASYSACC_FS_GROUP8_READ

22
Security (p3)

• Group access write masks are defined by
  NASYSACC_FS_GROUP1_WRITE to NASYSACC_FS_GROUP8_WRI
  TE
• A user must have read access to group X to see
  (or list) files and directories that belong to
  group X.
• A user must have read access to group X in order
  to open, read and close files that belong to
  group X.
• A user must have read and write access to group X
  to open, write and close files that belong to
  group X.

23
Security (p4)

• When creating a file (or directory), a user must
  have read and write access to the directory where
  the file (or directory) to be created is located,
  and the group id of the new file must be a group
  that the user has both read and write access.
• When renaming files and directories, a user must
  have read and write access to the directory where
  the file or directory to be renamed (or deleted )
  is located, and have read and write access to the
  file or directory to be renamed (or deleted).

24
File System Layer Power Loss Recovery

• Power loss related errors affect only the last
  file or last directory accessed for write
• Power loss recovery algorithms are the reverse of
  the write algorithms to create, write and delete
  files and directories.
• These algorithms are very tightly integrated such
  that write algorithms cannot be changed without
  affecting the power loss recovery algorithms.

25
File System Layer Power Loss Recovery(p2)

• Power loss recovery algorithm is recursive and
  requires up to 4 blocks of RAM per directory
  level traversed. For example, if directory has
  10 levels and 1K blocks are used, up to 40K of
  RAM are needed for power loss recovery algorithm.
• Current implementation allows power loss recovery
  checking for about 60 subdirectory levels.

26
Flash Services Layer Power Loss Recovery

• When a block is moved around due to a change in
  data or a sector transfer, the serial number in
  the block header is incremented and the new block
  is written before marking the old block as dirty.
• If power fails after the new block is written but
  before the old block is marked dirty, then
  there are 2 instances of the same logical block
  in the Flash volume.
• When power is resumed, two instances of the same
  logical block are detected and the block with the
  larger serial number is mapped the logical block
  table.

27
Flash Services Layer Power Loss Recovery (p2)

• Power loss recovery algorithms handle failures
  during a sector transfer operation.

28
Memory Requirements

• Flash centric design uses RAM tables to track
  free blocks and free inodes instead of storing
  these tables in the media.
• Reduces number of writes to the Flash volume.
  Updating tables in the Flash constantly will
  increase the number of dirty blocks, resulting
  in more sector transfer operations to remove
  dirty blocks. This design decision attempts to
  reduce the number of writes to the Flash volume
  to reduce wear and loss of performance.

29
Memory Requirements (p2)

• File system layer requires 4 bytes per free block
  in the volume and 4 bytes per free inode. For
  example, if volume has 1000 blocks and 500
  inodes, a total of (4 1000) (4 500) or 6KB
  of RAM is required.
• RAM I/O Services modules require 4 bytes per
  block in the volume. For example, if volume has
  1000 blocks, a total of (4 1000) or 4KB of RAM
  is required.

30
Memory Requirements (p3)

• Flash I/O Services modules requires 9 bytes per
  block in the volume. For example, if volume has
  1000 blocks, a total of (9 1000) or 9KB of RAM
  is required.
• Using RAM to build tables means that RAM
  requirements increase as the volume size
  increases. At some point, the amount of RAM
  needed for the tables becomes quite expensive,
  such that using a larger block size is required
  to reduce RAM requirements at the expense of
  block usage efficiency.

31
Asynchronous File I/O API Functions

• NAFScreate_file()
• NAFSdelete_file()
• NAFSrename_file()
• NAFSopen_file()
• NAFSread_file()
• NAFSwrite_file()
• NAFSopen_file_size()
• NAFSclose_file()
• NAFScreate_dir()
• NAFSdelete_dir()

32
Asynchronous File I/O API Functions (p2)

• NAFSrename_dir()
• NAFSdir_entry_count()
• NAFSlist_dir()

33
Control Block API Functions

• NAFSinstall_media_cb()
• NAFSinit_io_intf()
• NAFSinit_volume_cb()
• NAFSinstall_services()
• NAFSinit_io_request_cb()
• NAFSio_request_cb_status()

34
Status Information API Functions

• NAFSmedia_cb_table_size()
• NAFSmedia_cb_table_status()
• NAFSmedia_cb_volume_table_size()
• NAFSmedia_cb_volume_table_status()
• NAFSmedia_cb_block_size()
• NAFSvolume_stats()

35
Initialization API Functions

• NAFSinit()
• NAFScreate_volume()

36
Storage Services API

• SSinit()
• SSinstall_services()
• SScreate_volume()
• SSremove_volume()
• SSread_block()
• SSwrite_block()
• SSdelete_block()
• SSget_block_count()

37
RAM Services API

• RSScreate()
• RSSremove()
• RSSread_block()
• RSSwrite_block()
• RSSdelete_block()
• RSSget_block_count()

38
Flash Services API

• FSScreate()
• FSSremove()
• FSSread_block()
• FSSwrite_block()
• FSSdelete_block()
• FSSget_block_count()

39
Recommended Readings

• File System Specification
• Storage Services Specification
• Unix file system related material