Hi,
After praying in Tongues I rebooted again :-)
Data is back safe!
Is there something special about the re boot just after a core dump?
Just wondering why this didn't come up straight the first time
Backup3 464G 182G 282G 39% /Backup3
/Backup3/pfs/@@-1:00002 464G 182G 282G 39% /Backup3/mysql-baks
/Backup3/pfs/@@-1:00001 464G 182G 282G 39% /Backup3/VM-Backup
/Backup3/pfs/@@-1:00003 464G 182G 282G 39% /Backup3/svn-baks
/Backup3/pfs/@@-1:00004 464G 182G 282G 39% /Backup3/software
/Backup3/pfs/@@-1:00005 464G 182G 282G 39% /Backup3/Data
v# pwd
/Backup3/mysql-baks/agsrv
# undo -i 2011-11-11-all.sql.bz2
2011-11-11-all.sql.bz2: ITERATE ENTIRE HISTORY
0x000000010a549b40 11-Nov-2011 18:30:45
earlier it was
> # undo -i 2011-11-11-all.sql.bz2
> 2011-11-11-all.sql.bz2: ITERATE ENTIRE HISTORY: Inappropriate ioctl for device
Could some one give the explanation?
Thanks :-)
--Siju
On Mon, Nov 14, 2011 at 1:01 PM, Siju George <sgeorge...@gmail.com> wrote:
> I had these many PFSes on the hammer volume /Backup3
>
>
> /Backup3/pfs/mysql-baks /Backup3/mysql-baks null rw 0
> 0/Backup3/pfs/VM-Backup /Backup3/VM-Backup null rw 00
> /Backup3/pfs/svn-baks /Backup3/svn-baks null rw 0
> 0/Backup3/pfs/software /Backup3/software null rw 0 0/Backup3/pfs/Data
> /Backup3/Data null rw 0 0
>
> The /Backup3/pfs Directory is missing completely
>
> None of these are mounted
>
> BUT
>
> Two of these PFSes are available as directories.
>
> # pwd
> /Backup3
> # ls -l
> total 4
> drwxr-xr-x 5 root wheel 512 Dec 13 2010 mysql-baks
> drwxr-xr-x 3 root wheel 512 Jan 7 2011 svn-baks
>
>
> # pwd
> /Backup3/mysql-baks/agsrv
> # undo -i 2011-11-11-all.sql.bz2
> 2011-11-11-all.sql.bz2: ITERATE ENTIRE HISTORY: Inappropriate ioctl for device
>
> Thanks :-)
>
> --Siju
>
>
>
> On Mon, Nov 14, 2011 at 10:16 AM, Siju George <sgeorge...@gmail.com> wrote:
>> Hi,
>>
>> Hammer Core Dumped on My v2.13.0.154.g481b38-DEVELOPMENT.
>>
>> I have uploaded the core dump to
>> leaf:/home/sgeorge/crash/Coredump20111114.tbz
>> Files are
>>
>> Coredump20111114/
>> Coredump20111114/kern.2
>> Coredump20111114/info.2
>> Coredump20111114/vmcore.2
>> Coredump20111114/bounds
>> Coredump20111114/core.txt.2
>>
>>
>> However the system is up and running after a reboot.
>>
>> Would this have affected the file system?
>>
>> Should I try a latest src or wait till I hear from you?
>>
>> This kernel did run fine for many days though
>>
>>
>> DragonFly dfly-bkpsrv.hifxnx.local 2.13-DEVELOPMENT DragonFly
>> v2.13.0.154.g481b38-DEVELOPMENT #2: Mon Oct 31 14:21:57 IST 2011
>> root@dfly-bkpsrv.hifxnx.local:/usr/obj/Backup1/src/sys/GENERIC i386
>>
>>
>> Thanks
>>
>> --Siju
>>
>> The messsage is
>>
>> =========
>>
>> HAMMER(Backup3) recovery undo 300000000bc4d788-300000000bc502c0
>> (11064 bytes)(RW)
>> ad8: FAILURE - WRITE_DMA48 status=51<READY,DSC,ERROR> error=4<ABORTED>
>> LBA=890156672
>> HAMMER(): Critical error inode=-1 error=5 while flushing meta-data
>> HAMMER(): Forcing read-only mode
>> ad8: FAILURE - WRITE_DMA48 status=51<READY,DSC,ERROR> error=4<ABORTED>
>> LBA=890935168
>> HAMMER(): Critical error inode=-1 error=5 while flushing meta-data
>> panic: assertion "hammer_oneref(&buffer->io.lock)" failed in
>> hammer_recover_flush_buffer_callback at
>> /Backup1/src/sys/vfs/hammer/hammer_recover.c:1525
>> cpuid = 0
>> Trace beginning at frame 0xdcfde8b8
>> panic(ffffffff,0,c06c7328,dcfde8ec,d8329de0) at panic+0x198
>> panic(c06c7328,c070a3d0,c0678c60,c070a3a0,5f5) at panic+0x198
>> hammer_recover_flush_buffer_callback(dcf701c8,dcfde968,0,0,dcf70138)
>> at hammer_recover_flush_buffer_callback+0xe7
>> hammer_buf_rb_tree_RB_SCAN(dd09a034,c054fb9f,c0556ff7,dcfde968,dd09a034)
>> at hammer_buf_rb_tree_RB_SCAN+0xc0
>> hammer_recover_flush_buffers(dd09a000,c72ec310,1,0,0) at
>> hammer_recover_flush_buffers+0x71
>> hammer_recover_stage1(dd09a000,c72ec310,280,0,dcfde9fc) at
>> hammer_recover_stage1+0x857
>> hammer_vfs_mount(d832eb60,bfbffc13,bfbff948,d7310bd0,d832ed80) at
>> hammer_vfs_mount+0xb6c
>> vfs_mount(d832eb60,bfbffc13,bfbff948,d7310bd0,bfbff924) at vfs_mount+0x52
>> sys_mount(dcfdecf0,dcfded00,10,dcfe24b8,0) at sys_mount+0x712
>> syscall2(dcfded40) at syscall2+0x26f
>> Xint0x80_syscall() at Xint0x80_syscall+0x36
>> Debugger("panic")
>>
>> CPU0 stopping CPUs: 0x00000000
>> stopped
>> Physical memory: 3541 MB
>> Dumping 169 MB: 154 138 122 106 90 74 58 42 26 10
>> ======================================
>>
>
