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