Re: route inode->block_device in 2.5?

From: Alexander Viro (viro@math.psu.edu)
Date: Tue Sep 17 2002 - 08:11:26 EST


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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:19 EST