| /dragonfly/sbin/hammer2/ |
| H A D | cmd_debug.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| /dragonfly/sys/vfs/hammer2/ |
| H A D | hammer2_freemap.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_ioctl.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_flush.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_inode.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_vnops.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_chain.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2_vfsops.c | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|
| H A D | hammer2.h | diff 10136ab6 Thu Nov 14 04:23:02 GMT 2013 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Implement crash recovery, cleanups, stabilization
* Allocations which are made by the flush itself run in the next
transaction instead of the current transaction. We do this so the
flush code can flush a stable version of the freemap itself.
* Implement crash recovery. Due to the above mechanics an incremental
scan must be run at mount-time of all chains belonging to the last
transaction and ensure that the blocks are marked allocated in the
freemap. Since the scan is incremental this doesn't take very long.
* Add some chain API infrastructure to support the incremental scan.
* Allow transactions to operate on a single media mount point (hmp)
(verses a pfsmount (pmp)). Used by the recovery code.
* Take another pass on the flush algorithm, fixing a few bugs. The
filter is still pretty fragile unfortunately. Having to special-case
the root chains (hmp->vchain and hmp->fchain) is causing problems.
Add debugging to help figure out an assertion that still occurs.
|