6.2 w/ gjournal missing gjournal binary
I built a machine with 6.2 snapshot from April (May/June would not boot). I used the original src with the gjournal patch. I had to manually patch mount.h and vnode.h to complete the patch. everything built and installed fine and my gjournal seems to be working (gjournal loaded and gstats confirm I'm using the journal device). However I just noticed I have no gjournal binary to do my status. I copied a binary from a working 6.2S host running gjournal and the binary seg faults on this host. How can I build just the binary? -- ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildkernel failure
thanks. I cvs'd this morning and manually did the patch and finally got built and running 6.2S now on to my real problem.. next post. ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com pluknet wrote the following on 08/04/07 07:03: On 04/08/07, Kevin Kramer <[EMAIL PROTECTED]> wrote: ok, thanks. I have made that change and now I've gotten this /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_mountfs': /usr/src/sys/ufs/ffs/ffs_vfsops.c:675: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:677: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:687: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:688: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:696: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:865: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:866: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:867: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_unmount': /usr/src/sys/ufs/ffs/ffs_vfsops.c:1028: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1029: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1030: error: structure has no member named `mnt_gjprovider' *** Error code 1 I've searched the threads and found nothing so far relevant. Things are changed also a bit in src/sys/sys/mount.h with v1.197.2.7 since that patch was prepared, so it fails to apply against releng_6 cleanly. You can apply this manually to fix the build: @@ -178,6 +178,7 @@ int mnt_secondary_accwrites;/* (i) secondary wr. starts */ int mnt_ref;/* (i) Reference count */ int mnt_gen;/* struct mount generation */ + char*mnt_gjprovider;/* gjournal provider name */ }; struct vnode *__mnt_vnode_next(struct vnode **mvp, struct mount *mp); wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildkernel failure
ok, thanks. I have made that change and now I've gotten this /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_mountfs': /usr/src/sys/ufs/ffs/ffs_vfsops.c:675: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:677: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:687: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:688: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:696: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:865: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:866: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:867: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_unmount': /usr/src/sys/ufs/ffs/ffs_vfsops.c:1028: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1029: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1030: error: structure has no member named `mnt_gjprovider' *** Error code 1 I've searched the threads and found nothing so far relevant. pluknet wrote the following on 08/01/07 17:22: On 01/08/07, Kevin Kramer <[EMAIL PROTECTED]> wrote: I have a host that is running 6.2-PRERELEASE from Dec 14 2006. I'm trying to update it to 6.2 Stable. I've got the latest sources as of this morning. I'm also using gjournal so I've added the patch for that. The buildworld completed successfully, now I'm getting this when trying to buildkernel. /usr/src/sys/kern/vfs_subr.c: In function `vn_printf': /usr/src/sys/kern/vfs_subr.c:2551: error: `VV_DELETED' undeclared (first use in this function) /usr/src/sys/kern/vfs_subr.c:2551: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/vfs_subr.c:2551: error: for each function it appears in.) *** Error code 1 I'm using GENERIC and have only added these lines and I moved my original /usr/src before cvs'ing. options SMP options UFS_GJOURNAL Thanks for any help. It was discussed: http://lists.freebsd.org/pipermail/freebsd-stable/2007-February/032985.html wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildkernel failure
I have a host that is running 6.2-PRERELEASE from Dec 14 2006. I'm trying to update it to 6.2 Stable. I've got the latest sources as of this morning. I'm also using gjournal so I've added the patch for that. The buildworld completed successfully, now I'm getting this when trying to buildkernel. /usr/src/sys/kern/vfs_subr.c: In function `vn_printf': /usr/src/sys/kern/vfs_subr.c:2551: error: `VV_DELETED' undeclared (first use in this function) /usr/src/sys/kern/vfs_subr.c:2551: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/vfs_subr.c:2551: error: for each function it appears in.) *** Error code 1 I'm using GENERIC and have only added these lines and I moved my original /usr/src before cvs'ing. options SMP options UFS_GJOURNAL Thanks for any help. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated RELE6?
I have booted it into FC3 using 2.6.18 kernel. here is the dmesg and scanpci -v output tg3.c:v3.65 (August 07, 2006) ACPI: PCI Interrupt :04:00.0[A] -> GSI 17 (level, low) -> IRQ 177 PCI: Setting latency timer of device :04:00.0 to 64 eth0: Tigon3 [partno(BCM95754) rev b002 PHY(5787)] (PCI Express) 10/100/1000Base T Ethernet 00:13:72:25:67:ec eth0: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[1] TSOcap[1] eth0: dma_rwctrl[7618] dma_mask[64-bit] pci bus 0x0004 cardnum 0x00 function 0x00: vendor 0x14e4 device 0x167a Broadcom Corporation Device unknown CardVendor 0x1028 card 0x01de (Card unknown) STATUS0x0010 COMMAND 0x0006 CLASS 0x02 0x00 0x00 REVISION 0x02 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x10 BASE0 0xeddf0004 addr 0xeddf MEM 64BIT MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0a -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Brian A. Seklecki wrote the following on 10/23/06 11:18: Kevin: Maybe you can get a punter on linux-poweredge@ lists to do "scanpci -v" or "lspci" or whatever to get the IDs. ~BAS On Wed, 18 Oct 2006, Scott Long wrote: Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Sorry, I thought that you and others were working on numerous Broadcom issues including incorrect recognition of the chipsets for the Poweredge 1950's and Precision 390. You had been responding to most of the threads regarding Broadcom issues. ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/18/06 10:26: Kevin Kramer wrote: and will it support the BCM5754 in the Precision 390? No idea, ask the vendor. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
and will it support the BCM5754 in the Precision 390? -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Conrad Burger wrote the following on 10/18/06 04:58: Hi It looks like there is a "new" version of the bce driver in HEAD. When will it be incorporated into Releng_6? We are currently having some performance problems with a java application on our Dell 1950s. And it looks like it has something to do with the speed with which network I/Os are performed. We have Dell 2850s running FreeBSD 5.4/i386 SMP. With Intel nics (em) and they are performing quite well. With 34000 tcp sockets open the maximum time it takes to perform a single network I/O is about 100ms. The Dell 1950s running FreeBSD 6.2-Prerelease/i386 SMP with Broadcom nics (bce), the same application and 34000 tcp connections open. The maximum time it takes to perform a single network I/O is about 7000ms. Most of the packets the systems send/receive are rather small. We are not quite sure what could cause this behavior. If anyone has any ideas of what we could do to decrease the time it takes to perform network I/O it would be much appreciated. Regards Conrad Some information: dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x1028 subdevice=0x01b3 class=0x02 dev.bce.0.%parent: pci9 dev.bce.0.driver_version: v0.9.6 dev.bce.0.stat_IfHcInOctets: 2346165 dev.bce.0.stat_IfHCInBadOctets: 1877825702 dev.bce.0.stat_IfHCOutOctets: 2751390538 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 360078711 dev.bce.0.stat_IfHCInMulticastPkts: 18339 dev.bce.0.stat_IfHCInBroadcastPkts: 270544 dev.bce.0.stat_IfHCOutUcastPkts: 323261730 dev.bce.0.stat_IfHCOutMulticastPkts: 147410 dev.bce.0.stat_IfHCOutBroadcastPkts: 985 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFraes: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOverrsizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 44671171 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 166377250 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 125306581 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 11502851 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 3372657 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 9137084 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.0.stat_EtherStatsPktsTx64Octets: 12605056 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 208798776 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 82452517 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 8532515 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 3204492 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 7816769 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 4933702 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 0 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 # vmstat -i interrupt total rate irq14: ata0 47 0 irq16: bce0 bce1548968755 1086 irq21: uhci0 uhci+ 5 0 irq78: mfi0343548 0 cpu0: timer 998576924 1976 cpu1: timer1008301350 1995 cpu3: timer1008469139 1995 cpu2: timer 995126109 1969 Total 4559785877 9023 # uname -a FreeBSD niobium.mxit.co.za 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Oct 10 13:28:54 SAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MXIT-SMP-I386 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe
Re: bce issues still outstanding
There is no line for EISA in the GENERIC config file, nor can I find it in device.hints. The markings on the chip say it is a BCM5754, but it's being recognized as BCM5787. I currently have the machine at the db> prompt if someone can walk me through getting valuable information. -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/12/06 08:05: Yeah, the error is probably a PCI error coming from the chipset, not a RAM error. Unfortunately, there are a lot of mystery reasons why a PCI error might get triggered, and the message isn't enough to say what exactly it is. However, one simple test you can to is to disable the EISA device in the kernel if you still have it in there. Scott Kevin Kramer wrote: I'll try that, but we received a response from David C. and few weeks ago (on another thread) that the BCE driver should be picking up this NIC. The latest 6.1 stable does not panic with the NIC disabled in the BIOS. Gleb Smirnoff wrote: Kevin, On Wed, Oct 11, 2006 at 11:21:27AM -0500, Kevin Kramer wrote: K> here is a picture of a panic i get on a Dell Precision 390 booting K> 6.2-beta2_amd64. hope this helps. K> K> http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg Well, although the message above is about bge(4) identified, the panic says that the CPU received NMI due to RAM parity error. Have you tried replacing the RAM? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bce issues still outstanding
I'll try that, but we received a response from David C. and few weeks ago (on another thread) that the BCE driver should be picking up this NIC. The latest 6.1 stable does not panic with the NIC disabled in the BIOS. Gleb Smirnoff wrote: Kevin, On Wed, Oct 11, 2006 at 11:21:27AM -0500, Kevin Kramer wrote: K> here is a picture of a panic i get on a Dell Precision 390 booting K> 6.2-beta2_amd64. hope this helps. K> K> http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg Well, although the message above is about bge(4) identified, the panic says that the CPU received NMI due to RAM parity error. Have you tried replacing the RAM? -- Kevin Kramer Sr. Systems Administrator Centaur Technology, Inc. 512.418.5725 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bce issues still outstanding
here is a picture of a panic i get on a Dell Precision 390 booting 6.2-beta2_amd64. hope this helps. http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/11/06 10:11: Bill Moran wrote: I've copied many of the people who I've been working with directly on this issue. Can anyone provide a status update on these problems? Discussion seems to have stopped since Oct 5. Any new patches to test? I'm actively working on fixing the driver right now. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell Precision 390 issues (heads-up)
Well, I've cvs'd this morning and rebuilt world and kernel and the Broadcom nic driver still panics the machine. The device is identified as BCM5787 and immediately after it loads the kernel gives RAM Parity Error some other suff like a trace panic , non-maskable interrupt trap it now shows 6.2-pre-release as the version. what can i do to help fix this and maybe get this into 6.2. thanks Kevin Kramer wrote the following on 09/14/06 09:46: We have one of these new boxes. The latest ISOs for i386/AMD64 install fails with a RAM Parity error if the onboard Broadcom NIC is enabled in the BIOS. To get past this error just disable in the bios to get past. I'll repost after I do a source update to see if the Broadcom is supported. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dell Precision 390 issues (heads-up)
We have one of these new boxes. The latest ISOs for i386/AMD64 install fails with a RAM Parity error if the onboard Broadcom NIC is enabled in the BIOS. To get past this error just disable in the bios to get past. I'll repost after I do a source update to see if the Broadcom is supported. -- ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal questions
it's working great now that i've redone the whole thing ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Pawel Jakub Dawidek wrote the following on 09/01/06 13:56: On Fri, Sep 01, 2006 at 10:16:09AM -0500, Kevin Kramer wrote: I've already redone the whole thing. here are the steps i took umount /scr09 umount /scr10 gjournal stop da2.journal gjournal stop da4.journal ** had not done this on the first attempt newfs /dev/da1 newfs /dev/da3 This is not needed. gjournal label -v /dev/da2 /dev/da1 gjournal label -v /dev/da4 /dev/da3 newfs -J -L scr09 /dev/da2.journal newfs -J -L scr10 /dev/da4.journal mount /scr09 mount /scr10 Don't know how your /etc/fstab looks like, but you definiately should use 'async' mount option, which is safe to use with gjournaled file systems. it is looking much better so far. before, i was getting this in the debug (only on /scr10) and my mountd process was always the top process Sep 1 00:00:11 donkey kernel: fsync: giving up on dirty Sep 1 00:00:11 donkey kernel: 0xc9ee1bb0: tag devfs, type VCHR Sep 1 00:00:11 donkey kernel: usecount 1, writecount 0, refcount 198 mountedher e 0xc9ebfb00 Sep 1 00:00:11 donkey kernel: flags () Sep 1 00:00:11 donkey kernel: v_object 0xc9fbb528 ref 0 pages 5933 Sep 1 00:00:11 donkey kernel: lock type devfs: EXCL (count 1) by thread 0xc9bd4 180 (pid 38) Sep 1 00:00:11 donkey kernel: dev ufs/scr10 Sep 1 00:00:11 donkey kernel: GEOM_JOURNAL: Cannot suspend file system /scr10 ( error=35). It happens sometimes under load, haven't investigated yet what exactly is happening, but you can ignore it for now, it's harmless, it just means journal switch will be done a bit later. BTW. 8GB for journals is much. You should not need more than 2GB probably. Of course it will work with 8GB just fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal questions
i was seeing up to 14s suspends on /scr10 prior to the reconfig causing mount point to be unresponsive on the clients. i'm using async option also. the rsync is still going so won't go live again 'til next week. thanks for the help. ------ Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Pawel Jakub Dawidek wrote the following on 09/01/06 13:56: On Fri, Sep 01, 2006 at 10:16:09AM -0500, Kevin Kramer wrote: I've already redone the whole thing. here are the steps i took umount /scr09 umount /scr10 gjournal stop da2.journal gjournal stop da4.journal ** had not done this on the first attempt newfs /dev/da1 newfs /dev/da3 This is not needed. gjournal label -v /dev/da2 /dev/da1 gjournal label -v /dev/da4 /dev/da3 newfs -J -L scr09 /dev/da2.journal newfs -J -L scr10 /dev/da4.journal mount /scr09 mount /scr10 Don't know how your /etc/fstab looks like, but you definiately should use 'async' mount option, which is safe to use with gjournaled file systems. it is looking much better so far. before, i was getting this in the debug (only on /scr10) and my mountd process was always the top process Sep 1 00:00:11 donkey kernel: fsync: giving up on dirty Sep 1 00:00:11 donkey kernel: 0xc9ee1bb0: tag devfs, type VCHR Sep 1 00:00:11 donkey kernel: usecount 1, writecount 0, refcount 198 mountedher e 0xc9ebfb00 Sep 1 00:00:11 donkey kernel: flags () Sep 1 00:00:11 donkey kernel: v_object 0xc9fbb528 ref 0 pages 5933 Sep 1 00:00:11 donkey kernel: lock type devfs: EXCL (count 1) by thread 0xc9bd4 180 (pid 38) Sep 1 00:00:11 donkey kernel: dev ufs/scr10 Sep 1 00:00:11 donkey kernel: GEOM_JOURNAL: Cannot suspend file system /scr10 ( error=35). It happens sometimes under load, haven't investigated yet what exactly is happening, but you can ignore it for now, it's harmless, it just means journal switch will be done a bit later. BTW. 8GB for journals is much. You should not need more than 2GB probably. Of course it will work with 8GB just fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal questions
I've already redone the whole thing. here are the steps i took umount /scr09 umount /scr10 gjournal stop da2.journal gjournal stop da4.journal ** had not done this on the first attempt newfs /dev/da1 newfs /dev/da3 gjournal label -v /dev/da2 /dev/da1 gjournal label -v /dev/da4 /dev/da3 newfs -J -L scr09 /dev/da2.journal newfs -J -L scr10 /dev/da4.journal mount /scr09 mount /scr10 it is looking much better so far. before, i was getting this in the debug (only on /scr10) and my mountd process was always the top process Sep 1 00:00:11 donkey kernel: fsync: giving up on dirty Sep 1 00:00:11 donkey kernel: 0xc9ee1bb0: tag devfs, type VCHR Sep 1 00:00:11 donkey kernel: usecount 1, writecount 0, refcount 198 mountedher e 0xc9ebfb00 Sep 1 00:00:11 donkey kernel: flags () Sep 1 00:00:11 donkey kernel: v_object 0xc9fbb528 ref 0 pages 5933 Sep 1 00:00:11 donkey kernel: lock type devfs: EXCL (count 1) by thread 0xc9bd4 180 (pid 38) Sep 1 00:00:11 donkey kernel: dev ufs/scr10 Sep 1 00:00:11 donkey kernel: GEOM_JOURNAL: Cannot suspend file system /scr10 ( error=35). but now i'm getting clean journal writes, while i'm rsyncing the data back. i don't have any real clients yet so i'll enable that after the rsync is completed. Sep 1 10:00:36 donkey kernel: GEOM_JOURNAL[1]: Starting copy of journal. Sep 1 10:00:36 donkey kernel: GEOM_JOURNAL[1]: Switch time of da4: 0.002327s Sep 1 10:00:36 donkey kernel: GEOM_JOURNAL[1]: Entire switch time: 0.011674s Sep 1 10:00:36 donkey kernel: GEOM_JOURNAL[1]: Data has been copied. Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Msync time of /scr09: 0.08s Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Sync time of /scr09: 0.31s Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Suspend time of /scr09: 0.94 s Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Starting copy of journal. Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Switch time of da2: 0.002425s Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Entire switch time: 0.003477s Sep 1 10:00:46 donkey kernel: GEOM_JOURNAL[1]: Data has been copied. Sep 1 10:00:56 donkey kernel: GEOM_JOURNAL[1]: Entire switch time: 0.14s Sep 1 10:01:06 donkey kernel: GEOM_JOURNAL[1]: Entire switch time: 0.14s Sep 1 10:01:16 donkey kernel: GEOM_JOURNAL[1]: Msync time of /scr10: 0.002388s Sep 1 10:01:16 donkey kernel: GEOM_JOURNAL[1]: Sync time of /scr10: 0.002748s Sep 1 10:01:16 donkey kernel: GEOM_JOURNAL[1]: Suspend time of /scr10: 0.002751 s ---------- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Pawel Jakub Dawidek wrote the following on 09/01/06 09:59: On Fri, Sep 01, 2006 at 08:12:23AM -0500, Kevin Kramer wrote: we left the journaling devices raw. do i need to newfs the journaling device? is eveything else ok besides the newfs of the daX.journal? Journal switch times are very long, but this could be caused by SU. Could you try to disable SU and turn on gjournal? Without "renewfsing" you could do on an unmounted file system: # tunefs -n disable -J enable /dev/daX.journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal questions
we left the journaling devices raw. do i need to newfs the journaling device? is eveything else ok besides the newfs of the daX.journal? -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Pawel Jakub Dawidek wrote the following on 09/01/06 06:16: On Thu, Aug 31, 2006 at 02:01:34PM -0500, Kevin Kramer wrote: Pavel, running 6.1-stable with these patches rebuilt kernel/world as of 8/28 @ 2p CST w/ these patches gjournal6_20060808.patch vfs_subr.c.3.patch the backend RAID presents 4 luns, this is how we config'd it. da1 - 8G da2 - ~897G da3 - 8G da4 - ~897G da2/4 have been partitioned in FreeBSD, then we did the following gjournal label -v /dev/da2 /dev/da1 gjournal label -v /dev/da4 /dev/da3 newfs -U -L "scr09" /dev/da2.journal newfs -U -L "scr10" /dev/da4.journal so 1 -8 G journal for each data device. Hmm, using SU with gjournal is really bad choice and you didn't tell file system that it is on gjournaled device. Try: # newfs -J -L scr0X /dev/daX.journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gjournal questions
still trying Aug 31 13:56:44 b-204-38 kernel: nfs: server donkey OK Aug 31 13:56:44 bowltest3 kernel: nfs: server donkey not responding, still trying Aug 31 13:56:46 b-210-17 kernel: nfs: server donkey OK Aug 31 13:56:46 laybox17 kernel: nfs: server donkey OK are the journal devices not large enough? is there a formula for sizing? sorry this is long. can i umount the data device, remove journaling and mount as a regular device? what are those steps? thanks and sorry for the long-winded posting.. -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
