- [X] CRC bitmaps :ejt:
- [X] pool_destroy ref counting isn’t right :ejt: This should be done as part of the data resizing work.
- [X] Test and complete pool resizing work :ejt:
- [X] Test device deletion :mike:
- [X] Test creation/removal of large numbers of devices :mike:
- [X] wire up btree value_types :ejt:
- [X] printks :mike: These need an audit. Spurious ones removing, most converting to DMWARNS etc.
- [X] symbolic flag field on pool target param :mike:
- [X] implement btree highest key :ejt:
- [X] mapped blocks count isn’t being set :ejt:
- [X] extend method for space maps (needed for resizing) :ejt:
- [X] rename multisnap -> thin. Rebranding exercise :ejt:, :mike:
- [X] crc metadata sm index :ejt:
- [X] return zeroes for unprovisioned reads :ejt:
- [X] factor common code in space map
- [X] disk space map must not allocate blocks within a transaction, much like the metadata sm. This is good, the more similar they are the easier to factor out the common code. It does mean we’re not quite crash proof atm.
- [X] Sometimes I’m getting kmem_cache name clashes in the block manager. We’re obviously not deleting the cache in a particular error path. Recently introduced. :ejt:
- [X] Check reference counts are correct somehow. :ejt:
thin_repair now checks this
- [X] detect recursive block locks :ejt:
- [ ] Put discard back in :ejt:
- [ ] implement the btree trimming :ejt:
- [ ] a bug found in the userland tools, check that nr_free in the last index entry is being set correctly if there are fewer than a whole blocks worth. Also check this is extended correctly. :ejt:
- [X] RHEL6.2 needs kzalloc (Mike knows what this means) :mike:
- [ ] some work needs to be done to verify tearing down thin devices when the pool has run out of space is done cleanly :ejt:
- [ ] Heinz got an oops when doing a dmsetup remove_all -f :ejt:
- [X] atm we only commit metadata when a FUA or FLUSH bio comes in (or when we shutdown). This allows too big a position to be built up. We should commit every n seconds, and make this configurable. :ejt:
Hard coded to 60 seconds for now.
- [ ] We need to know how many block locks can be held concurrently.
I think the worst case is:
3 for insert + 2 for lookup in space map to allocate shadow for the insert
But it would be nice to have a static analysis tool that could check this.
Userland tools [0/5]
All tools run offline for first release.
- [ ] multisnap_format :ejt:
- [ ] multisnap_repair :ejt:
- [ ] multisnap_calc_metadata_size :ejt:
- [ ] multisnap_display :ejt:
- [ ] multisnap lib :ejt: C library to wrap multisnap tools
- [ ] resize metadata device
- [ ] external origin (read-only)
- [ ] stacked pools causes lockdep to complain about bufio
- [ ] multisnap_display That uses the held_root to do this for an online pool
- [ ] We need tests with multiple pools :heinz:
- [ ] Integrate Kabi’s ramdisk tests, and use the pattern stomp program he’s found (http://www.scsifaq.org/RMiller_Tools/dt.html). :heinz: