sys/vfs/hammer2/TODO

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