From: Joe Thornber <joe@fib011235813.fsnet.co.uk>
To: Linux Mailing List <linux-kernel@vger.kernel.org>,
lvm-devel@sistina.com, linux-lvm@sistina.com
Subject: New device-mapper patchset for 2.5.51
Date: Fri, 13 Dec 2002 11:50:14 +0000 [thread overview]
Message-ID: <20021213115014.GA15675@reti> (raw)
If anyone was experiencing problems with dm could they please try this
patchset and give me feedback.
Thanks,
- Joe
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-3.tar.bz2
Changes
-------
Revision 1:
Four constants:
DM_DIR,
DM_MAX_TYPE_NAME,
DM_NAME_LEN,
DM_UUID_LEN
Were being declared in device-mapper.h, these are all specific to
the ioctl interface, so they've been moved to dm-ioctl.h. Nobody
in userland should ever include <linux/device-mapper.h> so remove
ifdef __KERNEL guards.
Revision 2:
An error value was not being checked correctly in open_dev().
[Kevin Corry]
Revision 3:
Return -ENOTBLK if lookup_device() finds the inode, but it
is not a block device. [Cristoph Hellwig]
Revision 4:
No need to validate the parameters if we are doing a
REMOVE_ALL command.
Revision 5:
check_device_area was comparing the bytes with sectors.
[Stefan Lauterbach]
Revision 6:
minor change for dm-strip.c. Tests for correct chunksize before it allocates
the stripe context. [Heinz Mauelshagen]
Revision 7:
There's a bug in the dm-stripe.c constructor failing top check if enough
destinations are handed in. [Heinz Mauelshagen]
Revision 8:
Give each device its own io mempool to avoid a potential
deadlock with stacked devices. [HM + EJT]
Revision 9:
queue_io() was checking the DMF_SUSPENDED flag rather than the new
DMF_BLOCK_IO flag. This meant suspend could deadlock under load.
Revision 10:
dm_suspend(): Stop holding the read lock around the while loop that
waits for pending io to complete.
Revision 11:
Add a blk_run_queues() call to encourage pending io to flush
when we're doing a dm_suspend().
Revision 12:
dec_pending(): only bother spin locking if io->error is going to be
updated. [Kevin Corry]
Revision 13:
md->pending was being incremented for each clone rather than just
once. [Kevin Corry]
Revision 14:
Some fields in the duplicated bio weren't being set up properly in
__split_page(). [Kevin Corry]
Revision 15:
Remove some paranoia in highmem.c, need to check this with Jens Axboe.
Revision 16:
Remove verbose debug message 'Splitting page'.
Revision 17:
o If there's an error you still need to call bio_endio with bio->bi_size
as the 'done' param.
o Simplify clone_endio.
[Kevin Corry]
Revision 18:
The block layer does not honour bio->bi_size when issuing io, instead
it performs io to the complete bvecs. This means we have to change
the bio splitting code slightly.
Given a bio we repeatedly apply one of the following three operations
until there is no more io left in the bio:
1) The remaining io does not cross an io/target boundary, so just
create a clone and issue all of the io.
2) There are some bvecs at the start of the bio that are not split by
a target boundary. Create a clone for these bvecs only.
3) The first bvec needs splitting, use bio_alloc() to create *two*
bios, one for the first half of the bvec, the other for the second
half. A bvec can never contain more than one boundary.
Revision 19:
For large bios it was possible to look up the wrong target. Bug
introduced by the recent splitting changes.
Revision 20:
The linear target was getting the start sector wrong when doing a
dm_get_device(). [Kevin Corry]
next reply other threads:[~2002-12-13 11:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-13 11:50 Joe Thornber [this message]
2002-12-14 23:17 ` New device-mapper patchset for 2.5.51 Paul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021213115014.GA15675@reti \
--to=joe@fib011235813.fsnet.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@sistina.com \
--cc=lvm-devel@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox