Lost all Data
Hi, I dont Know when this actually happened today or yesterday. After the Update I found that the pfss on my Master and Slave mirror are completely missing. I cannot point out to anything except upgrade because nothing happens on the system except upgrade that is of administration status. mount -a gives mount -a hammer: No such file or directory hammer: No such file or directory mount: /Backup1/Data: No such file or directory My master pfs was /Backup1/pfs/Data mounted using /Backup1/pfs/Data /Backup1/Data null rw 0 0 And Slave pfs was /Backup2/pfs/Data Both pfs folders are missing. # cd /Backup1 # undo -i pfs pfs: ITERATE ENTIRE HISTORY: Unknown error: 0 # cd /Backup2 # ls # undo -i pfs pfs: ITERATE ENTIRE HISTORY: Unknown error: 0 Any Idea how to get the data back? From /var/log/messages #cat /var/log/messages Aug 3 14:00:00 dfly-bkpsrv newsyslog[879]: logfile turned over due to size100K Aug 5 13:56:19 dfly-bkpsrv kernel: arp: 172.16.50.52 moved from 00:01:6c:c6:8a:ab to 00:11:11:9c:3d:51 on re0 Aug 5 14:10:38 dfly-bkpsrv kernel: arp: 172.16.50.52 moved from 00:11:11:9c:3d:51 to 00:11:95:dd:26:05 on re0 Aug 10 08:01:43 dfly-bkpsrv syslogd: kernel boot file is /boot/kernel Aug 10 08:01:43 dfly-bkpsrv kernel: Copyright (c) 2003-2009 The DragonFly Project. Aug 10 08:01:43 dfly-bkpsrv kernel: Copyright (c) 1992-2003 The FreeBSD Project. Aug 10 08:01:43 dfly-bkpsrv kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 10 08:01:43 dfly-bkpsrv kernel: The Regents of the University of California. All rights reserved. Aug 10 08:01:43 dfly-bkpsrv kernel: DragonFly 2.3.2-DEVELOPMENT #3: Thu Jul 30 12:51:03 IST 2009 Aug 10 08:01:43 dfly-bkpsrv kernel: r...@dfly-bkpsrv.hifxchn2.local:/usr/obj/usr/src/sys/GENERIC Aug 10 08:01:43 dfly-bkpsrv kernel: TSC clock: 2193631958 Hz, i8254 clock: 1193191 Hz Aug 10 08:01:43 dfly-bkpsrv kernel: CPU: AMD Athlon(tm) 64 Processor 3400+ (2193.63-MHz 686-class CPU) Aug 10 08:01:43 dfly-bkpsrv kernel: Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Aug 10 08:01:43 dfly-bkpsrv kernel: Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Aug 10 08:01:43 dfly-bkpsrv kernel: Features2=0x1SSE3 Aug 10 08:01:43 dfly-bkpsrv kernel: AMD Features=0xe050NX,AMIE,LM,DSP,3DNow! Aug 10 08:01:43 dfly-bkpsrv kernel: real memory = 1039990784 (1015616K bytes) Aug 10 08:01:43 dfly-bkpsrv kernel: avail memory = 995622912 (972288K bytes) Aug 10 08:01:43 dfly-bkpsrv kernel: Preloaded elf kernel /boot/kernel at 0xc080d000. Aug 10 08:01:43 dfly-bkpsrv kernel: Preloaded elf module /boot/modules/acpi.ko at 0xc080d1f0. Aug 10 08:01:43 dfly-bkpsrv kernel: Pentium Pro MTRR support enabled Aug 10 08:01:43 dfly-bkpsrv kernel: md0: Malloc disk Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: RSDP @ 0x0xf96f0/0x0014 (v 0 ACPIAM) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: RSDT @ 0x0x3dfd/0x0034 (v 1 A M I OEMRSDT 0x01000624 MSFT 0x0097) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: FACP @ 0x0x3dfd0200/0x0084 (v 2 A M I OEMFACP 0x01000624 MSFT 0x0097) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: DSDT @ 0x0x3dfd0430/0x3A74 (v 1 1ABZR 1ABZRB49 0x0B49 INTL 0x02002026) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: FACS @ 0x0x3dfde000/0x0040 Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: APIC @ 0x0x3dfd0390/0x005C (v 1 A M I OEMAPIC 0x01000624 MSFT 0x0097) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: MCFG @ 0x0x3dfd03f0/0x003C (v 1 A M I OEMMCFG 0x01000624 MSFT 0x0097) Aug 10 08:01:43 dfly-bkpsrv kernel: ACPI: OEMB @ 0x0x3dfde040/0x0056 (v 1 A M I AMI_OEM 0x01000624 MSFT 0x0097) Aug 10 08:01:43 dfly-bkpsrv kernel: sched_ithd: stray interrupt 7 on cpu 0 Aug 10 08:01:43 dfly-bkpsrv kernel: npx0: math processor on motherboard Aug 10 08:01:43 dfly-bkpsrv kernel: npx0: INT 16 interface Aug 10 08:01:43 dfly-bkpsrv kernel: Using XMM optimized bcopy/copyin/copyout Aug 10 08:01:43 dfly-bkpsrv kernel: acpi0: A M I OEMRSDT on motherboard Aug 10 08:01:43 dfly-bkpsrv kernel: acpi0: Power Button (fixed) Aug 10 08:01:43 dfly-bkpsrv kernel: Warning: ACPI is disabling APM's device. You can't run both Aug 10 08:01:43 dfly-bkpsrv kernel: acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: cpu0: ACPI CPU on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: cpu_cst0: ACPI CPU C-State on cpu0 Aug 10 08:01:43 dfly-bkpsrv kernel: acpi_button0: Power Button on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: sio0: configured irq 3 not in bitmap of probed irqs 0 Aug 10 08:01:43 dfly-bkpsrv kernel: sio0 port 0x2f8-0x2ff irq 3 on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: sio0: type 16550A Aug 10 08:01:43 dfly-bkpsrv kernel: fdc0: NEC 72065B or clone port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: ppc0 port 0x378-0x37f irq 7 on acpi0 Aug 10 08:01:43 dfly-bkpsrv kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE
Re: Lost all Data
Siju George wrote: Hi, I dont Know when this actually happened today or yesterday. After the Update I found that the pfss on my Master and Slave mirror are completely missing. I cannot point out to anything except upgrade because nothing happens on the system except upgrade that is of administration status. mount -a gives mount -a hammer: No such file or directory hammer: No such file or directory mount: /Backup1/Data: No such file or directory My master pfs was /Backup1/pfs/Data mounted using /Backup1/pfs/Data /Backup1/Datanullrw 0 0 And Slave pfs was /Backup2/pfs/Data Both pfs folders are missing. # cd /Backup1 # undo -i pfs pfs: ITERATE ENTIRE HISTORY: Unknown error: 0 undo does not work on directories, try hammer history Any Idea how to get the data back? it doesn't seem that /Backup1 or /Backup2 are mounted. Did maybe your device numbers change and mount can not find the file systems? What happens if you try to mount them manually? cheers simon
Re: Lost all Data
Siju George wrote: h: 955801585 20971520unused# 466699.993MB ^^ this is flagged unused. change it to read HAMMER. do that by running disklabel -e h: 955801585 20971520unused# 466699.993MB same here. cheers simon
Re: Lost all Data
On Tue, Aug 11, 2009 at 8:03 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: Siju George wrote: h: 955801585 20971520 unused # 466699.993MB ^^ this is flagged unused. change it to read HAMMER. do that by running disklabel -e h: 955801585 20971520 unused # 466699.993MB same here. Initially when I put hammer there it didnt mount so I put unused there so that it will mount. I seem to miss /dev/ad4s1h and /dev/ad6s1h in my /dev. Shouldn't i make them? thanks Siju
Re: Lost all Data
Siju George wrote: On Tue, Aug 11, 2009 at 8:03 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: Siju George wrote: h: 955801585 20971520unused# 466699.993MB ^^ this is flagged unused. change it to read HAMMER. do that by running disklabel -e h: 955801585 20971520unused# 466699.993MB same here. Initially when I put hammer there it didnt mount so I put unused there so that it will mount. I seem to miss /dev/ad4s1h and /dev/ad6s1h in my /dev. Shouldn't i make them? that's my point. give the slices a proper type in disklabel, then they will appear (devfs). cheers simon
Re: Lost all Data
On Tue, Aug 11, 2009 at 8:14 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: that's my point. give the slices a proper type in disklabel, then they will appear (devfs). disklabel says line 29: Warning, unknown filesystem type hammer and the disklabel shows unused still :-( I changed disklabels to # disklabel /dev/ad4s1 # /dev/ad4s1: type: unknown disk: amnesiac label: fictitious flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 128 sectors/cylinder: 8064 cylinders: 121127 sectors/unit: 976773105 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 16 partitions: # size offsetfstype a:2097152 04.2BSD#1024.000MB b:20971522097152 swap#1024.000MB c: 976773105 0unused# 476939.993MB d:209715241943044.2BSD#1024.000MB e:209715262914564.2BSD#1024.000MB f: 1048576083886084.2BSD#5120.000MB g:2097152 188743684.2BSD#1024.000MB h: 955801585 20971520unused# 466699.993MB
Re: Lost all Data
On Tue, Aug 11, 2009 at 7:30 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: undo does not work on directories, try hammer history How do I do that? Any Idea how to get the data back? it doesn't seem that /Backup1 or /Backup2 are mounted. Did maybe your device numbers change and mount can not find the file systems? What happens if you try to mount them manually? This was my original fstab # cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1d /home ufs rw 2 2 /dev/ad4s1e /tmpufs rw 2 2 /dev/ad4s1f /usrufs rw 2 2 /dev/ad4s1g /varufs rw 2 2 /dev/ad4s1b noneswapsw 0 0 proc/proc procfs rw 0 0 # #Hammer Partitions - ad4s1h has master pfs, ad6s1h has slave pfs /dev/ad4s1h /Backup1hammer rw 2 2 /dev/ad6s1h /Backup2hammer rw 2 2 #pfs null_mount /Backup1/pfs/Data /Backup1/Datanullrw 0 0 ## #2nd Disk partitions mounted for chroot### /dev/ad6s1a /mnt/2ndDiskufs rw 1 1 /dev/ad6s1d/mnt/2ndDisk/homeufs rw 2 2 /dev/ad6s1e/mnt/2ndDisk/tmp ufs rw 2 2 /dev/ad6s1f/mnt/2ndDisk/usr ufs rw 2 2 /dev/ad6s1g/mnt/2ndDisk/var ufs rw 2 2 /dev/ad6s1b noneswapsw 0 0 this is my current disklabels # disklabel /dev/ad4s1 # /dev/ad4s1: type: unknown disk: amnesiac label: fictitious flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 128 sectors/cylinder: 8064 cylinders: 121127 sectors/unit: 976773105 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 16 partitions: # size offsetfstype a:2097152 04.2BSD#1024.000MB b:20971522097152 swap#1024.000MB c: 976773105 0unused# 476939.993MB d:209715241943044.2BSD#1024.000MB e:209715262914564.2BSD#1024.000MB f: 1048576083886084.2BSD#5120.000MB g:2097152 188743684.2BSD#1024.000MB h: 955801585 20971520unused# 466699.993MB dfly-bkpsrv# mount /dev/ad4s1h /Backup1 mount: /dev/ad4s1h: No such file or directory # disklabel /dev/ad6s1 # /dev/ad6s1: type: unknown disk: amnesiac label: fictitious flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 128 sectors/cylinder: 8064 cylinders: 121127 sectors/unit: 976773105 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 16 partitions: # size offsetfstype a:2097152 04.2BSD#1024.000MB b:20971522097152 swap#1024.000MB c: 976773105 0unused# 476939.993MB d:209715241943044.2BSD#1024.000MB e:209715262914564.2BSD#1024.000MB f: 1048576083886084.2BSD#5120.000MB g:2097152 188743684.2BSD#1024.000MB h: 955801585 20971520unused# 466699.993MB # mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad4s1d on /home (ufs, local, soft-updates) /dev/ad4s1e on /tmp (ufs, local, soft-updates) /dev/ad4s1f on /usr (ufs, local, soft-updates) /dev/ad4s1g on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) # mount -a hammer: No such file or directory hammer: No such file or directory mount: /Backup1/Data: No such file or directory Trying manual mount # mount /dev/ad4s1h /Backup1 mount: /dev/ad4s1h: No such file or directory # mount /dev/ad6s1h /Backup2 mount: /dev/ad6s1h: No such file or directory My original set up is here. http://www.mail-archive.com/users@crater.dragonflybsd.org/msg08919.html Thanks for the quick response :-) Hope the Data is still in there and it is a matter of making the device file /dev/ad4s1h and ad6s1h :-) --Siju
Re: Lost all Data
On Tue, Aug 11, 2009 at 8:12 PM, Sascha Wildners...@online.de wrote: Siju George schrieb: Hope the Data is still in there and it is a matter of making the device file /dev/ad4s1h and ad6s1h :-) Are these GPT related partitions? No they are not GPT To what did you upgrade? And when? I upgraded today morning to 2.3.2-DEVELOPMENT DragonFly 2.3.2-DEVELOPMENT #6: Tue Aug 11 18:03:58 IST 2009 r...@dfly-bkpsrv.hifxchn2.local:/usr/obj/usr/src/sys/GENERIC i386 Can you try upgrading again or are the disks crucial for that? No I can upgrade again. but it will take a few hours to compile, Should i do that now? What disk devices do you have in /dev? # ls /dev acd0ad6 bpf cuaia0 lpt0 random ttyp0 ttyv9 tun2 acpiad6s1 bpf0cuala0 lpt0.ctlserno ttyv0 ttyva tun3 ad4 ad6s1a bpf1devctl md0 stderr ttyv1 ttyvb urandom ad4s1 ad6s1b bpf2devfs mem stdin ttyv2 ttyvc usb ad4s1a ad6s1d bpf3fd null stdout ttyv3 ttyvd usb0 ad4s1b ad6s1e bpsm0 io pass0 sysmousettyv4 ttyve usb1 ad4s1d ad6s1f cd0 kbd0pci tty ttyv5 ttyvf xpt0 ad4s1e ad6s1g console klogppi0 ttyd0 ttyv6 tun zero ad4s1f apm consolectl kmempsm0 ttyid0 ttyv7 tun0 ad4s1g ata cuaa0 log ptyp0 ttyld0 ttyv8 tun1 Also i found that the directories I used to mount partitions from the second disk is missing :-( thanks Siju
Re: Lost all Data
Siju George schrieb: Hope the Data is still in there and it is a matter of making the device file /dev/ad4s1h and ad6s1h :-) Are these GPT related partitions? To what did you upgrade? And when? Can you try upgrading again or are the disks crucial for that? What disk devices do you have in /dev? Regards, Sascha -- http://yoyodyne.ath.cx
Re: Lost all Data
Siju George schrieb: disklabel says line 29: Warning, unknown filesystem type hammer and the disklabel shows unused still :-( Does HAMMER (uppercase) work? Sascha -- http://yoyodyne.ath.cx
Re: Lost all Data
Siju George wrote: On Tue, Aug 11, 2009 at 8:14 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: that's my point. give the slices a proper type in disklabel, then they will appear (devfs). disklabel says line 29: Warning, unknown filesystem type hammer as i wrote before, use HAMMER (yes, not intuitive.) cheers simon
Re: Lost all Data
: line 29: Warning, unknown filesystem type hammer : :as i wrote before, use HAMMER (yes, not intuitive.) : :cheers : simon The lower/upper case problem has caught more then a few people. I will change the lookups in the disklabel code to use strcasecmp(). I have also noticed that the NATA driver seems to have changed disk designations in the upgrade, and I don't know why. Siju's main issue seemed to be from calling the partitions unused. I think in that case we need to change DEVFS to actually make the partitions available in /dev, even though they should have properly been set to HAMMER. Alex or I will look into it. -Matt Matthew Dillon dil...@backplane.com
Re: Lost all Data
On Tue, Aug 11, 2009 at 9:45 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: as i wrote before, use HAMMER (yes, not intuitive.) Yes it worked Now i have all data :-)) but my /dev on the second disk has more files than /dev on the first disk. I have updated the base system on the second disk also using chroot . Is it because i have not booted from the second disk after the upgade? for comparision. /dev on the first disk # ls /dev acd0ad6s1a bpf3klograndom ttyv2 ttyvf acpiad6s1b bpsm0 kmemserno ttyv3 tun ad4 ad6s1d cd0 log stderr ttyv4 tun0 ad4s1 ad6s1e console lpt0stdin ttyv5 tun1 ad4s1a ad6s1f consolectl lpt0.ctlstdout ttyv6 tun2 ad4s1b ad6s1g cuaa0 md0 sysmouse ttyv7 tun3 ad4s1d ad6s1h cuaia0 mem tty ttyv8 urandom ad4s1e apm cuala0 nullttyd0 ttyv9 usb ad4s1f ata devctl pass0 ttyid0 ttyva usb0 ad4s1g bpf devfs pci ttyld0 ttyvb usb1 ad4s1h bpf0fd ppi0ttyp0 ttyvc xpt0 ad6 bpf1io psm0ttyv0 ttyvd zero ad6s1 bpf2kbd0ptyp0 ttyv1 ttyve /dev on the second disk # ls /mnt/2ndDisk/dev/ acd0ad6s2 ccd2s1 da13s4 da6s0a fd1s2 twed0s1e acd0a ad6s3 ccd2s1a da14da6s0b fd1s3 twed0s1f acd0c ad6s4 ccd2s1b da14s0 da6s0c fd1s4 twed0s1g acd0s0 ad7 ccd2s1c da14s0a da6s0d fw0 twed0s1h acpiad7s0 ccd2s1d da14s0b da6s0e fw0.0 twed0s1i ad0 ad7s0a ccd2s1e da14s0c da6s0f fw0.1 twed0s1j ad0s0 ad7s0b ccd2s1f da14s0d da6s0g fw0.2 twed0s1k ad0s0a ad7s0c ccd2s1g da14s0e da6s0h fw0.3 twed0s1l ad0s0b ad7s0d ccd2s1h da14s0f da6s0i fwmem0 twed0s1m ad0s0c ad7s0e ccd2s1i da14s0g da6s0j fwmem0.0twed0s1n ad0s0d ad7s0f ccd2s1j da14s0h da6s0k fwmem0.1twed0s1o ad0s0e ad7s0g ccd2s1k da14s0i da6s0l fwmem0.2twed0s1p ad0s0f ad7s0h ccd2s1l da14s0j da6s0m fwmem0.3twed0s2 ad0s0g ad7s0i ccd2s1m da14s0k da6s0n i4b twed0s3 ad0s0h ad7s0j ccd2s1n da14s0l da6s0o i4bctl twed0s4 ad0s0i ad7s0k ccd2s1o da14s0m da6s0p i4brbch0ucom0 ad0s0j ad7s0l ccd2s1p da14s0n da6s1 i4brbch1ucom1 ad0s0k ad7s0m ccd2s2 da14s0o da6s1a i4btel0 ucom2 ad0s0l ad7s0n ccd2s3 da14s0p da6s1b i4btel1 ucom3 ad0s0m ad7s0o ccd2s4 da14s1 da6s1c i4bteld0ugen0 ad0s0n ad7s0p ccd3da14s1a da6s1d i4bteld1ugen0.1 ad0s0o ad7s1 ccd3s0 da14s1b da6s1e i4btrc0 ugen0.10 ad0s0p ad7s1a ccd3s0a da14s1c da6s1f i4btrc1 ugen0.11 ad0s1 ad7s1b ccd3s0b da14s1d da6s1g iic0ugen0.12 ad0s1a ad7s1c ccd3s0c da14s1e da6s1h iic1ugen0.13 ad0s1b ad7s1d ccd3s0d da14s1f da6s1i io ugen0.14 ad0s1c ad7s1e ccd3s0e da14s1g da6s1j ipauth ugen0.15 ad0s1d ad7s1f ccd3s0f da14s1h da6s1k ipl ugen0.2 ad0s1e ad7s1g ccd3s0g da14s1i da6s1l ipnat ugen0.3 ad0s1f ad7s1h ccd3s0h da14s1j da6s1m ipsd0 ugen0.4 ad0s1g
Re: Lost all Data
That's because on one you have devfs mounted and on the other one you don't. Sincerely, Alex Hornung 2009/8/11 Siju George sgeorge...@gmail.com: On Tue, Aug 11, 2009 at 9:45 PM, Simon 'corecode' Schubertcorec...@fs.ei.tum.de wrote: as i wrote before, use HAMMER (yes, not intuitive.) Yes it worked Now i have all data :-)) but my /dev on the second disk has more files than /dev on the first disk. I have updated the base system on the second disk also using chroot . Is it because i have not booted from the second disk after the upgade? for comparision. /dev on the first disk # ls /dev acd0 ad6s1a bpf3 klog random ttyv2 ttyvf acpi ad6s1b bpsm0 kmem serno ttyv3 tun ad4 ad6s1d cd0 log stderr ttyv4 tun0 ad4s1 ad6s1e console lpt0 stdin ttyv5 tun1 ad4s1a ad6s1f consolectl lpt0.ctl stdout ttyv6 tun2 ad4s1b ad6s1g cuaa0 md0 sysmouse ttyv7 tun3 ad4s1d ad6s1h cuaia0 mem tty ttyv8 urandom ad4s1e apm cuala0 null ttyd0 ttyv9 usb ad4s1f ata devctl pass0 ttyid0 ttyva usb0 ad4s1g bpf devfs pci ttyld0 ttyvb usb1 ad4s1h bpf0 fd ppi0 ttyp0 ttyvc xpt0 ad6 bpf1 io psm0 ttyv0 ttyvd zero ad6s1 bpf2 kbd0 ptyp0 ttyv1 ttyve /dev on the second disk # ls /mnt/2ndDisk/dev/ acd0 ad6s2 ccd2s1 da13s4 da6s0a fd1s2 twed0s1e acd0a ad6s3 ccd2s1a da14 da6s0b fd1s3 twed0s1f acd0c ad6s4 ccd2s1b da14s0 da6s0c fd1s4 twed0s1g acd0s0 ad7 ccd2s1c da14s0a da6s0d fw0 twed0s1h acpi ad7s0 ccd2s1d da14s0b da6s0e fw0.0 twed0s1i ad0 ad7s0a ccd2s1e da14s0c da6s0f fw0.1 twed0s1j ad0s0 ad7s0b ccd2s1f da14s0d da6s0g fw0.2 twed0s1k ad0s0a ad7s0c ccd2s1g da14s0e da6s0h fw0.3 twed0s1l ad0s0b ad7s0d ccd2s1h da14s0f da6s0i fwmem0 twed0s1m ad0s0c ad7s0e ccd2s1i da14s0g da6s0j fwmem0.0 twed0s1n ad0s0d ad7s0f ccd2s1j da14s0h da6s0k fwmem0.1 twed0s1o ad0s0e ad7s0g ccd2s1k da14s0i da6s0l fwmem0.2 twed0s1p ad0s0f ad7s0h ccd2s1l da14s0j da6s0m fwmem0.3 twed0s2 ad0s0g ad7s0i ccd2s1m da14s0k da6s0n i4b twed0s3 ad0s0h ad7s0j ccd2s1n da14s0l da6s0o i4bctl twed0s4 ad0s0i ad7s0k ccd2s1o da14s0m da6s0p i4brbch0 ucom0 ad0s0j ad7s0l ccd2s1p da14s0n da6s1 i4brbch1 ucom1 ad0s0k ad7s0m ccd2s2 da14s0o da6s1a i4btel0 ucom2 ad0s0l ad7s0n ccd2s3 da14s0p da6s1b i4btel1 ucom3 ad0s0m ad7s0o ccd2s4 da14s1 da6s1c i4bteld0 ugen0 ad0s0n ad7s0p ccd3 da14s1a da6s1d i4bteld1 ugen0.1 ad0s0o ad7s1 ccd3s0 da14s1b da6s1e i4btrc0 ugen0.10 ad0s0p ad7s1a ccd3s0a da14s1c da6s1f i4btrc1 ugen0.11 ad0s1 ad7s1b ccd3s0b da14s1d da6s1g iic0 ugen0.12 ad0s1a ad7s1c ccd3s0c da14s1e da6s1h iic1 ugen0.13 ad0s1b ad7s1d ccd3s0d da14s1f da6s1i io ugen0.14 ad0s1c ad7s1e ccd3s0e da14s1g da6s1j ipauth ugen0.15 ad0s1d ad7s1f ccd3s0f da14s1h da6s1k
Re: Lost all Data
:but my /dev on the second disk has more files than /dev on the first disk. :I have updated the base system on the second disk also using chroot . :Is it because i have not booted from the second disk after the upgade? It's just because DEVFS is mounted on one and not mounted on the other. With DEVFS we no longer need anything in the dev directory since the DEVFS mount will simply overload it. An all-new installation of the system will leave the original /dev in the filesystem (prior to mounting DEVFS) empty. An upgrade leaves the original contents of /dev intact.. not because I want it to be intact (I'd rather delete it)... but because it is difficult to delete it on a live system since we can't unmount DEVFS. The only way to delete would be to do a localhost NFS export for /, mount it somewhere else, and then the original /dev would be exposed and accessible for deletion. So, simply put, you have DEVFS mounted on top of one filesystem but not on top of the other. The original contents of fs/dev is no longer relevant to the system now that we have DEVFS. If you want to mount DEVFS in both places you can do so with mount_devfs, or even mount_null. -Matt
got some strange vfsync messages about dirty buffer!
Hi! What does this kernel messages mean? Aug 11 19:27:05 kernel: Warning: vfsync_bp skipping dirty buffer 0xc2d52bec Aug 11 19:57:40 kernel: Warning: vfsync_bp skipping dirty buffer 0xc2ecb6a4 Aug 11 20:58:52 kernel: Warning: vfsync_bp skipping dirty buffer 0xc2c6c150 My machine is a eeepc900 with a ssd disk, can it be that the ssd is not that supported yet? I'm using UFS as filesystem, beacuse i read somewhere that Matt wrote we should't use HammerFS with filesystems under 40GB, this drive is on 16GB. And i wonder what this means too: ad2: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED ad2: 15391MB ASUS-PHISON SSD TST2.04P at ata1-master UDMA66 Thanks /Daniel
Re: got some strange vfsync messages about dirty buffer!
:Hi! : :What does this kernel messages mean? : :Aug 11 19:27:05 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2d52bec :Aug 11 19:57:40 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2ecb6a4 :Aug 11 20:58:52 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2c6c150 You can ignore these warnings. They typically occur under heavy I/O loads. The buffer will still be synced (eventually). :My machine is a eeepc900 with a ssd disk, can it be that the ssd is not :that supported yet? : :I'm using UFS as filesystem, beacuse i read somewhere that Matt wrote we :should't use HammerFS with filesystems under 40GB, this drive is on 16GB. : :And i wonder what this means too: : :ad2: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED :ad2: 15391MB ASUS-PHISON SSD TST2.04P at ata1-master UDMA66 : :Thanks : :/Daniel UFS is probably the best choice for a 16G drive. The SET_MULTI failures can probably be ignored. My guess is that the SSD simply does not support the command not surprising if it is a modern SATA drive. -Matt Matthew Dillon dil...@backplane.com
Re: got some strange vfsync messages about dirty buffer!
Matthew Dillon wrote: :Hi! : :What does this kernel messages mean? : :Aug 11 19:27:05 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2d52bec :Aug 11 19:57:40 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2ecb6a4 :Aug 11 20:58:52 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2c6c150 You can ignore these warnings. They typically occur under heavy I/O loads. The buffer will still be synced (eventually). :My machine is a eeepc900 with a ssd disk, can it be that the ssd is not :that supported yet? : :I'm using UFS as filesystem, beacuse i read somewhere that Matt wrote we :should't use HammerFS with filesystems under 40GB, this drive is on 16GB. : :And i wonder what this means too: : :ad2: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED :ad2: 15391MB ASUS-PHISON SSD TST2.04P at ata1-master UDMA66 : :Thanks : :/Daniel UFS is probably the best choice for a 16G drive. The SET_MULTI failures can probably be ignored. My guess is that the SSD simply does not support the command not surprising if it is a modern SATA drive. -Matt Matthew Dillon dil...@backplane.com Thank you for that, then i can ignore the SET_MULTI failures :D, Ok then i made a good choice of choosing UFS instead of Hammer beacuse my disk would run out of space pretty fast when hammer is pruning and cleaning up every night right? By the way do you know why i got these messages about vfsync messages about dirty buffer?
Re: HEADS UP - devfs integration update. iscsi now alpha.
Matthew Dillon schrieb: :Matt, do you think it's worth to even drive this one step further by :probing device slices for HAMMER (or other types of) filesystems, and :create devfs entries like /dev/hammer/fsid or /dev/hammer/volname.volno? : :This would, in case of HAMMER, make devtab kind of superfluous, despite :being very useful in general. : :Regards, : : Michael I think we have to be very careful when trying to identify drives by the data stored on them. Maintainance tasks such as someone, say, dd'ing a disk image, could blow in our faces from depending on it. Generally I agree that too much magic should be avoided. But I see one use case where it might be useful: Expanding or shrinking a HAMMER filesystem. Right now, all volumes have to be specified. If, after an expansion, you miss to add the new volume, you can easily render the box unbootable. What I imagine would still need to mount a filesystem explicitly, just that the volumes are determined automagically. Regards, Michael
Re: got some strange vfsync messages about dirty buffer!
Matthew Dillon wrote: :Hi! : :What does this kernel messages mean? : :Aug 11 19:27:05 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2d52bec :Aug 11 19:57:40 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2ecb6a4 :Aug 11 20:58:52 kernel: Warning: vfsync_bp skipping dirty buffer :0xc2c6c150 You can ignore these warnings. They typically occur under heavy I/O loads. The buffer will still be synced (eventually). :My machine is a eeepc900 with a ssd disk, can it be that the ssd is not :that supported yet? : :I'm using UFS as filesystem, beacuse i read somewhere that Matt wrote we :should't use HammerFS with filesystems under 40GB, this drive is on 16GB. : :And i wonder what this means too: : :ad2: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED :ad2: 15391MB ASUS-PHISON SSD TST2.04P at ata1-master UDMA66 : :Thanks : :/Daniel UFS is probably the best choice for a 16G drive. The SET_MULTI failures can probably be ignored. My guess is that the SSD simply does not support the command not surprising if it is a modern SATA drive. -Matt Matthew Dillon dil...@backplane.com Thank you for that, then i can ignore the SET_MULTI failures :D, Ok then i made a good choice of choosing UFS instead of Hammer beacuse my disk would run out of space pretty fast when hammer is pruning and cleaning up every night right? By the way do you know why i got these messages about vfsync messages about dirty buffer?
Re: got some strange vfsync messages about dirty buffer!
:Thank you for that, then i can ignore the SET_MULTI failures :D, Ok then :i made a good choice of choosing UFS instead of Hammer beacuse my disk :would run out of space pretty fast when hammer is pruning and cleaning :up every night right? Yes. Way too fast. :By the way do you know why i got these messages about vfsync messages :about dirty buffer? Those warnings are typically load related. They occur more often when the machine is under a heavier I/O load. It's strictly chance. -Matt Matthew Dillon dil...@backplane.com
Re: Lost all Data
On Tue, Aug 11, 2009 at 10:43 PM, Matthew Dillondil...@apollo.backplane.com If you want to mount DEVFS in both places you can do so with mount_devfs, or even mount_null. Thanks matt for the long explanation. :-) Currently I update the contents of the second disk by mounting it under /mnt/2ndDisk and chrooting to it. So in future upgrades when I chroot should devfs be mounted on /mnt/2ndDisk/dev inorder for buildworld and build kernel to suceed proprely? Thanks Siju
is hammer for us
I am a student doing fluid dynamics research. We generate a lot of data (close to 2TB a day). We are having scalability problems with NFS. We have 2 Linux servers with 64GB of RAM, and they are serving the files. We are constantly running into I/O bottle neck problems. Would hammer fix the scalability problems? TIA
Re: Lost all Data
:Thanks matt for the long explanation. :-) :Currently I update the contents of the second disk by mounting it :under /mnt/2ndDisk and chrooting to it. So in future upgrades when I :chroot should devfs be mounted on /mnt/2ndDisk/dev inorder for :buildworld and build kernel to suceed proprely? : :Thanks : :Siju Yes. The easiest way is to simply use 'mount_null /dev /mnt/2ndDisk/dev' after mounting the second disk. And, of course, to umount /mnt/2ndDisk/dev before umount /mnt/2ndDisk. Anything you chroot to will need its own devfs mount, either using mount_null of /dev onto the target dev or (more directly) mount_devfs on the target dev. -Matt Matthew Dillon dil...@backplane.com
Re: Lost all Data
On Wed, Aug 12, 2009 at 9:05 AM, Matthew Dillondil...@apollo.backplane.com Anything you chroot to will need its own devfs mount, either using mount_null of /dev onto the target dev or (more directly) mount_devfs on the target dev. Thanks matt :-) --Siju
Re: is hammer for us
The I/O bottleneck is coming from the disk subsystem and network. I was wondering if HAMMER can do parallel filesystem implementation similar to GPFS or Lustre. Also, the reads/writes are random access there is very little sequential streaming, but the files are large.Each file is around 30GB each On Tue, Aug 11, 2009 at 11:42 PM, Matthew Dillondil...@apollo.backplane.com wrote: :I am a student doing fluid dynamics research. We generate a lot of :data (close to 2TB a day). We are having scalability problems with :NFS. We have 2 Linux servers with 64GB of RAM, and they are serving :the files. : :We are constantly running into I/O bottle neck problems. Would hammer :fix the scalability problems? : :TIA If you are hitting an I/O bottleneck you need to determine where the bottleneck is. Is it in the actual accesses to the disk subsystem? Are the disks seeking randomly or accessing data linearly? Is the transfer rate acceptable? Is it the network? Is it the NFS implementation? Is it the underlying filesystem on the server? Are there parallelism issues? You need to find the answer to those questions before you can determine a solution. Serving large files typically does not create a filesystem bottleneck. i.e. any filesystem, even something like ZFS, should still be able to serve large linear files at the platter rate. Having a lot of ram only helps if there is some locality of reference in the data set. i.e. if the data set is much larger then available memory but there is no locality of reference and the disk drives are hitting their seek limits, no amount of ram will solve the problem. (DragonFly's 64 bit support isn't reliable yet, so DragonFly can't access that amount of ram right now anyhow). -Matt Matthew Dillon dil...@backplane.com
