| /dragonfly/sys/kern/ |
| H A D | vfs_jops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | vfs_journal.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | vfs_sync.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | vfs_vopops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | vfs_mount.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | vfs_init.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/udf/ |
| H A D | udf_vnops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | udf_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/sys/ |
| H A D | vfsops.h | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | namecache.h | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | mount.h | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/ntfs/ |
| H A D | ntfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/procfs/ |
| H A D | procfs_subr.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | procfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/msdosfs/ |
| H A D | msdosfs_denode.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | msdosfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/nfs/ |
| H A D | nfs_node.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | nfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/nullfs/ |
| H A D | null_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | null_vnops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/mfs/ |
| H A D | mfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/hpfs/ |
| H A D | hpfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/smbfs/ |
| H A D | smbfs_node.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| H A D | smbfs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|
| /dragonfly/sys/vfs/ufs/ |
| H A D | ffs_vfsops.c | 6ddb7618 Fri Dec 17 00:18:49 GMT 2004 Matthew Dillon <dillon@dragonflybsd.org> VFS messaging/interfacing work stage 10/99:
Start adding the journaling, range locking, and (very slightly) cache
coherency infrastructure. Continue cleaning up the VOP operations vector.
Expand on past commits that gave each mount structure its own set of VOP
operations vectors by adding additional vector sets for journaling or
cache coherency operations. Remove the vv_jops and vv_cops fields
from the vnode operations vector in favor of placing those vop_ops directly
in the mount structure. Reorganize the VOP calls as a double-indirect
and add a field to the mount structure which represents the current
vnode operations set (which will change when e.g. journaling is turned on
or off). This creates the infrastructure necessary to allow us to stack
a generic journaling implementation on top of a filesystem.
Introduce a hard range-locking API for vnodes. This API will be used by
high level system/vfs calls in order to handle atomicy guarentees. It is
a prerequisit for: (1) being able to break I/O's up into smaller pieces
for the vm_page list/direct-to-DMA-without-mapping goal, (2) to support
the parallel write operations on a vnode goal, (3) to support the clustered
(remote) cache coherency goal, and (4) to support massive parallelism in
dispatching operations for the upcoming threaded VFS work.
This commit represents only infrastructure and skeleton/API work.
|