route inode->block_device in 2.5?

route inode->block_device in 2.5?

[Peter T. Breuer]

Is there a pointer chain by which one can get to the struct
block_device of the underlying block device from an inode?

Well, or from kdev_t (since inode->i_rdev is such).

I want to drop a 'special' request on to the request queue of the
backing device, but I can't find a convenient entry point with more than
an inode to hand, and I can't find the route from there.  Tes, I can get
the major, and look at that offset in the blk_dev array, but those are
blk_dev_struct 's not struct block_device's.

I agree that you may well ask why I want to do this, but at the moment
this is just experimetin, so i can't answer sensibly - to try the effect
of 'special' requests, maybe. If it's not possible, tell me, and I'll
concentrate on some other thing.

Thanks for any hint kindly dropped ..

Peter

Re: route inode->block_device in 2.5?

[Anton Altaparmakov]

At 17:22 12/09/02, Peter T. Breuer wrote:
>Is there a pointer chain by which one can get to the struct
>block_device of the underlying block device from an inode?

struct inode->i_sb (== struct super_block)->s_bdev (== struct block_device).

Anton


-- 
   "I haven't lost my mind... it's backed up on tape." - Peter da Silva
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: route inode->block_device in 2.5?

[Alexander Viro]

On Tue, 17 Sep 2002, Anton Altaparmakov wrote:

> At 17:22 12/09/02, Peter T. Breuer wrote:
> >Is there a pointer chain by which one can get to the struct
> >block_device of the underlying block device from an inode?
> 
> struct inode->i_sb (== struct super_block)->s_bdev (== struct block_device).

... is meaningful only for local filesystems that happen to live on a
single block device and even that only if said local filesystems want
to use the helper functions that expect ->s_bdev to be there.

IOW, upper layers have no business using that field - it's for the
filesystem-specific code and helper functions such code decides to
call.

There might be such thing as underlying block device of a <foofs> inode.
There is no such thing as underlying block device of an inode.  For
quite a few filesystems it simply makes no sense.  For some it does
and for many of them ->i_sb->s_bdev indeed would give you that, but
that's it - it _is_ fs-dependent and there is no guarantee that
e.g. minixfs in 2.6.4-pre2 won't change leaving ->s_bdev NULL and
storing pointer to block device elsewhere (at which point it will
have to switch from sb_bread() and friends to something else).

The point being, VFS doesn't know, doesn't care and shouldn't presume
anything about private details of fs implementation.  Notice that
VFS != "all stuff in fs/*.c" - the latter includes a pile of library
functions intended for use by filesystem code.  That stuff obviously
can make whatever assumptions about fs internals it wants - the callers
know what data structures they have and can decide what can be called.

Re: route inode->block_device in 2.5?

[Andrew Morton]

Alexander Viro wrote:
> 
> ...
> There might be such thing as underlying block device of a <foofs> inode.

What he said.  Generally when the generic layers want to know
what the backing block_device is they defer this all the way down
to the point where they have called the filesystem's ->get_block
callback, and they pluck the block_dev pointer out of bh_result->b_bdev.

That's the only point at which it can be sanely resolved.

It may be different for different blocks of the file (striping;
swap_get_block() did this for the short period when it nearly
existed).