Storage Devices..
Storage device can be part of hardware (like ide,scsi,sata,ssd..) or not so it can be from san devices (as luns) from san storage (as emc,clarion..) or iscsi unit from network and usb sources and the others...
If you attached (for exa scsi disk) , kernel detected signals from the bus and for this , it creates one device(maybe more devices) representation of detected disk.This devices must be structure for processing on it and must cover our device. Actually we access our disk by the hardware - kernel(operations,processing) - driver(how to interact interacts with our hardware , modul (driver) contains code about our hardware for realize to process what we want and it usually written assembly language or c ) . So kernel use system drivers for access our scsi disk. We manage it by various utilities (packages , which is executable in operating system (dependicies must be in) via open,write,list by kernel syscalls.

And actually mount processing is sameway.Eventually we buy a disk from hardware vendor.Firstly we use fdisk utulity for create partitons and create a new partiton table.After than we have to format it for create appropriate fs structure to our system.And we attach it so install disk in our hardware..After than our operating system (actually kernel) handles for after that.."Resume Storage Devices .."

After kernel detects and identify (assing to a avaliable disk device ) we can mount this via matched the disk device (/dev/sda1 ). we use a directory as mount point or create newly.And than we call the mount..
Before the mount , i must mention vfs (virtual file system mechanism) in kernel.firstly all systems have a vfs layer in its own kernel.at this point , you can think mount operation is a trigger for adding processes a vfs entry to vsflist
for mount devices.but in mount operation is differ by fs type,
int mount(const char *source, const char *target,
const char *filesystemtype, unsigned long mountflags,
const void *data);
now we can call mount then these parameters passing to kernel by mount syscall
after than mount then vfs searchs filesystem types in the kernel filesystem table that system supports (vfs knows previously, it looks to where for table
list) and if finds so found valid fs and then it can call routines -fs specific- by appropriate fs this modul(driver) for reading superblock (contains fs
type , its size,a magic number , free blocks and startup and end adresses , inode list and free inodes ...). if not , vfs return this state to kernel then
kernel try to find appropriate fs modul in your modules if its then load memory and register this in to kernel.if is not return to mount it as unknown
filesystem type.
at the now vfs will read the superblock of device by fs modul and create a VFS superblock by sys_mount (vfsmount). sys_mount() finds avaliable disk device for our new disk..
in VFS the sys_mount()
/*
sys_mount arguments:
dev_name - name of the block special file, e.g., /dev/sda1
dir_name - name of the mount point, e.g., /mnt/mydisk
fstype - name of the filesystem type, e.g., ext3
flags - mount flags, e.g., read-only
data - filesystem-specific data
*/

Vfs process , ext2 and ext3 (and ext4)
filesystem mount is easy at this point for other than because structure is familiar.
Endly a mounted fs is like a part of system and you can list or find files that file structures and inode(caches) or [vfs inode], dentrys as open system
call and the others(e.g. getdents,fstat..)..

I hope you could help some..

Regards
ygemici