NetBSD Problem Report #37425
From scotte@intrepid.warped.com Sat Nov 24 01:20:15 2007
Return-Path: <scotte@intrepid.warped.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 8D18163B88C
for <gnats-bugs@gnats.NetBSD.org>; Sat, 24 Nov 2007 01:20:15 +0000 (UTC)
Message-Id: <E1Ivjgq-0007f1-Vx@intrepid.warped.com>
Date: Fri, 23 Nov 2007 17:20:12 -0800
From: scotte@warped.com
Sender: "Scott Ellis,,," <scotte@intrepid.warped.com>
Reply-To: scotte@warped.com
To: gnats-bugs@NetBSD.org
Subject: fss_snapshot_mount panic during fsck
X-Send-Pr-Version: 3.95
>Number: 37425
>Category: kern
>Synopsis: fsck on a system with snapshots resulted in panic...resolved after boot
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: hannken
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Nov 24 01:25:00 +0000 2007
>Closed-Date: Tue Dec 16 09:56:42 +0000 2008
>Last-Modified: Tue Dec 16 09:56:42 +0000 2008
>Originator: Scott Ellis
>Release: NetBSD 4.99.36
>Organization:
>Environment:
System: NetBSD intrepid 4.99.36 NetBSD 4.99.36 (INTREPID.P5W) #1: Tue Nov 20 17:17:23 PST 2007 scotte@intrepid:/nbu/source/netbsd/src/obj.amd64/nbu/source/netbsd/src/sys/arch/amd64/compile/INTREPID.P5W amd64
Architecture: x86_64
Machine: amd64
>Description:
Upon reboot, fsck occurred, and the system panic'ed:
panic: ffs_snapshot_mount: 861962 already on list
Stopped in pid 18.1 (mount_ffs) at netbsd:breakpoint+0x1: ret
db{0}> bt
breakpoint() at netbsd:breakpoint+0x1
ffs_snapremove() at netbsd:ffs_snapremove
ffs_mount() at netbsd:ffs_mount+0x6c0
do_sys_mount() at netbsd:do_sys_mount+0x3ac
sys___mount50() at netbsd:sys___mount50+0x33
syscall() at netbsd:syscall+0x177
Continuing caused a sync and reboot, at which time the filesystem was
pronounced clean, and all seems well.
>How-To-Repeat:
Torturing my system by doing (effectively):
fssconfig -c fss0 / /.foobar/`date`
fssconfig -u fss0
vnconfig -r vnd0 /.foobar/`date`
mount -o ro vnd0a /.woof/`date`
umount -f /.woof/`date`
vnconfig -u vnd0
rm /.foobar/`date`
(In a script, so that properly removes files/dirs/etc.)
Eventually the system froze (could not break into DDB it seems), seemingly
related to doing an 'ls' in one of the mounted snapshots while it was
being removed.
Reset the system and enjoy.
>Fix:
>Release-Note:
>Audit-Trail:
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Fri, 23 Nov 2007 17:35:40 -0800
This seems reliable (different inode number each time, obviously), after
any time the system is reset/crashes when in the middle of removing a
backing file from a snapshot.
A reboot (with the "clean" FS) and subsequent fsck in single-user shows
the filesystem to NOT be completely clean. But it doesn't seem wholly
corrupted (yet) either...just a few straggling file fragments that end
up in lost+found.
Responsible-Changed-From-To: kern-bug-people->hannken
Responsible-Changed-By: hannken@NetBSD.org
Responsible-Changed-When: Mon, 03 Nov 2008 17:23:44 +0000
Responsible-Changed-Why:
Take.
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/37425 (fsck on a system with snapshots resulted in panic...resolved after boot)
Date: Mon, 3 Nov 2008 18:29:46 +0100
There was much work on ffs internal snapshots over the last 1/2 year.
Please try again with a recent -current.
Thanks,
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 16 Nov 2008 09:38:27 +0000
State-Changed-Why:
Feedback was requested.
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Sun, 23 Nov 2008 09:15:29 -0800
The -current install kernel does not panic on boot, but it is still
unstable.
Running the same test as described in the initial pr on an installed
-current yields a panic, with the following backtrace (hand copied):
ffs_copyonwrite+0x9c
fscow_run+0xaf
ffs_alloccg+0xd9
ffs_hashalloc+0x2c
ffs_alloc+0x128
ffs_balloc_ufs1+0xcc4
ffs_balloc+0x69
expunge+0x322
ffs_snapshot+0x1091
VFS_SNAPSHOT+0x2f
ffs_ioctl+0x73a
VOP_IOCTL+0x6a
vn_ioctl+0x62
sys_ioctl+0x11e
syscall+0xab
So while there have been changes, it looks like FFS snapshots still
aren't playing nice when stressed.
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Mon, 24 Nov 2008 10:43:48 +0100
On Sun, Nov 23, 2008 at 07:45:02PM +0000, Scott Ellis wrote:
> The following reply was made to PR kern/37425; it has been noted by GNATS.
Please send the following information:
- The exact panic string above ffs_copyonwrite+0x9c
- The output of dmesg
- The script you use to test
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Mon, 24 Nov 2008 18:05:23 -0800
This is a multi-part message in MIME format.
--------------050807060401010309000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 11/24/2008 1:45 AM, Juergen Hannken-Illjes wrote:
> The following reply was made to PR kern/37425; it has been noted by GNATS.
>
> From: Juergen Hannken-Illjes<hannken@eis.cs.tu-bs.de>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
> Date: Mon, 24 Nov 2008 10:43:48 +0100
>
> On Sun, Nov 23, 2008 at 07:45:02PM +0000, Scott Ellis wrote:
> > The following reply was made to PR kern/37425; it has been noted by GNATS.
>
> Please send the following information:
>
> - The exact panic string above ffs_copyonwrite+0x9c
> - The output of dmesg
> - The script you use to test
>
> --
> Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
>
Sure thing.
The panic string is:
uvm_fault(0xffffffff80bf58c0, 0xffff800005ef4000, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff80286987 cs 8 rflags 10206 cr2
ffff800005ef4e00 cpl 0 rsp ffff8000023cac040
kernel: page trap fault, code=0
Stopped in pid 361.1 (fssconfig) at netbsd:ffs_copyonwrite+0x9c: movq 0
(%rdi,%rax,8),%rax
Script used to test is attached (yes, it's a hack, but it was quick to
write!) as pffstest.pl. It requires the directory structure of
/.snapshot/.store to be created, and vnd 11-14 to be available.
Dmesg is attached as vmware.dmesg. It's GENERIC running on VMware.
Don't imagine there's much machine-specific stuff there.
--------------050807060401010309000309
Content-Type: text/plain;
name="pffstest.pl"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="pffstest.pl"
#!/usr/bin/perl
# Use vnd?? starting at $startvnode, to eliminate conflicts with other
# vnd users on the system
$startvnode=10;
$snapshotdir="/.snapshot";
$snapshotstore="/.snapshot/.store";
$datetime=`date "+%C%y.%m.%d-%H.%M.%S"`;
chomp($datetime);
# Number of generations of backups that should be kept
$generations=5;
fill_vnd();
fill_store();
# If all the vnd are free, use them up!
# Assume this only happens after a fresh reboot
if (scalar(keys %vnd) <= 1)
{
freshstart();
exit(10);
}
rotate();
# Take new snapshot, and attach it to a vnode
if ($vnd{""})
{
$newfile=$snapshotstore."/".$datetime;
# Make a new store file
exec(`fssconfig -c fss0 / $newfile`);
exec(`fssconfig -u fss0`);
# Attach it to the vnode
exec(`vnconfig -r $vnd{""} $newfile`);
# Make a directory and mount it
$newdir=$snapshotdir."/".$datetime;
mkdir($newdir);
exec(`mount -o ro /dev/$vnd{""}a $newdir`);
}
else
{
print "Hey, no free vnodes!\n";
exit(20);
}
##################################################################
sub sort_store {
# Sort the list of files in %store in decending order
@inodesorted= reverse sort { $store{$a} cmp $store{$b} } keys %store;
}
sub fill_vnd {
# Populate vnd list with vnode devices
$i=$startvnode;
while ($i < ($startvnode+$generations))
{
@vntemp=split(" ",`vnconfig -l vnd$i`);
# Add hash entry with key of inode, value of associated vnode
chop($vntemp[0]);
$vnd{$vntemp[4]}=$vntemp[0];
$i++;
}
}
sub fill_store {
# Create list of all store files
@storelist=split('\n',`ls $snapshotstore`);
# Populate store list with list of filenames
$i=0;
while ($storelist[$i])
{
$tempfile=$snapshotstore."/".$storelist[$i];
$tempnode=`stat -f "%i" $tempfile`;
chomp($tempnode);
# Add hash entry with key of inode, value of associated filename
$store{$tempnode}=$tempfile;
$i++;
}
}
sub freshstart {
print "Empty vnd, populating\n";
$i=0;
while (($inode,$filename)=each(%store))
{
$tempvnode=$startvnode+$i;
exec(`vnconfig -r vnd$tempvnode $store{$inode}`);
$i++;
}
}
sub rotate {
# Sort the list of store files, so we can clear old ones out
sort_store();
# See if we need to remove any extra files
$i=0;
while ($currentinode = @inodesorted[$i])
{
if ($i >= ($generations-1))
{
# We have too many files...remove them
print "Removing ";
if ($vnd{$currentinode})
{
# Forcibly unmount it first
$dirname=$snapshotdir."/".`basename $store{$currentinode}`;
chomp($dirname);
exec(`umount -f $dirname`);
rmdir($dirname);
# Next, remove the vnode association
exec(`vnconfig -u $vnd{$currentinode}`);
# Mark this vnode as clear
$vnd{""}=$vnd{$currentinode};
}
unlink($store{$currentinode});
}
else
{
print "Keeping ";
}
print "File:".$store{@inodesorted[$i]}." ".$vnd{@inodesorted[$i]}."\n";
$i++;
}
}
--------------050807060401010309000309
Content-Type: text/plain;
name="vmware.dmesg"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="vmware.dmesg"
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.99.02 (GENERIC) #0: Mon Nov 17 20:41:39 PST 2008
scotte@intrepid:/nbu/source/netbsd/src/obj.amd64/nbu/source/netbsd/src/sys/arch/amd64/compile/GENERIC
total memory = 511 MB
avail memory = 481 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
SMBIOS rev. 2.4 @ 0xe4010 (45 entries)
VMware, Inc. VMware Virtual Platform (None)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel 686-class, 3600MHz, id 0x6fb
cpu1 at mainbus0 apid 1: Intel 686-class, 3600MHz, id 0x6fb
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 11, 24 pins
acpi0 at mainbus0: Intel ACPICA 20080321
acpi0: X/RSDT: OemId <INTEL ,440BX ,06040000>, AslId <VMW ,01324272>
acpi0: SCI interrupting at int 9
acpi0: fixed-feature power button present
timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
ACPI-Safe 24-bit timer
PIC (PNP0001) at acpi0 not configured
attimer1 at acpi0 (TIME, PNP0100): AT Timer
attimer1: io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800)
pcppi1: io 0x61
midi0 at pcppi1: PC speaker (CPU-intensive output)
sysbeep0 at pcppi1
pckbc1 at acpi0 (KBC, PNP0303): kbd port
pckbc1: io 0x60,0x64 irq 1
pckbc2 at acpi0 (MOUS, PNP0F13): aux port
pckbc2: irq 12
LPTB (PNP0400) at acpi0 not configured
COMA (PNP0501) at acpi0 not configured
COMB (PNP0501) at acpi0 not configured
FDC (PNP0700) at acpi0 not configured
acpiacad0 at acpi0 (ACAD, ACPI0003-1): ACPI AC Adapter
attimer1: attached to pcppi1
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pms0 at pckbc1 (aux slot)
pckbc1: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0
pchb0: vendor 0x8086 product 0x7190 (rev. 0x01)
ppb0 at pci0 dev 1 function 0: vendor 0x8086 product 0x7191 (rev. 0x01)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
pcib0 at pci0 dev 7 function 0
pcib0: vendor 0x8086 product 0x7110 (rev. 0x08)
piixide0 at pci0 dev 7 function 1
piixide0: Intel 82371AB IDE controller (PIIX4) (rev. 0x01)
piixide0: bus-master DMA support present
piixide0: primary channel configured to compatibility mode
piixide0: primary channel interrupting at ioapic0 pin 14
atabus0 at piixide0 channel 0
piixide0: secondary channel configured to compatibility mode
piixide0: secondary channel ignored (disabled)
piixpm0 at pci0 dev 7 function 3
piixpm0: vendor 0x8086 product 0x7113 (rev. 0x08)
timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 1000
piixpm0: 24-bit timer
piixpm0: SMBus disabled
vga0 at pci0 dev 15 function 0: vendor 0x15ad product 0x0405 (rev. 0x00)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
mpt0 at pci0 dev 16 function 0: vendor 0x1000 product 0x0030
mpt0: applying 1030 quirk
mpt0: interrupting at ioapic0 pin 17
scsibus0 at mpt0: 16 targets, 8 luns per target
ppb1 at pci0 dev 17 function 0: vendor 0x15ad product 0x0790 (rev. 0x02)
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
wm0 at pci2 dev 0 function 0: Intel i82545EM 1000BASE-T Ethernet, rev. 1
wm0: interrupting at ioapic0 pin 18
wm0: 32-bit 66MHz PCI bus
wm0: 256 word (8 address bits) MicroWire EEPROM
wm0: Ethernet address 00:0c:29:2b:56:65
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 3
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
isa0 at pcib0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
ERROR: 305 cycle TSC drift observed
acpiacad0: AC adapter online.
scsibus0: waiting 2 seconds for devices to settle...
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
atapibus0 at atabus0: 2 targets
cd0 at atapibus0 drive 1: <VMware Virtual IDE CDROM Drive, 0100000000000000000, 0000000> cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
wd0 at atabus0 drive 0: <VMware Virtual IDE Hard Drive>
wd0: drive supports 64-sector PIO transfers, LBA addressing
wd0: 2048 MB, 4161 cyl, 16 head, 63 sec, 512 bytes/sect x 4194304 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA)
cd0(piixide0:0:1): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA)
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio0 at pad0: half duplex
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
--------------050807060401010309000309--
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Tue, 25 Nov 2008 15:15:53 +0100
On Mon, Nov 24, 2008 at 06:05:23PM -0800, Scott Ellis wrote:
[snip]
> Script used to test is attached (yes, it's a hack, but it was quick to
> write!) as pffstest.pl. It requires the directory structure of
> /.snapshot/.store to be created, and vnd 11-14 to be available.
How should the /.snapshot/.store hierarchy look like?
> # Make a new store file
> exec(`fssconfig -c fss0 / $newfile`);
> exec(`fssconfig -u fss0`);
>
> # Attach it to the vnode
> exec(`vnconfig -r $vnd{""} $newfile`);
If I get this right you are trying to create a vnd device from the
snapshot backup. If this succeeds, there is a bug in the vnd driver.
Snapshot backups cannot be opened, read or written -- they can only
be accessed through /dev/{r,}fss{n}.
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Tue, 25 Nov 2008 17:40:50 -0800
On 11/25/2008 6:20 AM, Juergen Hannken-Illjes wrote:
> The following reply was made to PR kern/37425; it has been noted by GNATS.
>
> From: Juergen Hannken-Illjes<hannken@eis.cs.tu-bs.de>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
> Date: Tue, 25 Nov 2008 15:15:53 +0100
>
> On Mon, Nov 24, 2008 at 06:05:23PM -0800, Scott Ellis wrote:
> [snip]
> > Script used to test is attached (yes, it's a hack, but it was quick to
> > write!) as pffstest.pl. It requires the directory structure of
> > /.snapshot/.store to be created, and vnd 11-14 to be available.
>
> How should the /.snapshot/.store hierarchy look like?
I believe /.snapshot/.store/ will get populated with snapshot files (5
at a time?) with the filename of the date and time the snapshot was
taken. The script should automatically do that for you.
>
> > # Make a new store file
> > exec(`fssconfig -c fss0 / $newfile`);
> > exec(`fssconfig -u fss0`);
> >
> > # Attach it to the vnode
> > exec(`vnconfig -r $vnd{""} $newfile`);
>
> If I get this right you are trying to create a vnd device from the
> snapshot backup. If this succeeds, there is a bug in the vnd driver.
> Snapshot backups cannot be opened, read or written -- they can only
> be accessed through /dev/{r,}fss{n}.
It's been ages since I hacked together that script, but if memory
serves, the general logic is supposed to be something like:
1) Create snapshot #1
2) Attach vnd11 to snapshot #1 (using
"/.snapshot/.store/2008-11-25-whatever" as the vnd backing file)
3) Mount vnd11a (or whatever) as "/.snapshot/2008-11-25-whatever"
4) Create snapshot #2
5) Repeat steps 1-3 until vnd11-vnd14 are filled snapshots #1 through #4
6) umount and unconfigure vnd11/snapshot #1
7) Free the snapshot #1
8) Perform steps 1-3 (so that snapshot #1 is now the most recent snapshot)
9) Repeat steps 6-8 with the oldest snapshot, loop forever
The gist is that I tried to always have 4 snapshots configured and
mounted (via vnd). As soon as all 4 are used, the oldest one is removed
and a new snapshot is taken.
In my quick test, creating /.snapshots/.store/ and running the script
twice gave the panic (the first time through it just created the first
.store/foo file I believe...to get the process started).
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Wed, 26 Nov 2008 10:06:25 +0100
On Wed, Nov 26, 2008 at 03:30:04AM +0000, Scott Ellis wrote:
[snip]
> > How should the /.snapshot/.store hierarchy look like?
>
> I believe /.snapshot/.store/ will get populated with snapshot files (5
> at a time?) with the filename of the date and time the snapshot was
> taken. The script should automatically do that for you.
Nope.
$ mkdir -p /.snapshot/.store
$ perl pffstest.pl
Empty vnd, populating
$ find /.snapshot -print0 | xargs -0 ls -ldo
drwxr-xr-x 3 root wheel - 512 Nov 26 10:53 /.snapshot
drwxr-xr-x 2 root wheel - 512 Nov 26 10:53 /.snapshot/.store
All fss and vnd devices are unconfigured. So I tried to create a snapshot:
$ fssconfig -c fss0 / /.snapshot/.store/TEST
$ perl pffstest.pl
Empty vnd, populating
vnconfig: /.snapshot/.store/TEST: Operation not permitted
As I noted before you cannot (any more) vnconfig a snapshot backup. You
always have to use the fss device. So
$ vnconfig -r vndX /.../SNAPBACKUP
$ mount -o ro /dev/vndXa /NEWDIR
should become
$ fssconfig -c fssX / /.../SNAPBACKUP
$ mount -o ro /dev/fssX /NEWDIR
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Wed, 03 Dec 2008 18:42:52 -0800
Juergen Hannken-Illjes wrote:
>
> As I noted before you cannot (any more) vnconfig a snapshot backup. You
> always have to use the fss device. So
>
> $ vnconfig -r vndX /.../SNAPBACKUP
> $ mount -o ro /dev/vndXa /NEWDIR
>
> should become
>
> $ fssconfig -c fssX / /.../SNAPBACKUP
> $ mount -o ro /dev/fssX /NEWDIR
>
Thanks. Now your earlier statement makes sense. :-) I'll adjust (or
rewrite, since I no longer remember how it is really supposed to work)
the script to use /dev/fssX rather than the vnode devices and make a new
PR if that exhibits problems.
Should we keep this PR to track that it crashes with the vndX device
(and I can try and hack together something which more clearly exhibits
the issue), or should we close this one and I'll make a new one to track
the "vnd shouldn't work" issue?
From: Juergen Hannken-Illjes <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/37425 CVS commit: src/sys/ufs/ffs
Date: Sun, 7 Dec 2008 10:01:10 +0000 (UTC)
Module Name: src
Committed By: hannken
Date: Sun Dec 7 10:01:10 UTC 2008
Modified Files:
src/sys/ufs/ffs: ffs_snapshot.c
Log Message:
ffs_copyonwrite(): Only use si_snapblklist if it is already allocated.
ffs_snapshot_read(): Allow the kernel to read beyond file system size.
Persistent snapshots work again.
Should fix PR kern/37425: fss_snapshot_mount panic during fsck.
To generate a diff of this commit:
cvs rdiff -r1.84 -r1.85 src/sys/ufs/ffs/ffs_snapshot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Juergen Hannken-Illjes <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/37425 CVS commit: src/sys/ufs/ffs
Date: Sun, 7 Dec 2008 18:55:58 +0000 (UTC)
Module Name: src
Committed By: hannken
Date: Sun Dec 7 18:55:58 UTC 2008
Modified Files:
src/sys/ufs/ffs: ffs_snapshot.c
Log Message:
Revert previous -- ALL reads are from kernel space.
Still open: PR kern/37425: fss_snapshot_mount panic during fsck.
To generate a diff of this commit:
cvs rdiff -r1.85 -r1.86 src/sys/ufs/ffs/ffs_snapshot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Juergen Hannken-Illjes <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/37425 CVS commit: src/sys/ufs/ffs
Date: Sun, 7 Dec 2008 19:51:07 +0000 (UTC)
Module Name: src
Committed By: hannken
Date: Sun Dec 7 19:51:07 UTC 2008
Modified Files:
src/sys/ufs/ffs: ffs_snapshot.c
Log Message:
ffs_copyonwrite(): Only use si_snapblklist if it is already allocated.
ffs_snapshot_read(): Use IO_ALTSEMANTICS to allow reading a snapshot vnode
beyond file system size. Needed to read the snapblklist
on mount.
Persistent snapshots work again.
Should fix PR kern/37425: fss_snapshot_mount panic during fsck.
To generate a diff of this commit:
cvs rdiff -r1.86 -r1.87 src/sys/ufs/ffs/ffs_snapshot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/37425 CVS commit: [netbsd-5] src/sys/ufs/ffs
Date: Wed, 10 Dec 2008 21:49:32 +0000 (UTC)
Module Name: src
Committed By: snj
Date: Wed Dec 10 21:49:31 UTC 2008
Modified Files:
src/sys/ufs/ffs [netbsd-5]: ffs_snapshot.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #169):
sys/ufs/ffs/ffs_snapshot.c: revision 1.87
ffs_copyonwrite(): Only use si_snapblklist if it is already allocated.
ffs_snapshot_read(): Use IO_ALTSEMANTICS to allow reading a snapshot vnode
beyond file system size. Needed to read the snapblklist
on mount.
Persistent snapshots work again.
Should fix PR kern/37425: fss_snapshot_mount panic during fsck.
To generate a diff of this commit:
cvs rdiff -r1.82 -r1.82.4.1 src/sys/ufs/ffs/ffs_snapshot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/37425 CVS commit: [netbsd-5] src/sys/ufs/ffs
Date: Thu, 11 Dec 2008 11:55:17 +0100
A fix has been committed to -current and pulled up to NetBSD-5.
Ok to close this PR ?
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Scott Ellis <scotte@warped.com>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/37425: fss_snapshot_mount panic during fsck
Date: Sun, 14 Dec 2008 08:02:47 -0800
I vote it's okay to close.
State-Changed-From-To: feedback->closed
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Tue, 16 Dec 2008 09:56:42 +0000
State-Changed-Why:
Fixed in tree, pulled up to NetBSD-5 and closed on submitters request.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home