xref: /dragonfly/sys/vfs/hammer2/TODO (revision e314d7e2)
1
2* Currently the check code (bref.methods / crc, sha, etc) is being checked
3  every single blasted time a chain is locked, even if the underlying buffer
4  was previously checked for that chain.  This needs an optimization to
5  (significantly) improve performance.
6
7* flush synchronization boundary crossing check and current flush chain
8  interlock needed.
9
10* snapshot creation must allocate and separately pass a new pmp for the pfs
11  degenerate 'cluster' representing the snapshot.  This theoretically will
12  also allow a snapshot to be generated inside a cluster of more than one
13  node.
14
15* snapshot copy currently also copies uuids and can confuse cluster code
16
17* hidden dir or other dirs/files/modifications made to PFS before
18  additional cluster entries added.
19
20* transaction on cluster - multiple trans structures, subtrans
21
22* inode always contains target cluster/chain, not hardlink
23
24* cluster_modify_ip -> data returned mod to all chains
25* and hammer2_cluster_data() -> same thing
26
27* chain refs in cluster, cluster refs
28
29* check inode shared lock ... can end up in endless loop if following
30  hardlink because ip->chain is not updated in the exclusive lock cycle
31  when following hardlink.
32
33cpdup /build/boomdata/jails/bleeding-edge/usr/share/man/man4 /mnt/x3
34
35
36        * The block freeing code.  At the very least a bulk scan is needed
37          to implement freeing blocks.
38
39        * Crash stability.  Right now the allocation table on-media is not
40          properly synchronized with the flush.  This needs to be adjusted
41          such that H2 can do an incremental scan on mount to fixup
42          allocations on mount as part of its crash recovery mechanism.
43
44        * We actually have to start checking and acting upon the CRCs being
45          generated.
46
47        * Remaining known hardlink issues need to be addressed.
48
49        * Core 'copies' mechanism needs to be implemented to support multiple
50          copies on the same media.
51
52        * Core clustering mechanism needs to be implemented to support
53          mirroring and basic multi-master operation from a single host
54          (multi-host requires additional network protocols and won't
55          be as easy).
56
57* make sure we aren't using a shared lock during RB_SCAN's?
58
59* overwrite in write_file case w/compression - if device block size changes
60  the block has to be deleted and reallocated.  See hammer2_assign_physical()
61  in vnops.
62
63* freemap / clustering.  Set block size on 2MB boundary so the cluster code
64  can be used for reading.
65
66* need API layer for shared buffers (unfortunately).
67
68* add magic number to inode header, add parent inode number too, to
69  help with brute-force recovery.
70
71* modifications past our flush point do not adjust vchain.
72  need to make vchain dynamic so we can (see flush_scan2).??
73
74* MINIOSIZE/RADIX set to 1KB for now to avoid buffer cache deadlocks
75  on multiple locked inodes.  Fix so we can use LBUFSIZE!  Or,
76  alternatively, allow a smaller I/O size based on the sector size
77  (not optimal though).
78
79* When making a snapshot, do not allow the snapshot to be mounted until
80  the in-memory chain has been freed in order to break the shared core.
81
82* Snapshotting a sub-directory does not snapshot any
83  parent-directory-spanning hardlinks.
84
85* Snapshot / flush-synchronization point.  remodified data that crosses
86  the synchronization boundary is not currently reallocated.  see
87  hammer2_chain_modify(), explicit check (requires logical buffer cache
88  buffer handling).
89
90* on fresh mount with multiple hardlinks present separate lookups will
91  result in separate vnodes pointing to separate inodes pointing to a
92  common chain (the hardlink target).
93
94  When the hardlink target consolidates upward only one vp/ip will be
95  adjusted.  We need code to fixup the other chains (probably put in
96  inode_lock_*()) which will be pointing to an older deleted hardlink
97  target.
98
99* Filesystem must ensure that modify_tid is not too large relative to
100  the iterator in the volume header, on load, or flush sequencing will
101  not work properly.  We should be able to just override it, but we
102  should complain if it happens.
103
104* Kernel-side needs to clean up transaction queues and make appropriate
105  callbacks.
106
107* Userland side needs to do the same for any initiated transactions.
108
109* Nesting problems in the flusher.
110
111* Inefficient vfsync due to thousands of file buffers, one per-vnode.
112  (need to aggregate using a device buffer?)
113
114* Use bp->b_dep to interlock the buffer with the chain structure so the
115  strategy code can calculate the crc and assert that the chain is marked
116  modified (not yet flushed).
117
118* Deleted inode not reachable via tree for volume flush but still reachable
119  via fsync/inactive/reclaim.  Its tree can be destroyed at that point.
120
121* The direct write code needs to invalidate any underlying physical buffers.
122  Direct write needs to be implemented.
123
124* Make sure a resized block (hammer2_chain_resize()) calculates a new
125  hash code in the parent bref
126
127* The freemap allocator needs to getblk/clrbuf/bdwrite any partial
128  block allocations (less than 64KB) that allocate out of a new 64K
129  block, to avoid causing a read-before-write I/O.
130
131* Check flush race upward recursion setting SUBMODIFIED vs downward
132  recursion checking SUBMODIFIED then locking (must clear before the
133  recursion and might need additional synchronization)
134
135* There is definitely a flush race in the hardlink implementation between
136  the forwarding entries and the actual (hidden) hardlink inode.
137
138  This will require us to associate a small hard-link-adjust structure
139  with the chain whenever we create or delete hardlinks, on top of
140  adjusting the hardlink inode itself.  Any actual flush to the media
141  has to synchronize the correct nlinks value based on whether related
142  created or deleted hardlinks were also flushed.
143
144* When a directory entry is created and also if an indirect block is
145  created and entries moved into it, the directory seek position can
146  potentially become incorrect during a scan.
147
148* When a directory entry is deleted a directory seek position depending
149  on that key can cause readdir to skip entries.
150
151* TWO PHASE COMMIT - store two data offsets in the chain, and
152  hammer2_chain_delete() needs to leave the chain intact if MODIFIED2 is
153  set on its buffer until the flusher gets to it?
154
155
156				OPTIMIZATIONS
157
158* If a file is unlinked buts its descriptors is left open and used, we
159  should allow data blocks on-media to be reused since there is no
160  topology left to point at them.
161