stacked bdev driver, howto? locking of lower level block device
Hi there, I'm new on this list.
I do some happy hacking with drbd, which is "distributed replicated block device", a stacked block device driver by Phillipp Reisner, aiming towards network raid, GFS, this stuff.
I'd like to implement some kind of locking of the lower level block device, so nobody can mount it/modify it underneath the drbd driver.
I know drivers/md/md.c does this somehow. I tried to understand and adapt, but it does not work.
Hopefully my questions are trivial to some of you. Please put me on the right track.
- How does block device locking work?
- In which mode do I have to open it?
- Which flags have to be set?
- What else am I missing?
TIA
Lars-Gunnar
A message that is not in the archive (sent off-list or not yet received): [email protected]
ok, I got some answers. not that much though.
Quoted 6 lines · On Mon, Aug 05, 2002 at 10:16:52PM +0200, I wrote:
I'd like to implement some kind of locking of the lower level block device, so nobody can mount it/modify it underneath the drbd driver.
I know
drivers/md/md.cdoes this somehow. I tried to understand and adapt, but it does not work.
to be more explicit:
/*
* prevent the device from being mounted, repartitioned or
* otherwise reused by a RAID array (or any other kernel
* subsystem), by opening the device. [simply getting an
* inode is not enough, the SCSI module usage code needs
* an explicit open() on the device]
*/
static int lock_rdev(mdk_rdev_t *rdev)
but this does _not_ prevent the device from being mounted or used, I did not check the repartitioning.
On Tue, Aug 06, 2002 at 12:42:38AM -0500, Milton Miller suggested:
Quoted 1 line
Quoted 1 line
In 2.5 see
bd_claimandbd_releaseinfs/block_dev.c
well, I need to have this on 2.4 for now. I did not check the 2.5 code yet. other opinions whether this will work when we swithc to 2.5?
Quoted 3 lines
Quoted 3 lines
In 2.4 as fars as I know you have to add yourself to the list of checks that are incomplete and don't all check against each other (swap, filesystems, raid, etc).
could someone be so kind an be more explicit please. what piece of code do "list of checks" translate to?
or do I have to follow this?
On Wed, Aug 07, 2002 at 10:51:00AM -0700, Tim Pepper had the impression:
Quoted 8 lines
Quoted 8 lines
this is not possible from what I've seen inside the kernel. You can do a bdget/blkdev_get() on teh underlying dev, but as far as I saw that only prevents somebody from fdisking the device.
I think a lot of people figure this is just in line with the unix way of allowing you to shoot yourself in the foot if you want. I don't have a big problem with that, but understand the arguments to the contrary.
is this the case? it is not possible?
I understand that all this is not that important, but I want do do it anyways, to reduce the careless foot shooter. I suppose, iff someone really wants to, the shooting can be done with raw io anyways. no problem, then every now and then someone will have to do some transplantation...
BTW: why can I mount just about every device multiple times on different
mountpoints at the same time?
ok, my questions remain:
Quoted 5 lines
- How does block device locking work?
- In which mode do I have to open it?
- Which flags have to be set?
- What else am I missing?
Thanks.
Lars-Gunnar