How does the kernel chooses the 'vfat' module for fat32 partitions?
Hi List, I have one doubt regarding the component which determines that 'vfat' module is the correct module to be used for accessing fat32 file systems and how does vfat.ko became the ideal candidate for accessing fat32 partition? For example, even though my /etc/fstab doesn't contain any entry for my usbstick, which is having a fat32 partition, when I issued the command 'mount /dev/sdb1 /mnt/usb' after inserting the usbstick, I could see the following events in udevadm monitor --kernel --udev' s output. Pls note the lines "KERNEL[1304999552.510965] add /module/fat (module) KERNEL[1304999552.516633] add /module/vfat (module)" [Questions] 1. Who makes the decision that vfat.ko is to be used for fat32 partitions? Is it kernel/udev or some other component? 2. How does the kernel or the module loader determines that 'vfat' is the correct module to be used for accessing fat32 partition? AFAIK, there is nothing similar to 'MODULE_DEVICE_TABLE' in vfat.ko's sources, which maps partition type 'c' (partition type id for W95 FAT32) to vfat.ko (CMIIW) as in pci/usb drivers. [udevadm monitor output] KERNEL[1304999552.510965] add /module/fat (module) KERNEL[1304999552.512169] add /kernel/slab/fat_cache (slab) UDEV [1304999552.512212] add /module/fat (module) KERNEL[1304999552.512239] add /kernel/slab/fat_inode_cache (slab) UDEV [1304999552.512263] add /kernel/slab/fat_cache (slab) UDEV [1304999552.512289] add /kernel/slab/fat_inode_cache (slab) KERNEL[1304999552.516633] add /module/vfat (module) UDEV [1304999552.516861] add /module/vfat (module) KERNEL[1304999552.542026] add /module/nls_cp437 (module) UDEV [1304999552.542267] add /module/nls_cp437 (module) KERNEL[1304999552.545320] add /module/nls_iso8859_1 (module) UDEV [1304999552.545566] add /module/nls_iso8859_1 (module) [more entries...] TIA, -- Thanks Sudheer
hi Sudheer... On Tue, May 10, 2011 at 11:48, Sudheer Divakaran <inbox1.sudheer@gmail.com> wrote:
Hi List,
I have one doubt regarding the component which determines that 'vfat' module is the correct module to be used for accessing fat32 file systems and how does vfat.ko became the ideal candidate for accessing fat32 partition?
AFAIK, kernel simply iterates the filesystem module so far loaded (the ones you see in /proc/filesystems). Whichever match the superblock or main metadata of the target partition, that is the one which is gonna used... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi Mulyadi, On Tue, May 10, 2011 at 12:10 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
hi Sudheer...
On Tue, May 10, 2011 at 11:48, Sudheer Divakaran <inbox1.sudheer@gmail.com> wrote:
Hi List,
I have one doubt regarding the component which determines that 'vfat' module is the correct module to be used for accessing fat32 file systems and how does vfat.ko became the ideal candidate for accessing fat32 partition?
AFAIK, kernel simply iterates the filesystem module so far loaded (the ones you see in /proc/filesystems). Whichever match the superblock or main metadata of the target partition, that is the one which is gonna used...
vfat module was not loaded before, it got loaded only after I issued the mount command. We can see this info in the udev log. Moreover there was no entry for the usbstick partition in /etc/fstab. So someone kernel/userspace takes the decision that vfat.ko should be used for managing fat32 partitions. I was trying to identify this component. -- Thanks Sudheer
Hi,
vfat module was not loaded before, it got loaded only after I issued the mount command. We can see this info in the udev log. Moreover there was no entry for the usbstick partition in /etc/fstab. So someone kernel/userspace takes the decision that vfat.ko should be used for managing fat32 partitions. I was trying to identify this component.
'mount' itself was responsible for guessing the vfat driver. Running mount with -v gave the following output # mount -v /dev/sdb1 /mnt/usb mount: you didn't specify a filesystem type for /dev/sdb1 I will try type vfat /dev/sdb1 on /mnt/usb type vfat (rw) -- Thanks Sudheer
Hi... On Tue, May 10, 2011 at 14:47, Sudheer Divakaran <inbox1.sudheer@gmail.com> wrote:
'mount' itself was responsible for guessing the vfat driver. Running mount with -v gave the following output
we both are partly correct, from "man mount": " If no -t option is given, or if the auto type is specified, mount will try to guess the desired type. Mount uses the blkid or volume_id library for guessing the filesystem type; if that does not turn up anything that looks familiar, mount will try to read the file /etc/filesystems, or, if that does not exist, /proc/filesystems. All of the filesystem types listed there will be tried, except for those that are labeled "nodev" (e.g., devpts, proc and nfs). If /etc/filesystems ends in a line with a single * only, mount will read /proc/filesystems afterwards. " -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
participants (2)
-
Mulyadi Santosa -
Sudheer Divakaran