stacked bdev driver, howto? locking of lower level block device

stacked bdev driver, howto? locking of lower level block device

[Lars Ellenberg]

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

Re: stacked bdev driver, howto? locking of lower level block device

[Lars Ellenberg]

ok, I got some answers. not that much though.

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.c does 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:
>> In 2.5 see bd_claim and bd_release in fs/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?

>> 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:
>> 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:
> 
> - 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