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