Re: new mount is broken w/regard to devnames in /etc/fstab

[Rob Landley <rob@landley.net>]

On 05/20/2013 03:52:29 PM, Linda Walsh wrote:
> 
> 
> 
> 
> Rob Landley wrote:
> > On 05/19/2013 12:01:18 AM, Linda Walsh wrote:
> >> 1) How is one supposed to get the real root device?
> >> It's not /dev/root -- and on my system /dev/root doesn't even  
> exist.
> > There was a thread on this a couple months ago:
> >   https://lkml.org/lkml/2013/3/20/315
> >
> > You can get the major/minor of a filesystem with the stat() system
> > call, or even the stat command line utility. That gives you the
> > major/minor of the device the filesystem was mounted from.
> >
> > Note that there's only a major/minor when the filesystem _has_ a
> > backing block device. If it's initramfs or tmpfs: there isn't one.  
> If
> > it's nfs, smbfs, or v9fs: there isn't one.
> ----
>     Indeed.
> 
>     Just that having to go through the extra stat call breaks
> *scripts* that relied on previous behavior.  I mean why the kernel
> can't put /dev/sdc1 in /proc/mounts instead of /dev/root when it
> was specifically passed root=/dev/sdc1 on it's command line
> seems a bit puzzling.

That part, I've never understood.

>     The thing is -- while there is a /dev/root in '/proc/mounts',  
> there
> is no '/dev/root' in '/dev/ NOR is there a "root" or "rootfs" listed
> in '/proc/devices'.  I.e. saying the boot occurred from /dev/root when
> /dev/root doesn't exist is a bit obfuscating, at best.

I taught mdev to make a symlink. I believe this predated the existence  
of devtmpfs. :)

>     That said, it's also incredibly non-portable to have to ...
> call 'stat' on '/'

Dynamically populating /dev is incredibly non-portable. It was all  
static devices back in the 90's.

> As for the boot from ramfs, it's odd that it doesn't list
> dev/ramdisk or /dev/mem as the major.

Because ramfs is not a ramdisk. It's a tiny shim that mounts the disk  
cache as a filesystem, and gives the data nowhere to go so it can't be  
freed unless you delete the files. The dentries are just dentry cache  
with no backing store, the file contents are just page cache with no  
backing store. It allocates more memory when you write files into it,  
and frees memory when you delete files out of it. (tmpfs is a layer on  
top of ramfs that imposes a maximum size so "cat /dev/zero > file"  
won't fill up all memory and kill your system, and adds hooks to copy  
them to swap space when the VM asks the filesystem to flush those pages  
instead of replying "no can do".)

I explicitly listed ramfs and tmpfs in the "no block device" entries  
above.

You're thinking of "ramdisk", in which you take a chunk of memory and  
treat it as a block device, then format it and mount it via a  
filesystem driver. This means that page cache is copied from said block  
device, so there's two copies of the data and an unnecessary filesystem  
driver copying data back and forth. All that's considerably more  
complicated and less efficient than just mounting the disk cache as a  
filesystem directly. (Ramdisk was the old way, ramfs is the new way.  
Between ramfs and loopback devices, ramdisks are pretty thoroughly  
obsolete.)

See Documentation/filesystems/ramfs-rootfs-initramfs.txt

Rob