linux/Documentation/filesystems/omfs.rst
<<
>>
Prefs
   1.. SPDX-License-Identifier: GPL-2.0
   2
   3================================
   4Optimized MPEG Filesystem (OMFS)
   5================================
   6
   7Overview
   8========
   9
  10OMFS is a filesystem created by SonicBlue for use in the ReplayTV DVR
  11and Rio Karma MP3 player.  The filesystem is extent-based, utilizing
  12block sizes from 2k to 8k, with hash-based directories.  This
  13filesystem driver may be used to read and write disks from these
  14devices.
  15
  16Note, it is not recommended that this FS be used in place of a general
  17filesystem for your own streaming media device.  Native Linux filesystems
  18will likely perform better.
  19
  20More information is available at:
  21
  22    http://linux-karma.sf.net/
  23
  24Various utilities, including mkomfs and omfsck, are included with
  25omfsprogs, available at:
  26
  27    https://bobcopeland.com/karma/
  28
  29Instructions are included in its README.
  30
  31Options
  32=======
  33
  34OMFS supports the following mount-time options:
  35
  36    ============   ========================================
  37    uid=n          make all files owned by specified user
  38    gid=n          make all files owned by specified group
  39    umask=xxx      set permission umask to xxx
  40    fmask=xxx      set umask to xxx for files
  41    dmask=xxx      set umask to xxx for directories
  42    ============   ========================================
  43
  44Disk format
  45===========
  46
  47OMFS discriminates between "sysblocks" and normal data blocks.  The sysblock
  48group consists of super block information, file metadata, directory structures,
  49and extents.  Each sysblock has a header containing CRCs of the entire
  50sysblock, and may be mirrored in successive blocks on the disk.  A sysblock may
  51have a smaller size than a data block, but since they are both addressed by the
  52same 64-bit block number, any remaining space in the smaller sysblock is
  53unused.
  54
  55Sysblock header information::
  56
  57    struct omfs_header {
  58            __be64 h_self;                  /* FS block where this is located */
  59            __be32 h_body_size;             /* size of useful data after header */
  60            __be16 h_crc;                   /* crc-ccitt of body_size bytes */
  61            char h_fill1[2];
  62            u8 h_version;                   /* version, always 1 */
  63            char h_type;                    /* OMFS_INODE_X */
  64            u8 h_magic;                     /* OMFS_IMAGIC */
  65            u8 h_check_xor;                 /* XOR of header bytes before this */
  66            __be32 h_fill2;
  67    };
  68
  69Files and directories are both represented by omfs_inode::
  70
  71    struct omfs_inode {
  72            struct omfs_header i_head;      /* header */
  73            __be64 i_parent;                /* parent containing this inode */
  74            __be64 i_sibling;               /* next inode in hash bucket */
  75            __be64 i_ctime;                 /* ctime, in milliseconds */
  76            char i_fill1[35];
  77            char i_type;                    /* OMFS_[DIR,FILE] */
  78            __be32 i_fill2;
  79            char i_fill3[64];
  80            char i_name[OMFS_NAMELEN];      /* filename */
  81            __be64 i_size;                  /* size of file, in bytes */
  82    };
  83
  84Directories in OMFS are implemented as a large hash table.  Filenames are
  85hashed then prepended into the bucket list beginning at OMFS_DIR_START.
  86Lookup requires hashing the filename, then seeking across i_sibling pointers
  87until a match is found on i_name.  Empty buckets are represented by block
  88pointers with all-1s (~0).
  89
  90A file is an omfs_inode structure followed by an extent table beginning at
  91OMFS_EXTENT_START::
  92
  93    struct omfs_extent_entry {
  94            __be64 e_cluster;               /* start location of a set of blocks */
  95            __be64 e_blocks;                /* number of blocks after e_cluster */
  96    };
  97
  98    struct omfs_extent {
  99            __be64 e_next;                  /* next extent table location */
 100            __be32 e_extent_count;          /* total # extents in this table */
 101            __be32 e_fill;
 102            struct omfs_extent_entry e_entry;       /* start of extent entries */
 103    };
 104
 105Each extent holds the block offset followed by number of blocks allocated to
 106the extent.  The final extent in each table is a terminator with e_cluster
 107being ~0 and e_blocks being ones'-complement of the total number of blocks
 108in the table.
 109
 110If this table overflows, a continuation inode is written and pointed to by
 111e_next.  These have a header but lack the rest of the inode structure.
 112
 113