Bug #741

vinum problems

Added by eric.j.christeson almost 7 years ago. Updated over 6 years ago.

Status:ClosedStart date:
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I'm getting kernel panics related to vinum. I've been running -devel
for a couple of months now, updating every couple of days. Currently
I've got 1.11.0-DEVELOPMENT as of yesterday afternoon (2007-07-25)
installed.
I follow the make buildworld, buildkernel, installkernel,
installworld, upgrade process detailing in UPDATING

FS layout is:
-bash-3.2$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 248M 147M 81M 65% /
/dev/da0s1d 248M 15M 213M 7% /var
/dev/da0s1e 992M 348M 566M 38% /tmp
/dev/da0s1f 10G 3.7G 5.9G 38% /usr
/dev/da0s1g 3.9G 437M 3.1G 12% /home
procfs 4.0K 4.0K 0B 100% /proc

with my vinum device on /usr/space. I have ad0 and ad1 to use for vinum.

I nuked the vinum config on the drives using dd, and rand fdisk and
disklabel. I also nuked /dev/vinum.

bash-3.2# vinum start
loads vinum.ko and starts vinum just fine, but then funky things start
happening to the other filesystems.
bash-3.2# dmesg
vinum: loaded
vinum: no drives found
dscheck(#da/0x20003): attempt to access non-existant partition
dscheck(#da/0x20003): attempt to access non-existant partition
dscheck(#da/0x20003): attempt to access non-existant partition
dscheck(#da/0x20003): attempt to access non-existant partition
dscheck(#da/0x20006): attempt to access non-existant partition
dscheck(#da/0x20006): attempt to access non-existant partition

bash-3.2# cd /usr
bash-3.2# ls
bin games libdata lost+found pkgsrc
space
crash include libexec obj sbin
src
freebsd_pkg lib local pkg share
sup

bash-3.2# ls -l
ls: freebsd_pkg: Bad file descriptor
ls: include: Bad file descriptor
ls: libdata: Bad file descriptor
ls: lost+found: Bad file descriptor
ls: obj: Bad file descriptor
ls: pkgsrc: Bad file descriptor
ls: space: Bad file descriptor
ls: src: Bad file descriptor
ls: sup: Bad file descriptor
total 30
drwxr-xr-x 2 root wheel 6656 Jul 26 06:16 bin
drwxr-xr-x 2 root wheel 512 Jun 13 09:01 crash
drwxr-xr-x 3 root wheel 1024 Jul 26 06:14 games
drwxr-xr-x 10 root wheel 4608 Jul 26 06:16 lib
drwxr-xr-x 10 root wheel 1024 Jul 26 06:16 libexec
drwxr-xr-x 15 root wheel 512 May 3 09:46 local
drwxr-xr-x 16 root wheel 512 Apr 30 11:58 pkg
drwxr-xr-x 2 root wheel 4096 Jul 26 06:17 sbin
drwxr-xr-x 26 root wheel 512 Mar 13 18:55 share

With more of the dscheck... stuff in dmesg and this gem:

spec_getpages:(#da/0x20005) I/O read failure: (error=22) bp 0xc11bfa00 vp 0
size: 65536, resid: 65536, a_count: 65536, valid: 0x0
nread: 0, reqpage: 0, pindex: 0, pcount: 16

When I try to edit a file that suffers from the 'Bad file descriptor' error.

Eventually the box will panic, though it's more resistant to that than
1.9 from a couple of days ago was. That would panic the first time I
tried to edit or access one of these files.

Unload vinum.ko

bash-3.2# kldunload vinum
bash: /sbin/kldunload: Input/output error

bash-3.2# vinum stop
vinum unloaded

but the problems with other files persist.

Any ideas?

Thanks,
Eric

History

#1 Updated by dillon almost 7 years ago

:bash-3.2# vinum start
:loads vinum.ko and starts vinum just fine, but then funky things start

I've seen this happen when using vinum start too. I have not figured
out what is going on yet.

Try telling vinum to load its config from a particular drive and
do not use 'vinum start', and see if that helps.

-Matt

#2 Updated by eric.j.christeson almost 7 years ago

I don't have any config on either drive. I'm starting with bare drives.

Eric

#3 Updated by c.turner almost 7 years ago

pretty much the execution of 'vinum start' hoses things up, bare or not.

if you do a 'resetconfig', followed by a 'create',
and then use 'read' across subsequent reboots, things continue to work.

#4 Updated by dillon over 6 years ago

I've tracked the vinum problem down to the fact that vinum is trying
to synthesize devices and talk directly to the device layer. It's
doing a number of things wrong:

* It is opening and closing the underlying device regardless of whether
the underlying device wants only a 'last close' close. This is
causing the underlying device to be closed even if other sources,
such as other filesystems, are holding it open.

This is what is causing all the dscheck errors and blowing up the
rest of the system.

* It is overriding the device's si_iosize_max setting. This is just
plain illegal. vinum has no business setting an underlying device's
maximum physical I/O size.

* It is calling the device strategy functions with I/O sizes which
are not bounded by the device's si_iosize_max setting.

I am working on a fix right now, which is basically to make vinum use
the vnode interface to access underlying devices instead of the device
interface.

-Matt

Also available in: Atom PDF