more changes on original files
[linux-2.4.git] / fs / hfs / TODO
1 The hfs_fs "to do" list.
2 ------------------------
3 Items are broken down into groups and the groups are listed in order
4 from most important to least important.  The items within each group
5 are not placed in any particular order.  The order in which items are
6 listed probably doesn't correlate well with the order they will be
7 addressed.
8
9 Genuine bugs:
10 1.      Header files have compiled-in limit (currently 10) on descriptors.
11
12 Missing features:
13 1.      1k block support is needed for some devices.
14 2.      An ioctl()-based interface is needed to provide a consistent way
15         to do things under all of the representations of forked files.
16
17 Possible additional "fork" mount options:
18 1.      AppleSingle.
19 2.      The scheme MacOS uses on FAT disks (PC Exchange).
20 3.      "Flat" (no resource forks or metadata).
21
22 Performance issues:
23 1.      Use drAllocPtr to speed block allocations.
24 2.      Keep a real cache of bnodes, rather than just a hash table of
25         the ones that are currently in use.
26 3.      Keep a real cache of extent records, rather than just a linked
27         list of the ones that are currently in use and the one most
28         recently used.  This is particularly needed to get acceptable
29         performance with multiple readers on a file.  Perhaps simply
30         keep them in memory once they've been read until the file is
31         closed.
32
33 Implementation details:
34 1.      Allocation scheme could/should be closer to that used by Apple.
35 2.      B*-tree insertion could/should be closer to that used by Apple.
36 3.      Magic-number checks on data structures are rarely done.
37 4.      Error recovery is needed for failed binsert(), bdelete() and rename().
38 5.      Deadlock detection is needed to make insert_empty_bnode() and
39         bdelete() less likely to hang on a corrupted B-tree.
40 6.      Metadata for covered directories shouldn't appear in the filesystem.
41         Under CAP and AppleDouble it currently does.  However, the obvious
42         solution is a real performance killer and is not worth implementing.
43
44 Fantasy features:
45 1.      Access Desktop file/database for comment and icon.
46 2.      Implement mmap() for AppleDouble header files and CAP info files.
47 3.      Implement AppleShare client support.
48
49 Suggestions/comments/questions are welcome.
50 Code addressing any of the issues listed above is especially welcome.
51 Paul H. Hargrove
52 hargrove@sccm.Stanford.EDU