Loading...
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
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