From c34ef2dc3cba84d71fd548b8b7ab90b5ae06f137 Mon Sep 17 00:00:00 2001 From: Joe Thornber Date: Thu, 16 Aug 2001 15:14:07 +0000 Subject: [PATCH] o added a description --- driver/device-mapper/device-mapper.c | 70 +++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 1 deletion(-) diff --git a/driver/device-mapper/device-mapper.c b/driver/device-mapper/device-mapper.c index 4a27704cb..970faaa5b 100644 --- a/driver/device-mapper/device-mapper.c +++ b/driver/device-mapper/device-mapper.c @@ -57,7 +57,75 @@ #include /* - * FIXME: write description + * This driver attempts to provide a generic way of specifying logical + * devices which are mapped onto other devices. + * + * It does this by mapping sections of the logical device onto 'targets'. + * + * When the logical device is accessed the make_request function looks up + * the correct target for the given sector, and then asks this target + * to do the remapping. + * + * A btree like structure is used to hold the sector range -> target + * mapping. Because we know all the entries in the btree in advance + * we can make a very compact tree, omitting pointers to child nodes, + * (child nodes locations can be calculated). Each node of the btree is + * 1 level cache line in size, this gives a small performance boost. + * + * A userland test program for the btree gave the following results on a + * 1 Gigahertz Athlon machine: + * + * entries in btree lookups per second + * ---------------- ------------------ + * 5 25,000,000 + * 1000 7,700,000 + * 10,000,000 3,800,000 + * + * Of course these results should be taken with a pinch of salt; the lookups + * were sequential and there were no other applications (other than X + emacs) + * running to give any pressure on the level 1 cache. + * + * Typically LVM users would find they have very few targets for each + * LV (probably less than 10). + * + * Target types are not hard coded, instead the + * 'register_mapping_type' function should be called. A target type + * is specified using three functions (see the header): + * + * dm_ctr_fn - takes a string and contructs a target specific piece of + * context data. + * dm_dtr_fn - destroy contexts. + * dm_map_fn - function that takes a buffer_head and some previously + * constructed context and performs the remapping. + * + * This file contains two trivial mappers, which are automatically registered: + * 'linear', and 'io_error'. Linear alone would be enough to implement most + * LVM features (omitting striped volumes and snapshots). + * + * At the moment this driver has a temporary ioctl interface, but I will + * move this to a read/write interface on either a /proc file or a + * char device. This will allow scripts to simply cat a text mapping + * table in order to set up a volume. + * + * At the moment the table assumes 32 bit keys (sectors), the move to + * 64 bits will involve no interface changes, since the tables wil be + * read in as ascii data. A different table implementation can + * therefor be provided at another time. Either just by changing offset_t + * to 64 bits, or maybe implementing a structure which looks up the keys in + * stages (ie, 32 bits at a time). + * + * More interesting targets: + * + * striped mapping; given a stripe size and a number of device regions + * this would stripe data across the regions. Especially useful, since + * we could limit each striped region to a 32 bit area and then avoid + * nasy 64 bit %'s. + * + * mirror mapping (reflector ?); would set off a kernel thread slowly + * copying data from one region to another, ensuring that any new + * writes got copied to both destinations correctly. Great for + * implementing pvmove. Not sure how userland would be notified that + * the copying process had completed. */ #define MAX_DEVICES 64 -- 2.43.5