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