| /dragonfly/sys/vfs/hammer/ |
| H A D | hammer_cursor.h | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_transaction.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_subs.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_ioctl.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_cursor.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_flusher.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_io.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_btree.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_object.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_ondisk.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_vfsops.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_inode.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer_vnops.c | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|
| H A D | hammer.h | b84de5af Thu Apr 24 21:20:33 GMT 2008 Matthew Dillon <dillon@dragonflybsd.org> HAMMER 38A/Many: Undo/Synchronization and crash recovery
* Separate all frontend operations from all backend media synchronization.
The frontend VNOPs make all changes in-memory and in the frontend
buffer cache. The backend buffer cache used to manage meta-data is
not touched.
- In-memory inode contains two copies of critical meta-data structures
- In-memory record tree distinguishes between records undergoing
synchronization and records not undergoing synchronization.
- Frontend buffer cache buffers are tracked to determine which ones
to synchronize and which ones not to.
- Deletions are cached in-memory. Any number of file truncations
simply caches the lowest truncation offset and on-media records
beyond that point are ignored. Record deletions are cached as
a negative entry in the in-memory record tree until the backend
can execute the operation on the media.
- Frontend operations continue to have full, direct read access to
the media.
* Backend synchronization to the disk media is able to take place
simultaniously with frontend operations on the same inodes. This
will need some tuning but it basically works.
* In-memory records are no longer removed from the B-Tree when deleted.
They are marked for deletion and removed when the last reference goes
away.
* An Inode whos last reference is being released is handed over to the
backend flusher for its final disposition.
* There are some bad hacks and debugging tests in this commit. In particular
when the backend needs to do a truncation it special-cases any
negative entries it finds in the in-memory record tree. Also, if a
rename operation hits a deadlock it currently breaks atomicy.
* The transaction API has been simplified. The frontend no longer allocates
transaction ids. Instead the backend does a full flush with a single
transaction id (since that is the granularity the crash recovery code will
have anyway).
|