Date: Mon, 18 Nov 1996 11:23:23 -0800 From: Julian Elischer <julian@whistle.com> To: hackers@freebsd.org Subject: [Fwd: Device filesystem stumbling block] Message-ID: <3290B7AB.41C67EA6@whistle.com>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------446B9B3D2781E494167EB0E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
this time get the address right!
--------------446B9B3D2781E494167EB0E7
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <32903133.41C67EA6@whistle.com>
Date: Mon, 18 Nov 1996 01:49:39 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: hackers@freebsd
CC: mckusick@vangogh.cs.berkeley.edu
Subject: Device filesystem stumbling block
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David, John, Kirk.. HELP!
I have the device filesystem here working quite nicely..
until I try unmount a filesystem mounted from a device accessed
through devfs.
here's an example:
[IJ-julian.whistle.com] 28 mount -t devfs devfs /mnt
[IJ-julian.whistle.com] 29 mount /mnt/wd0e /data/mnt
[IJ-julian.whistle.com] 30 mount
/dev/wd0a on / (local, read-only)
/dev/wd0g on /var (local)
/dev/wd0h on /data (local)
procfs on /proc (local)
devfs on /mnt (local)
/mnt/wd0e on /data/mnt (local)
[IJ-julian.whistle.com] 31 sysctl -w debug.debugger=1
debug.debugger: 0 -> 1
{private mod to allow me to
drop into debugger to set a breakpoint at unmount(), and return}
[IJ-julian.whistle.com] 32 umount /data/mnt
at this point the process doing the unmount hangs...
tracing in the debugger gives.. (stopped at a breakpoint before
the tsleep in getblk() )
Breakpoint 2, getblk (vp=0xf0ae1880, blkno=16, size=2048, slpflag=0,
slptimeo=0) at ../../kern/vfs_bio.c:1068
(xxgdb) info stack
#0 getblk (vp=0xf0ae1880, blkno=16, size=2048, slpflag=0, slptimeo=0)
at ../../kern/vfs_bio.c:1068
#1 0xf0164544 in ffs_sbupdate (mp=0xf0b3ea00, waitfor=1) at
../../ufs/ffs/ffs_vfsops.c:1051
#2 0xf0163dfd in ffs_unmount (mp=0xf0b3ec00, mntflags=0, p=0xf0b34a00)
at ../../ufs/ffs/ffs_vfsops.c:672
#3 0xf01329f0 in dounmount (mp=0xf0b3ec00, flags=0, p=0xf0b34a00) at
../../kern/vfs_syscalls.c:309
#4 0xf0132928 in unmount (p=0xf0b34a00, uap=0xefbfff94,
retval=0xefbfff84) at ../../kern/vfs_syscalls.c:280
#5 0xf018882f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =
-272640000, tf_esi = 161190, tf_ebp = -272638864, tf_isp = -272629788,
tf_ebx = 0, tf_edx = 1, tf_ecx = 58, tf_eax = 22, tf_trapno = 7, tf_err
= 7, tf_eip = 11413, tf_cs = 31, tf_eflags = 582, tf_esp = -272640052,
tf_ss = 39}) at ../../i386/i386/trap.c:891
#6 0xf017fddf in Xsyscall ()
the vnode in question is:
$13 = {
v_flag = 8192,
v_usecount = 2,
v_writecount = 0,
v_holdcnt = 3,
v_lastr = 0,
v_id = 1568,
v_mount = 0xf0b34800,
v_op = 0xf09c0a00,
v_freelist = {
tqe_next = 0xf0ae1800,
tqe_prev = 0xdeadb
},
v_mntvnodes = {
le_next = 0xf0ae1900,
le_prev = 0xf0b34814
},
v_cleanblkhd = {
lh_first = 0xf29ad64c
},
v_dirtyblkhd = {
lh_first = 0x0
},
v_numoutput = 0,
v_type = VBLK,
v_un = {
vu_mountedhere = 0xf09a3f50,
vu_socket = 0xf09a3f50,
vu_specinfo = 0xf09a3f50,
vu_fifoinfo = 0xf09a3f50
},
v_lease = 0x0,
v_lastw = 0,
v_cstart = 0,
v_lasta = 0,
v_clen = 0,
v_ralen = 0,
v_usage = 1,
v_maxra = 0,
v_object = 0xf0b24980,
v_tag = VT_DEVFS,
v_data = 0xf0b47b00
}
and the buf in question is the buf holding the superblock for the
filesystem. It is marked BUSY, but nothing is dealing with it so
getblk waits forever. for the life of me I can't figure out
what I need to add to devfs to make that block be handled.
If it helps, here's the buf..
$15 = {
b_hash = {
le_next = 0x0,
le_prev = 0xf01c2168
},
b_vnbufs = {
le_next = 0xf29af0cc,
le_prev = 0xf29ad654
},
b_freelist = {
tqe_next = 0xf29af0cc,
tqe_prev = 0xf29ad9ac
},
b_act = {
tqe_next = 0x0,
tqe_prev = 0xf01c91dc
},
b_proc = 0x0,
b_flags = 8454708,
b_qindex = 0,
b_usecount = 6 '\006',
b_error = 0,
b_bufsize = 2048,
b_bcount = 2048,
b_resid = 0,
b_dev = 4,
b_un = {
b_addr = 0xf0ace000 ""
},
b_saveaddr = 0x0,
b_lblkno = 16,
b_blkno = 16,
b_iodone = 0,
b_iodone_chain = 0x0,
b_vp = 0xf0ae1880,
b_dirtyoff = 0,
b_dirtyend = 0,
b_rcred = 0x0,
b_wcred = 0x0,
b_validoff = 0,
b_validend = 0,
b_pblkno = 307279,
b_savekva = 0x0,
b_driver1 = 0x0,
b_driver2 = 0x0,
b_spc = 0x0,
b_cluster = {
cluster_head = {
tqh_first = 0xf29afc64,
tqh_last = 0xf29ac994
},
cluster_entry = {
tqe_next = 0xf29afc64,
tqe_prev = 0xf29ac994
}
},
b_pages = {0x0 <repeats 16 times>},
b_npages = 0
}
I don't understand what is supposed to find it and do the write back
that it is apparently waiting for.
I've looked in the 4.4 book but unfortunatly it doesn't seem to cover
this anywhere I can see. Certainly it lacks a clear diagram of
the linking in of filesystem meta-data in the buffer system.
I don't know where this buffer is hung off.
I guess I'm going to be single stepping through 'mount'
tomorrow to try figure this out, but any hints in the meanwhile
would be gratefully accepted..
julian
--------------446B9B3D2781E494167EB0E7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3290B7AB.41C67EA6>