1 2* on fresh mount with multiple hardlinks present separate lookups will 3 result in separate vnodes pointing to separate inodes pointing to a 4 common chain (the hardlink target). 5 6 When the hardlink target consolidates upward only one vp/ip will be 7 adjusted. We need code to fixup the other chains (probably put in 8 inode_lock_*()) which will be pointing to an older deleted hardlink 9 target. 10 11* Filesystem must ensure that modify_tid is not too large relative to 12 the iterator in the volume header, on load, or flush sequencing will 13 not work properly. We should be able to just override it, but we 14 should complain if it happens. 15 16* Kernel-side needs to clean up transaction queues and make appropriate 17 callbacks. 18 19* Userland side needs to do the same for any initiated transactions. 20 21* Nesting problems in the flusher. 22 23* Inefficient vfsync due to thousands of file buffers, one per-vnode. 24 (need to aggregate using a device buffer?) 25 26* Use bp->b_dep to interlock the buffer with the chain structure so the 27 strategy code can calculate the crc and assert that the chain is marked 28 modified (not yet flushed). 29 30* Deleted inode not reachable via tree for volume flush but still reachable 31 via fsync/inactive/reclaim. Its tree can be destroyed at that point. 32 33* The direct write code needs to invalidate any underlying physical buffers. 34 Direct write needs to be implemented. 35 36* Make sure a resized block (hammer2_chain_resize()) calculates a new 37 hash code in the parent bref 38 39* The freemap allocator needs to getblk/clrbuf/bdwrite any partial 40 block allocations (less than 64KB) that allocate out of a new 64K 41 block, to avoid causing a read-before-write I/O. 42 43* Check flush race upward recursion setting SUBMODIFIED vs downward 44 recursion checking SUBMODIFIED then locking (must clear before the 45 recursion and might need additional synchronization) 46 47* There is definitely a flush race in the hardlink implementation between 48 the forwarding entries and the actual (hidden) hardlink inode. 49 50 This will require us to associate a small hard-link-adjust structure 51 with the chain whenever we create or delete hardlinks, on top of 52 adjusting the hardlink inode itself. Any actual flush to the media 53 has to synchronize the correct nlinks value based on whether related 54 created or deleted hardlinks were also flushed. 55 56* When a directory entry is created and also if an indirect block is 57 created and entries moved into it, the directory seek position can 58 potentially become incorrect during a scan. 59 60* When a directory entry is deleted a directory seek position depending 61 on that key can cause readdir to skip entries. 62 63* TWO PHASE COMMIT - store two data offsets in the chain, and 64 hammer2_chain_delete() needs to leave the chain intact if MODIFIED2 is 65 set on its buffer until the flusher gets to it? 66 67 68 OPTIMIZATIONS 69 70* If a file is unlinked buts its descriptors is left open and used, we 71 should allow data blocks on-media to be reused since there is no 72 topology left to point at them. 73