[dm-devel] 2.6.5-udm2
thornber at redhat.com
thornber at redhat.com
Wed Apr 7 10:59:41 UTC 2004
http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.5/2.6.5-udm2.tar.bz2
Mainly just composting -udm1.
- Joe
Revision 1:
-mm1
Revision 2:
Fix 64/32 bit ioctl problems.
Revision 3:
Check the uptodate flag in sub-bios to see if there was an error.
[Mike Christie]
Revision 4:
Handle interrupts within suspend.
Revision 5:
dm.c: Use wake_up() rather than wake_up_interruptible() with the
eventq.
Revision 6:
dm_resume: dm_table_unplug_all() was being called on md->map, rather
than the 'map' we carefully took a reference on earlier on in the
function.
Revision 7:
Log an error if the target has unknown target type, or zero length.
Revision 8:
Correctly align the dm_target_spec structures during retrieve_status().
This patch applies to both 2.4 and 2.6 kernels.
Revision 9:
Clarify the comment regarding the "next" field in struct dm_target_spec. The
"next" field has different behavior if you're performing a DM_TABLE_STATUS
command than it does if you're performing a DM_TABLE_LOAD command.
See populate_table() and retrieve_status() in drivers/md/dm-ioctl.c for more
details on how this field is used.
Revision 10:
dm-ioctl(): In retrieve_status(), make sure we don't overrun the ioctl
buffer. [Kevin Corry]
Revision 11:
Documentation for the linear target. The last 2 scripts still need
testing.
Revision 12:
VFS lock patch [Chris Mason]
Revision 13:
Fix XFS to work with the new VFS-lock patch.
Revision 14:
Lock the filesystem while a device is suspended.
[Kevin Corry, Joe Thornber]
Revision 15:
Multipath target
Revision 16:
Multipath: move the path failure decision to the path
selector. Some ps's may want to select paths that have a couple
failures over one that has N failures. If a ps has to track this info
there didn't seem to be a compelling reason to also do it in
dm-mpath.c. Well code duplication and sharing is a good reason to do
it in dm-mpath. It would be nice if I could just add an init function
to any ps and leach off other people's work :) but is that too modular?
Additionally, if a ps fails to activate a path or cannot use it
during initialization it may want to fail it. [Mike Christie]
Revision 17:
Multipath: exports the register and unregister ps functions.
[Mike Christie]
Revision 18:
Multipath: makes priority group / path-selector initialization
possible. Remapping failed bios from end_io was not nice becuase you
couldn't choose a path until you knew a group was activated and what
paths in that group were still functional. Plus, incoming IO needed
to be mapped while failures were coming in.
I guess you could just make map_io sleep or do some internal queueing.
I choose the former, so I had to move the remap map_io call to
dispatch_failed_ios and add a get_mapinfo accessor function.
I think queueing incoming io while you finish the failed may be better,
but targets calling dm's queueing mechanism didn't seem right, and
reimplementing it didn't either. Well, I do not know if it is better
or not. While paths are failing performance is going to take a hit
so io ordering may only be a problem if you are concerned with
journaling or barrier type stuff (but as we end up sending IO down
multiple queues we cannot gaurantee ordering on the normal IO code
path anyways). [Mike Christie]
Revision 19:
Multipath: adds another accessor so path-selectors can access a path's
bdev. This is necessary for devices which need to send commands down
to the device. (see rdac-test-support.patch) [Mike Christie]
Revision 20:
Multipath: dispatch_failed_ios can sleep. It should not
disrupt other users of the default work queue. Under heavy load
or group/ps initializations on a single processor machine, this
conflict becomes painful. [Mike Christie]
Revision 21:
Multipath: attached patch initializes current_count correctly.
[Mike Christie]
Revision 22:
dm-io
Revision 23:
kcopyd
Revision 24:
snapshot target.
Revision 25:
mirror target
Revision 26:
Flakey target
Revision 27:
dm-zero
More information about the dm-devel
mailing list