omfs.rst (4229B)
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