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
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/
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.
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).