Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jan 2000 02:09:49 -0500 (EST)
From:      "Mark W. Krentel" <krentel@dreamscape.com>
To:        freebsd-stable@freebsd.org
Subject:   fstat's use of device numbers
Message-ID:  <200001150709.CAA11205@dreamscape.com>

next in thread | raw e-mail | index | archive | help

I have a question about fstat's treatment of the high-order bits in a
device's minor number.  My /etc/fstab includes:

  # Device       Mountpoint    FStype   Options     Dump    Pass
  /dev/da0s2f    /usr          ufs      rw          2       2
  /dev/da0s3f    /home         ufs      rw          2       2

That is, /usr and /home are both the "f" partition on different slices
of the same disk.  As a result, these two partitions are confused by
fstat(1) with the -f flag (restrict to open files on the same file
system as the -f argument).

  % fstat -f /home 
  USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
  krentel  fstat      10702   wd /home    315401 drwxr-xr-x    2048  r
  krentel  fstat      10702 text /usr       7946 -r-xr-sr-x   10160  r
  ...

That is, I asked for files on /home, but I also got /usr, a separate
partition.  In general, this will happen whenever there are two
partitions with the same letter on different slices of the same disk.
The /dev entries are:

  % ls -l /dev/da0*f
  brw-r-----  1 root  operator    4,   5 Dec 24 20:06 /dev/da0f
  brw-r-----  1 root  operator    4, 0x00030005 Jul  1  1999 /dev/da0s2f
  brw-r-----  1 root  operator    4, 0x00040005 Jul  1  1999 /dev/da0s3f

Looking through the fstat.c source, in the ufs_filestat procedure, the
file system id is computed as:

  int
  ufs_filestat(vp, fsp)
          struct vnode *vp;
          struct filestat *fsp;
  {
          struct inode inode;
  
          if (!KVM_READ(VTOI(vp), &inode, sizeof (inode))) {
                  dprintf(stderr, "can't read inode at %p for pid %d\n",
                      (void *)VTOI(vp), Pid);
                  return 0;
          }
          fsp->fsid = inode.i_dev & 0xffff;

That is, the 0xffff mask erases the high-order bits of the major/minor
number packing and makes da0f, da0s2f, and da0s3f appear to be the
same partition.  Is this right?

Now, I don't know enough about Freebsd's treatment of minor numbers.
Is this a simple bug, fixable by removing the 0xffff mask?  I tried
that, and it seems to work.  Or, is the issue more complicated?
Or, should I just avoid creating Freebsd partitions on two slices of
the same disk?

--Mark Krentel


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001150709.CAA11205>