| /dragonfly/sys/vfs/hammer2/ |
| H A D | TODO | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_cluster.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_subr.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_freemap.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_ioctl.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_flush.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_inode.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_vnops.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_chain.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2_vfsops.c | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|
| H A D | hammer2.h | diff da6f36f4 Wed Jul 30 07:17:29 GMT 2014 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - major simplification of algorithms part 1/many
* Huge simplification of in-memory data structures and algorithms.
Remove delete-duplicate, ownerq (shadow copies), dbq, dbtree, and most of
the xid lo/hi sequencing. Remove all the complexities related to
managing the above elements. Net removal of ~1500 lines of code or so.
* Blockmap deletions are now handled by the frontend, so the backend doesn't
need to deal with shadowed deletions. This is still fairly optimal since
insertions are still handled by the backend during flushes. So for quick
create/delete operations the blockmap is never even initialized which means
that deletions don't have to remove anything.
* Cleanup buffer cache on file removal / last-close, but allow file delete
to simply wipe out the inode. Don't bother iterating its indirect blocks
or data blocks on-media but use the flush code to get rid of any chains
still cached.
* Buffer invalidation on permanent chain deletions for modified chains.
* Major items still TODO: flush interlocks and meta-data updates.
|