Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
On 2009-Mar-25 07:21:37 -0500, "Jack L. Stone" wrote: >However, last month upon upon upgrading those servers from FBSD-6.3px >(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers >had a similar problem as the original poster while the other half did not. ... >the next day, and the next day, and the next day. (The servers that did >work fooled us and we found out about this issue on the others when the >overlaps appeared and drew our attention). That's when our work to try and >solve the issues started and went on for days. It's not clear to me whether all your servers have the problem and you only initially noticed it on some of them or some of your servers work and others dont. In the latter case, you are probably in a very good position to identify the problem since it is related to some difference between your servers. >We could only conclude that the problem was perhaps something with >hardeware, perhaps the way memory was handled in 7.0, but that is only a >guess. If you are talking about server-grade hardware (ECC RAM etc) then it's unlikely to be RAM corruption. About the only thing I can think of would be that if you have RAM above 4GB, you might be running foul of an address being truncated somewhere (particularly in a device driver). (The amd64 user memory map changed between 7.x and 8.x but I don't think there was any change between 6.x & 7.x). The pre-emption changes in 7.x and/or moving to an SMP host would seem to increase the probability of hitting the problem fixed in the patch mentioned later (kern/121684). -- Peter Jeremy pgpASB6IFkuVK.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape header type 1853384566)
On Thursday 26 March 2009 19:55:04 Peter Jeremy wrote: > On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor wrote: > >One other thing would be to make absolutely sure that your version of dump > > & restore are in sync, the are very machine/version dependent. > > Actually, they aren't - the archive format is very stable. (This is a > fairly important requirement - you don't want to suddenly be unable to > restore your backups after an upgrade). I can restore dumps made on > FreeBSD4.8/i386 and FreeBSD4.9/alpha on a FreeBSD-current/amd64 system > without problems. Hmm interesting.. I must confess I haven't had problems recently but I tend to use tar these days anyway since it's more portable. > It's possible that you might have problems with a backup made using a > very recent dump on a very old restore if you've used filesystem > features that didn't exist when that restore was built. Could be, too long ago to remember :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: support quality (Re: dump | restore fails: unknown tape header type 1853384566)
On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor wrote: >One other thing would be to make absolutely sure that your version of dump & >restore are in sync, the are very machine/version dependent. Actually, they aren't - the archive format is very stable. (This is a fairly important requirement - you don't want to suddenly be unable to restore your backups after an upgrade). I can restore dumps made on FreeBSD4.8/i386 and FreeBSD4.9/alpha on a FreeBSD-current/amd64 system without problems. It's possible that you might have problems with a backup made using a very recent dump on a very old restore if you've used filesystem features that didn't exist when that restore was built. -- Peter Jeremy pgpYbMnzATlVE.pgp Description: PGP signature
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On Thu, Mar 26, 2009 at 10:59:25AM +, John wrote: > Weongyo Jeong wrote: > > > Could you please test it with attached patch to fix a page fault? I > > don't know why bus_dma_tag_create() returns ENOMEM that it looks > > temporary. > > Hi, thanks for this, I'll try it when I get home tonight. Not all that > familiar with patching though. I guess I go to where malo.c is, patch > and recompile? > > or patch < patchfile (from anywhere?) > #cd /usr/src/sys/dev/malo #patch -p0 < /path/to/patch_malo_20090326_panic.diff And rebuild malo(4)/kernel. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Weongyo Jeong wrote: > Could you please test it with attached patch to fix a page fault? I > don't know why bus_dma_tag_create() returns ENOMEM that it looks > temporary. Hi, Seems the patch failed to apply: [r...@potato /usr/src/sys/dev/malo]# ls -la total 140 drwxr-xr-x2 root wheel512 Mar 26 11:17 . drwxr-xr-x 199 root wheel 3072 Mar 24 16:58 .. -rw-r--r--1 root wheel 8 May 4 2008 if_malo.c -rw-r--r--1 root wheel 19096 May 4 2008 if_malo.h -rw-r--r--1 root wheel 9625 Mar 26 11:14 if_malo_pci.c -rw-r--r--1 root wheel 22333 May 4 2008 if_malohal.c -rw-r--r--1 root wheel 8266 May 4 2008 if_malohal.h -rw-r--r--1 root wheel 3722 May 4 2008 if_maloioctl.h -rw-r--r--1 root wheel375 Mar 26 11:15 patch_malo_20090326_panic.diff [r...@potato /usr/src/sys/dev/malo]# patch < patch_malo_20090326_panic.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: if_malo_pci.c |=== |--- if_malo_pci.c (revision 187939) |+++ if_malo_pci.c (working copy) -- Patching file if_malo_pci.c using Plan A... Hunk #1 failed at 260. 1 out of 1 hunks failed--saving rejects to if_malo_pci.c.rej done thanks, -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Weongyo Jeong wrote: > Could you please test it with attached patch to fix a page fault? I > don't know why bus_dma_tag_create() returns ENOMEM that it looks > temporary. Hi, thanks for this, I'll try it when I get home tonight. Not all that familiar with patching though. I guess I go to where malo.c is, patch and recompile? or patch < patchfile (from anywhere?) btw I'm running amd64, I should have mentioned it earlier: FreeBSD 7.2-PRERELEASE #0: Thu Mar 26 01:02:54 GMT 2009 thanks -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote: >> Jack L Stone writes: > >>> I've been watching this thread with some interest since we've had some >>> similar problems with dump/restore which we use every morning via cron >>> scripts on a number of servers to produce bootable clones as part of our >>> backup program. Have been doing this for years and also never saw a problem >>> as most of you say. We prefer dump/restore for backups. > >>> However, last month upon upon upgrading those servers from FBSD-6.3px >>> (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers >>> had a similar problem as the original poster while the other half did not. >>> All of the servers (rackmounts) use the same (type) hardware. We spent many >>> hours trying to solve the problem with those that failed to dump/restore. >>> Also, searched for any others with the problem and only found a very few, >>> but without solutions to this issue. (Indeed, the only one was a reference >>> to any efforts to restore an older OS version which didn't apply here). > [snip] >>> SOLUTION >>> The "clones" are a very important pasrt of our backup program. Since the >>> dump side of the problems simply stuck and provided no error message at all >>> and the errors from any restores were not useful, our only solution was to >>> revert back to FBSD-6.3 on those servers with this issue and dump/restore >>> went back to working again. We left those that were working on FBSD-7.0-R >>> and they continue to work okay. > >I was seeing this same problem on all my 64-bit systems: FreeBSD-7 >dump would hang at a random point. Dump continues to work flawlessly >for me on FreeBSD-7/i386. > >I ran across this which includes a patch: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=121684 > >The kernel patch linked to there solved the problem for me, but I am >running many production systems and am unwilling to apply this patch >to -RELEASE every time there is a kernel update (I just use the >standard GENERIC kernel which I get via freebsd-update). I now live >without dump on amd64. Apparently this fix is waiting on some related >issue; and I will be very happy when it makes it to the officially >released kernel. > >plw > Thanks for the reply. Forgot to mention, our machines are all i386 with the problem -- so are the ones without the problem. Yes, I found that patch too and tried it on one of the servers -- no joy. Guess we'll continue to wait also for now. Maybe 7.2/i386or, until someone finds the solution since we're out of ideas and stuck with 6.3 in order to use dump that we have trusted. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 07:53 AM 3/26/2009, Jack L. Stone wrote: >>> SOLUTION >>> The "clones" are a very important pasrt of our backup program. Since the >>> dump side of the problems simply stuck and provided no error message at all >>> and the errors from any restores were not useful, our only solution was to >>> revert back to FBSD-6.3 on those servers with this issue and dump/restore >>> went back to working again. We left those that were working on FBSD-7.0-R >>> and they continue to work okay. > Thanks for the reply. Forgot to mention, our machines are all i386 with the problem -- so are the ones without the problem. Yes, I found that patch too and tried it on one of the servers -- no joy. Guess we'll continue to wait also for now. Maybe 7.2/i386or, until someone finds the solution since we're out of ideas and stuck with 6.3 in order to use dump that we have trusted. Hi, I didnt see it in the thread clearly, but did you try creating a dump without the -L... i.e. without snapshots enabled ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Hi, I followed this thread out of interest since I do not suffer from this error. But I wonder if truss could shed some light into this issue. If for example a dump hangs at 99%, it might be an idea to set up truss to trace the dump process. Yes, this will produce lots of output, but maybe it gives a hint as soon as dump hangs. Christian Walther ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 07:57 AM 3.26.2009 -0400, Mike Tancsa wrote: >> >>Thanks for the reply. Forgot to mention, our machines are all i386 with the >>problem -- so are the ones without the problem. >> >>Yes, I found that patch too and tried it on one of the servers -- no joy. >> >>Guess we'll continue to wait also for now. Maybe 7.2/i386or, until >>someone finds the solution since we're out of ideas and stuck with 6.3 in >>order to use dump that we have trusted. > > >Hi, > I didnt see it in the thread clearly, but did you try >creating a dump without the -L... i.e. without snapshots enabled ? > > ---Mike > Yes, but it's for running a dump on a (L)ive FS and just spits out warnings to that effect and has no effect on solving the problem(s). Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Pyun YongHyeon wrote: > #cd /usr/src/sys/dev/malo > #patch -p0 < /path/to/patch_malo_20090326_panic.diff > > And rebuild malo(4)/kernel. Ok thanks for that, I'll try again -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Pyun YongHyeon wrote: > #cd /usr/src/sys/dev/malo > #patch -p0 < /path/to/patch_malo_20090326_panic.diff > > And rebuild malo(4)/kernel. No luck I'm afraid: [r...@potato /usr/src/sys/dev/malo]# patch -p0 < patch_malo_20090326_panic.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: if_malo_pci.c |=== |--- if_malo_pci.c (revision 187939) |+++ if_malo_pci.c (working copy) -- Patching file if_malo_pci.c using Plan A... Hunk #1 failed at 260. 1 out of 1 hunks failed--saving rejects to if_malo_pci.c.rej done -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On 3/26/09, John wrote: > Weongyo Jeong wrote: > >> Could you please test it with attached patch to fix a page fault? I >> don't know why bus_dma_tag_create() returns ENOMEM that it looks >> temporary. > > Hi, > > Seems the patch failed to apply: Patch is so trivial and short that it can be applied manually. Are you sure that you use 7 STABLE sources and not CURRENT one? If patching failed, rebuilding module/kernel is pointless. -- Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Paul B. Mahol wrote: > > Patch is so trivial and short that it can be applied manually. > > Are you sure that you use 7 STABLE sources and not CURRENT one? I'm absolutely certain. Sources from the 25th March, make world and kernel the day after: [r...@potato ~]# uname -a FreeBSD potato.growveg.org 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Thu Mar 26 01:02:54 GMT 2009 r...@potato.growveg.org:/usr/src/sys/amd64/compile/POTATO amd64 [r...@potato ~]# my cvsupfile looks like this: *default host=cvsup.uk.freebsd.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_7 *default delete use-rel-suffix src-all doc-all *default tag=. ports-all > If patching failed, rebuilding module/kernel is pointless. agreed -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
remote debug over usb vs. old serial cable?
Hello, In the past I could catch a panic during boot via a serial cable connected to another computer. My new computer only has USB-ports and ethernet. What kind of cable do I need now to do remote debugging? The old computer also has usb, so I think the connection should be in that corner. They all run 7-STABLE. Cheers, Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: remote debug over usb vs. old serial cable?
On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote: > Hello, > > In the past I could catch a panic during boot via a serial cable connected > to another computer. > My new computer only has USB-ports and ethernet. What kind of cable do I > need now to do remote debugging? > The old computer also has usb, so I think the connection should be in that > corner. > They all run 7-STABLE. USB won't work for that purpose. It requires far too much kernel support to be useful after a panic. The same goes for ethernet. There exists support for debugging over firewire - see dcons(4), and over old-fashioned serial ports. If you don't have either of those you are probably out of luck as far as remote debugging is concerned. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 08:08 AM 3/26/2009, Jack L. Stone wrote: Yes, but it's for running a dump on a (L)ive FS and just spits out warnings to that effect and has no effect on solving the problem(s). Unless the filesystem is very busy, you will get your data backed up. If you have things like databases, I still would not trust snapshots. Better to use pg_dump or mysqldump or the app that comes with whatever DB you are using... When backing up things like / and /usr, I would hazard a guess that most things are not changing while the backup is running, at least they dont in my environments. I have never had a problem with things like /home and even /var or /mail which are changing quite a bit. We dont restore much in the course of our daily routine, but we have always been able to restore people's Maildir when they accidentally have deleted stuff and it all worked without issue over the years. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On 3/26/09, John wrote: > Paul B. Mahol wrote: > >> >> Patch is so trivial and short that it can be applied manually. >> >> Are you sure that you use 7 STABLE sources and not CURRENT one? > > I'm absolutely certain. Sources from the 25th March, make world and > kernel the day after: > > [r...@potato ~]# uname -a > FreeBSD potato.growveg.org 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Thu > Mar 26 01:02:54 GMT 2009 > r...@potato.growveg.org:/usr/src/sys/amd64/compile/POTATO amd64 > [r...@potato ~]# > > my cvsupfile looks like this: > > *default host=cvsup.uk.freebsd.org > *default base=/usr > *default prefix=/usr > *default release=cvs > *default tag=RELENG_7 > *default delete use-rel-suffix > src-all > doc-all > *default tag=. This is a contradiction, I think that in csup case "last rule wins" > ports-all > >> If patching failed, rebuilding module/kernel is pointless. > > agreed > > -- > John > -- Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> >Yes, but it's for running a dump on a (L)ive FS and just spits out warnings > >to that effect and has no effect on solving the problem(s). > > Unless the filesystem is very busy, you will get your data backed up. > If you have things like databases, I still would not trust > snapshots. Uh. If backuping up a live database from a snapshot is not trustworthy, either the snapshot facility is broken or the database is broken (i.e., not crash-safe to begin with). That said there are plenty of other reasos to use proper dump tools (data portability, confirming the ability to actually read all rows from a table, using a more often exercised code path and perhaps less likely to have edge case bugs, etc). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpcA9In9BSP8.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 10:01 AM 3/26/2009, Peter Schuller wrote: > > Unless the filesystem is very busy, you will get your data backed up. > If you have things like databases, I still would not trust > snapshots. Uh. If backuping up a live database from a snapshot is not trustworthy, either the snapshot facility is broken or the database is broken (i.e., not crash-safe to begin with). ... or the database is configured in a risky way... But judging by this thread, it seems dump with -L is indeed broken for some people. Hence, I suggested dumping the database using the database's backup tools and trying dump without -L ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Peter Schuller wrote: Yes, but it's for running a dump on a (L)ive FS and just spits out warnings to that effect and has no effect on solving the problem(s). Unless the filesystem is very busy, you will get your data backed up. If you have things like databases, I still would not trust snapshots. Uh. If backuping up a live database from a snapshot is not trustworthy, either the snapshot facility is broken or the database is broken (i.e., not crash-safe to begin with). That said there are plenty of other reasos to use proper dump tools (data portability, confirming the ability to actually read all rows from a table, using a more often exercised code path and perhaps less likely to have edge case bugs, etc). The issue with backing up a database live comes in when the filesystem where the database and transaction log files are DIFFERS. You can get into a pathological case in that instance. If the transaction log and database itself are both on the same snapshotted entity (that is, the snapshot is pulled at the same instant in time for both) what you get BETTER be restorable or your database's transaction log facility doesn't really do what it promises to do! -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: remote debug over usb vs. old serial cable?
on 26/03/2009 15:06 Erik Trulsson said the following: > On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote: >> Hello, >> >> In the past I could catch a panic during boot via a serial cable connected >> to another computer. >> My new computer only has USB-ports and ethernet. What kind of cable do I >> need now to do remote debugging? >> The old computer also has usb, so I think the connection should be in that >> corner. >> They all run 7-STABLE. > > USB won't work for that purpose. It requires far too much kernel support to > be useful after a panic. Erik, in fact, there is a special USB (EHCI) mode for such purposes: http://www.coreboot.org/EHCI_Debug_Port But that requires some special HW in addition to SW support which our doesn't have. BTW, Ronald, it is possible that you might have a serial header on motherboard which is not connected to any traditional port. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Paul B. Mahol wrote: > This is a contradiction, I think that in csup case "last rule wins" How come this builds a 7-STABLE system rather than -CURRENT ? In any case, I appreciate your comment and will take out the offending line. (it's in there because I thought ports was always HEAD) cheers -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: remote debug over usb vs. old serial cable?
On Thu, 26 Mar 2009 15:22:36 +0100, Andriy Gapon wrote: on 26/03/2009 15:06 Erik Trulsson said the following: On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote: Hello, In the past I could catch a panic during boot via a serial cable connected to another computer. My new computer only has USB-ports and ethernet. What kind of cable do I need now to do remote debugging? The old computer also has usb, so I think the connection should be in that corner. They all run 7-STABLE. USB won't work for that purpose. It requires far too much kernel support to be useful after a panic. Erik, in fact, there is a special USB (EHCI) mode for such purposes: http://www.coreboot.org/EHCI_Debug_Port But that requires some special HW in addition to SW support which our doesn't have. BTW, Ronald, it is possible that you might have a serial header on motherboard which is not connected to any traditional port. Is that this sio0 one? sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled I am going to open my computer tonight to see what is in there. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: remote debug over usb vs. old serial cable?
on 26/03/2009 16:33 Ronald Klop said the following: > Is that this sio0 one? > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > > I am going to open my computer tonight to see what is in there. I don't know. I think it's better to read your motherboard documentation, internal serial header is not an obvious one and you would need a special connector for it. The port can also be disabled in BIOS. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> ... or the database is configured in a risky way... But judging by > this thread, it seems dump with -L is indeed broken for some > people. Hence, I suggested dumping the database using the database's > backup tools and trying dump without -L Well, if dump -L is really broken I'd recommend just not using dump unless you absolutely have to. That is assuming snapshots are not broken so that you can still use mksnap_ffs with your favorite backup tool. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpK9HnrQBlRj.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> The issue with backing up a database live comes in when the filesystem > where the database and transaction log files are DIFFERS. You can get > into a pathological case in that instance. > > If the transaction log and database itself are both on the same > snapshotted entity (that is, the snapshot is pulled at the same instant > in time for both) what you get BETTER be restorable or your database's > transaction log facility doesn't really do what it promises to do! Absolutely. Doing things like snapshot based backups of databases assumes you know what you're doing since it is not something which is documented as an official procedure in your typical database administrator guide. Personally, while I would use such schemes, I would always use a plain fully supported regular dump as a fallback position. I would only rely on snapshot based processes to do fancy stuff (such as near-realtime hot standby with zfs snaps + serialized incrementals). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpwtMtbjdvab.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Peter Schuller wrote: The issue with backing up a database live comes in when the filesystem where the database and transaction log files are DIFFERS. You can get into a pathological case in that instance. If the transaction log and database itself are both on the same snapshotted entity (that is, the snapshot is pulled at the same instant in time for both) what you get BETTER be restorable or your database's transaction log facility doesn't really do what it promises to do! Absolutely. Doing things like snapshot based backups of databases assumes you know what you're doing since it is not something which is documented as an official procedure in your typical database administrator guide. Personally, while I would use such schemes, I would always use a plain fully supported regular dump as a fallback position. I would only rely on snapshot based processes to do fancy stuff (such as near-realtime hot standby with zfs snaps + serialized incrementals). To add to this what SHOULD (ha!) work is to dump the database partition FIRST and THEN dump the Transaction Log partition. If you do it in the other order you WILL get screwed, as you will have transactions committed in the database that are not in the XLOG. That is essentially guaranteed to blow up in your face. As always any backup scheme has to be TESTED so you can prove to your own satisfaction that it is RESTORABLE. I can't tell you how many business clients I have run into (and not only on Unix machines) that have wind up with lots of backups and NONE of them can be restored - because they never TESTED their backup strategy. -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On 3/26/09, John wrote: > Paul B. Mahol wrote: > >> This is a contradiction, I think that in csup case "last rule wins" > > How come this builds a 7-STABLE system rather than -CURRENT ? > > In any case, I appreciate your comment and will take out the offending > line. (it's in there because I thought ports was always HEAD) from csup(1) Default settings may be specified in lines whose collection name is *default. Such defaults will apply to subsequent lines in the supfile. Multiple *default lines may be present. New values augment or override any defaults specified earlier in the supfile. Values specified explic- itly for a collection override any default values. This can be much simpler. Did you noticed kernel version when you booted new kernel (available via dmesg(8))? -- Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> To add to this what SHOULD (ha!) work is to dump the database partition > FIRST and THEN dump the Transaction Log partition. Depending on how the database works; specifically when old data in the log may or may not be expunged. You could do this with PostgreSQL by using it's PITR support for example. But to the extent that you have a log which is only supposed to be used for internal reasons (such as with pg by default), you'd likely be in trouble anyway unless you had a specific reason to know that it is safe. > As always any backup scheme has to be TESTED so you can prove to your > own satisfaction that it is RESTORABLE. I can't tell you how many > business clients I have run into (and not only on Unix machines) that > have wind up with lots of backups and NONE of them can be restored - > because they never TESTED their backup strategy. Very true, but it is equally dangerous to rely on testing *only*; a backup system can be very very broken yet appear to work during testing, either because backups only break sometimes or because they break in ways that do not obviously and immediately blow up in your face. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpWj4ZTvhhau.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Peter Schuller wrote: To add to this what SHOULD (ha!) work is to dump the database partition FIRST and THEN dump the Transaction Log partition. Depending on how the database works; specifically when old data in the log may or may not be expunged. You could do this with PostgreSQL by using it's PITR support for example. But to the extent that you have a log which is only supposed to be used for internal reasons (such as with pg by default), you'd likely be in trouble anyway unless you had a specific reason to know that it is safe. True. If the log rolls on you while you're taking the dumps you're DEAD. Both design and verification are important :) -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Hi.. On Thu, 26 Mar 2009, Peter Schuller wrote: Yes, but it's for running a dump on a (L)ive FS and just spits out warnings to that effect and has no effect on solving the problem(s). Unless the filesystem is very busy, you will get your data backed up. If you have things like databases, I still would not trust snapshots. Uh. If backuping up a live database from a snapshot is not trustworthy, either the snapshot facility is broken or the database is broken (i.e., not crash-safe to begin with). Exactly right - if you backup a database by relying on storage snapshots then the best you will end up with is a database that needs to be recovered when you restore those volumes (crash consistent). That's not a good place to be in when your production DB has just blown up. In addition, there are all sorts of complications which mean that you might need to freeze IO on multiple volumes simultaneously in order for this to have a chance of being successful (maintaining write-order-fidelity). I would strongly discourage anyone from using this method of backup for anything that is considered production, thought it might do you for making QA clones of a running database. That said there are plenty of other reasos to use proper dump tools (data portability, confirming the ability to actually read all rows from a table, using a more often exercised code path and perhaps less likely to have edge case bugs, etc). Absolutely. You really must use a tool that interacts with the database to perform the backup. Most commercial DBs have hooks that allow the backup routines to call out to custom snapshot facilities. One would usually request a backup through the database, which would then freeze IO to its data files and maybe log files, deal with flushing caches etc and then call your snapshot routine. I'm not aware that MySQL and Postgres do though so the best you can do is a dump. Jake ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
Paul B. Mahol wrote: > On 3/26/09, John wrote: >> Paul B. Mahol wrote: >> >>> This is a contradiction, I think that in csup case "last rule wins" >> How come this builds a 7-STABLE system rather than -CURRENT ? >> >> In any case, I appreciate your comment and will take out the offending >> line. (it's in there because I thought ports was always HEAD) > > from csup(1) > > Default settings may be specified in lines whose collection name is > *default.Such defaults will apply to subsequent lines in the > supfile. > Multiple *default lines may be present. New values augment or override > any defaults specified earlier in the supfile. Values specified explic- > itly for a collection override any default values. This means that my cvsup file was working as expected - RELENG_7 for everything apart from ports. > This can be much simpler. Did you noticed kernel version when you booted > new kernel (available via dmesg(8))? > Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #0: Thu Mar 26 01:02:54 GMT 2009 r...@potato.growveg.org:/usr/src/sys/amd64/compile/POTATO Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3006.83-MHz K8-class CPU) I thought that ports was always HEAD ? Is this incorrect? -- John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
On 2009-03-26 02:45:45PM +, Jake Scott wrote: > Absolutely. You really must use a tool that interacts with the database to > perform the backup. Most commercial DBs have hooks that allow the backup > routines to call out to custom snapshot facilities. One would usually > request a backup through the database, which would then freeze IO to its > data files and maybe log files, deal with flushing caches etc and then call > your snapshot routine. I'm not aware that MySQL and Postgres do though so > the best you can do is a dump. With MySQL at least, you can (ab)use the replication facilities so that you can set up a "slave" and do the fs-level dump while the slave is in a "frozen" state - the last time I played with MySQL, you could basically desync your slave for a period of time (basically until transaction logs are purged on the master), during which the slave will be consistent; do the fs-level backup then kick the master to sync with the slave again. -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> Exactly right - if you backup a database by relying on storage snapshots > then the best you will end up with is a database that needs to be > recovered when you restore those volumes (crash consistent). That's not a > good place to be in when your production DB has just blown up. If you have a production db that you care about, your database better not have trouble recoverying from a crash consistent state. But again I'm not suggesting that snapshot based backups be the primary method of backing up. In terms of time-to-recovery, having a crash consistent DB can be a lot quicker to recover than grabbing a dump, whose restoration will tend to be a lot slower than copying files. > Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. I do not think "really must" is appropriate since clearly you can recover without DB specific integration. There may be reasons why it's better to have DB specific integration though (for example, limiting the amount of log reply that will be needed at recovery). The implication above that you cannot use snapshot based mechanisms with PostgreSQL and MySQL is not true; it's just that if you do you have to know what you're doing. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpnrWUeX1TdZ.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
Jake Scott wrote:
That said there are plenty of other reasos to use proper dump tools
(data portability, confirming the ability to actually read all rows
from a table, using a more often exercised code path and perhaps less
likely to have edge case bugs, etc).
Absolutely. You really must use a tool that interacts with the
database to perform the backup. Most commercial DBs have hooks that
allow the backup routines to call out to custom snapshot facilities.
One would usually request a backup through the database, which would
then freeze IO to its data files and maybe log files, deal with
flushing caches etc and then call your snapshot routine. I'm not
aware that MySQL and Postgres do though so the best you can do is a dump.
Jake
VERY careful thought has to go into backup strategy with production
databases.
Hooks that call out and snapshot are not necessarily good enough
although they're "necessary" to get a dump that restores without the
database going into log-replay mode.
It is not difficult to do this with Postgresql; you can quiesce the
database, snapshot and then release it, then dump the snapshots. This
gives you transaction-complete dumps (as opposed to "crashed and rolled
forward" dumps). The latter ("crashed and rolled forward"), if its
sufficient, is trivially able to be done by having Postgresql (and most
other databases) keep a sufficient number of log segments that a
rollover cannot happen during the dump process itself, and either
snapshotting both filesystems at once, keeping both on the same
filesystem (undesirable for performance reasons) or dumping the database
first and XLOG second.
However, whether either of these approaches is sufficient is another
matter. One of the real problems with live transaction processing
systems is a means to know when there is a failure exactly what you
lost. This is not a trivial problem to solve and requires plenty of
thought before implementation, especially if you cannot afford the
outage time necessary to take the snapshots - in some cases even that
(relatively) short outage time is unacceptable.
--
--
Karl Denninger
k...@denninger.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> However, whether either of these approaches is sufficient is another > matter. One of the real problems with live transaction processing > systems is a means to know when there is a failure exactly what you > lost. This is not a trivial problem to solve and requires plenty of > thought before implementation, especially if you cannot afford the > outage time necessary to take the snapshots - in some cases even that > (relatively) short outage time is unacceptable. I would like to point out that if the backup strategy is correct, a COMMIT is guaranteed to be correctly honored, and the problem of determining what was lost has more to do with the birds-eye view of to what point in time the database was reverted as part of emergency recovery, than any difficulty in understanding what actually happens during snapshot recovery. I completely understand that you have various requirements in production that makes it a non-solution to just get a consistent snapshot at some arbitrary point in time without synchronizing with other software components somehow, but such issuse are into the realm of application design and integration with the backup procedure, and we are no longer talking about the viability of obtaining a consistent backup of a single database through snapshotting. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpHwSW72mDdH.pgp Description: PGP signature
process hanging on 7.2-PRERELEASE
Hi, My brand new amd64 has a hanging process. # uname -a FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar 25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64 I'm compiling a port of kde4. top says this since a while: 43404 root 1 116 20 21304K 4148K umtxn 1 0:00 0.00% automoc4 # procstat -kk 43404 PIDTID COMM TDNAME KSTACK 43404 100279 automoc4 -tdq_cpu+0x1218 Dmesg in the attachment. Can I provide more information to debug this? Ronald. dmesg.boot Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: process hanging on 7.2-PRERELEASE
On Thu, 26 Mar 2009 17:26:13 +0100, Ronald Klop wrote: Hi, My brand new amd64 has a hanging process. # uname -a FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar 25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64 I'm compiling a port of kde4. top says this since a while: 43404 root 1 116 20 21304K 4148K umtxn 1 0:00 0.00% automoc4 # procstat -kk 43404 PIDTID COMM TDNAME KSTACK 43404 100279 automoc4 -tdq_cpu+0x1218 Dmesg in the attachment. Can I provide more information to debug this? Ronald. I have more information. Maybe related. | | | \-+= 01734 root -su (bash) | | | \-+= 28036 root /bin/sh /home/ronald/bin/ports_upgrade.sh | | | \-+- 28987 root /bin/sh /tmp/ports_upgrade.sh.g4IH4j | | | \-+- 28988 root ruby18: portupgrade: [22/34] kdenetwork-4.2.1 (ruby18) | | | \-+- 29984 root /usr/bin/script -qa /tmp/portupgrade20090326-28988-19b2asv | | | \-+= 29986 root make | | | \-+- 31170 root [sh] | | | \-+- 31171 root [sh] | | | \-+- 31172 root make -f Makefile OPENSSL_CFLAGS=-DNO_IDEA all | | | \-+- 31175 root make -f CMakeFiles/Makefile2 all | | | \-+- 43401 root make -f kdnssd/ioslave/CMakeFiles/kio_zeroconf | | | \-+- 43402 root [sh] | | | \-+- 43403 root [automoc4] | | | \--- 43404 root [automoc4] # procstat -kk 43403 PIDTID COMM TDNAME KSTACK 43403 100073 automoc4 -tdq_cpu+0x1218 43403 100229 automoc4 initial thread tdq_cpu+0x6f8 Is this interesting? Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dump | restore fails: unknown tape header type 1853384566
On Tue, Mar 24, 2009 at 02:03:12PM -0400, Mikhail T. wrote: > Same problem: > >restore -rf ibmo.0.2009-03-24.dump >load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k >unknown tape header type 213474529 >abort? [yn] > > Please, advise. Thanks! Yours, Hi Mikhail, If you actually need to get a dump back that restore can't read, you can try the "-D" option that I added a few years ago. Dump and restore expect things to be in a block format, but if (say) dump outputs a few bytes into the stream due to a bug, then the entire end of the dump can become unreadable. The -D option to restore tells it to try hard to get back in sync again. I'd guess you've tripped over either a bug in dump or restore. If you can file a PR, particularly with access to a sample dump, then I can have a look and see if I can figure out what's going on. Daid. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 09:32 AM 3.26.2009 -0400, Mike Tancsa wrote: >At 08:08 AM 3/26/2009, Jack L. Stone wrote: > >>Yes, but it's for running a dump on a (L)ive FS and just spits out warnings >>to that effect and has no effect on solving the problem(s). > >Unless the filesystem is very busy, you will get your data backed up. >If you have things like databases, I still would not trust >snapshots. Better to use pg_dump or mysqldump or the app that comes >with whatever DB you are using... When backing up things like / and >/usr, I would hazard a guess that most things are not changing while >the backup is running, at least they dont in my environments. I have >never had a problem with things like /home and even /var or /mail >which are changing quite a bit. We dont restore much in the course >of our daily routine, but we have always been able to restore >people's Maildir when they accidentally have deleted stuff and it all >worked without issue over the years. > > ---Mike Yes, we have been using the "L" switch for as long as it has existed because we have and always before that, backed up live FSes. And, as said before, we do a dump/restore dump every morning to produce a bootable clone. The clones have always worked for the many years we have done this. Indeed, we have always used the MySQL's own dump separately to backup DBs. But, that's OT. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 10:15 AM 3.26.2009 -0400, Mike Tancsa wrote: >At 10:01 AM 3/26/2009, Peter Schuller wrote: >> > >> > Unless the filesystem is very busy, you will get your data backed up. >> > If you have things like databases, I still would not trust >> > snapshots. >> >>Uh. If backuping up a live database from a snapshot is not >>trustworthy, either the snapshot facility is broken or the database is >>broken (i.e., not crash-safe to begin with). > >... or the database is configured in a risky way... But judging by >this thread, it seems dump with -L is indeed broken for some >people. Hence, I suggested dumping the database using the database's >backup tools and trying dump without -L > > ---Mike Mike: The "L" for dumping is definitely NOT the problem. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
> Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. mysql can do this - you can flush the tables and acuire a lock simultaneously so that you can then snapshot the uderlying filesystem and then release the lock to let everything continue. I use this for taking database snapshots and it works fine. I stop my slaves before snapshotting to avoid log files changing underneath me too like this... #!/bin/sh /usr/local/bin/mysql -usnapuser -psnapuser
Re: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566)
At 03:49 PM 3.26.2009 +0100, Peter Schuller wrote: >> ... or the database is configured in a risky way... But judging by >> this thread, it seems dump with -L is indeed broken for some >> people. Hence, I suggested dumping the database using the database's >> backup tools and trying dump without -L > >Well, if dump -L is really broken I'd recommend just not using dump >unless you absolutely have to. That is assuming snapshots are not >broken so that you can still use mksnap_ffs with your favorite backup >tool. > >-- >/ Peter Schuller > No one has said the dump "L" is broken -- and is NOT but now may mislead others just tuning into this thread. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
At 10:46 AM 3.26.2009 -0500, Karl Denninger wrote: >Jake Scott wrote: >> >>> That said there are plenty of other reasos to use proper dump tools >>> (data portability, confirming the ability to actually read all rows >>> from a table, using a more often exercised code path and perhaps less >>> likely to have edge case bugs, etc). >> This thread has drifted off the main issue of using the FS dump/restore problem. Although, the DBs may be included as a part of this dump, it should NOT be relied upon as a backup/restore of DBs. We use MySQL's dump/backup tools strictly for the DBs. The dumps of the DBs (using MySQL's own dump tool) here are run by cron jobs every hour or few hours at most. That keeps our DB backups very recent and near current as possible is a restore is needed. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: istgt now supports command queuing in disk type
Hello, I sent change request of ports version. (just now was committed when I wrote mail) What's new? (from 20090323) o starting to support multipath I/O by VMware ESXi (Fix/MRU/RR) o wildcard address listen and translate IP (useful on DHCP) o utilization efficiency of the command queuing was improved o task abort handling in cluster nodes o reduce deadlock and timeout risk (from 20090314) o support command queuing o shrink pre-allocated SCSI sense data buffer from 64K to 4K. o allow full specify "eui." and "naa." like "iqn." o if small PDU, write as one buffer. and many bug fixes The command queuing is disabled by default. If you want to use it, please add QueueDepth key in the LogicalUnit section of your configuration. for example: [LogicalUnit1] # Queuing 0=disabled, 1-255=enabled with specified depth. QueueDepth 16 If you have any problem with command queuing, comment out or specify 0 to disable it. Disabled version is about the same behavior as 20090314. To use wildcard address, edit your configuration like this: [PortalGroup1] # for IPv6 Portal DA1 [::]:3260 # for IPv4 Portal DA1 0.0.0.0:3260 Do not use mix with other IPs. After this change you can see TargetAddress as connected IP. IP address family connected by discovery session is important. If you need IPv6 target address, should use IPv6 in discovery. Also if you need IPv4 target address, should use IPv4. The istgt will reply only one IP address of multiple wildcard address to the initiator. Here is release 20090326: http://shell.peach.ne.jp/aoyama/archives/386 -- Daisuke Aoyama ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566)
On Thu, 2009-03-26 at 14:45 +, Jake Scott wrote: .. > Absolutely. You really must use a tool that interacts with the database > to perform the backup. Most commercial DBs have hooks that allow the > backup routines to call out to custom snapshot facilities. One would > usually request a backup through the database, which would then freeze IO > to its data files and maybe log files, deal with flushing caches etc and > then call your snapshot routine. I'm not aware that MySQL and Postgres do > though so the best you can do is a dump. > > > Jake > Just to add, mysql has a utility (mysqlhotcopy) to allow you to directly copy MyISAM databases with a guarentee of consistency (thus avoiding the conversion from MyISAM data -> SQL, and no need to reimport when recovering). It isn't exactly online though, any writes will be blocked until the hotcopy finishes. Still, it is only MyISAM, and not much call for that these days.. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Q: FreeBSD 7.1 stable boot failure
Greetings, I just re-installed an old file server from stable 6.1 to 7.1 stable, and I'm having a problem with my 3ware 7000-2 card. After sysinstall completes, and I try to boot from the SCSI HDD (not connected to the 3ware) for the first time, the system hangs immediatly after the POST completes. The keyboard goes dead (numlock and caps lock stop working) and it never starts to load. I can't get the system to a point where I can get an error to work with. When I remove the 3ware card, the system boot fine. FreeBSD is installed on my system's internal SCSI drives (the 3ware card manages data disks, not OS disks). I've checked the media md5, and the media checks out OK. I've tried manually setting the boot partition to the root partition on the SCSI drives. This problem is 100% repeatable on my system using 7.1 stable (and I did not experiance this with 6.1 stable). I've reinstalled several times with different options trying to get around this problem. The system is a Dell poweredge 2200 (dual PIII 333Mhz procs) SCSI drives (set to 4 and 5, controller set to 7), 128MB memory, and a 3ware 7000-2 card which should be supported by the twe0 driver. Would someone point me in the correct direction for resolving this? Something must have changed between 6.1 and 7.1 stable that is causing my hang. Thanks, John H. Nyhuis IT Manager Dept. of Pediatrics HS RR541C, Box 356320 University of Washington Desk: (206)-685-3884 jnyh...@u.washington.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566)
At 01:11 PM 3/26/2009, Jack L. Stone wrote: No one has said the dump "L" is broken -- and is NOT but now may mislead others just tuning into this thread. OK, sorry I misunderstood that restore worked from dump files without -L I wonder if the original poster just needs to do an fsck on the disk. The only time I had dump crap out on me (other than with -L) was on a dirty filesystem. I regularly do stuff like cd /usr;dump 0f - /usr | (cd /tmp/usr; restore -rf - ) to duplicate partitions ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: process hanging on 7.2-PRERELEASE
On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote: > Hi, > > My brand new amd64 has a hanging process. > # uname -a > FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar > 25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64 > > I'm compiling a port of kde4. > top says this since a while: > 43404 root 1 116 20 21304K 4148K umtxn 1 0:00 0.00% > automoc4 > > # procstat -kk 43404 > PIDTID COMM TDNAME KSTACK > 43404 100279 automoc4 -tdq_cpu+0x1218 > > Dmesg in the attachment. > > Can I provide more information to debug this? Did you rebuild both world and kernel ? (old world with new kernel shall work, I am just gathering information by this question). The most useful data would be usermode backtrace of all threads. For this to be useful, you probably need to build at least libc and libthr with debugging symbols. pgpA967AKY9N6.pgp Description: PGP signature
Re: process hanging on 7.2-PRERELEASE
On Thu, 26 Mar 2009 19:23:42 +0100, Kostik Belousov wrote: On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote: Hi, My brand new amd64 has a hanging process. # uname -a FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar 25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64 I'm compiling a port of kde4. top says this since a while: 43404 root 1 116 20 21304K 4148K umtxn 1 0:00 0.00% automoc4 # procstat -kk 43404 PIDTID COMM TDNAME KSTACK 43404 100279 automoc4 -tdq_cpu+0x1218 Dmesg in the attachment. Can I provide more information to debug this? Did you rebuild both world and kernel ? (old world with new kernel shall work, I am just gathering information by this question). The most useful data would be usermode backtrace of all threads. For this to be useful, you probably need to build at least libc and libthr with debugging symbols. Yes, world and kernel are in sync. Ok, I've rebuild libc and libthr with doing: export DEBUG_FLAGS=-g cd /usr/src/lib/libc make clean && make depend && make && make install And the same for /usr/src/lib/libthr. Now I did 'gdb /usr/local/bin/automoc4 ' for both programs (see my other mail). The output is in the attachment. One of the processes (43403) is threaded, but I don't know how to debug that. Hints are welcome. Does this info ring a bell? Ronald.Script started on Thu Mar 26 19:41:50 2009 [r...@sjakie ~]# uname -aprocstat -kk 43404[10Puname -a[Kgdb /usr/local/bin/automoc4 43403 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/bin/automoc4, process 43403 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...done. Error while reading shared library symbols: Cannot get thread info: generic error Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x000800f55cdc in tcsetattr (fd=Variable "fd" is not available. ) at /usr/src/lib/libc/gen/termios.c:76 76 errno = EINVAL; (gdb) bt #0 0x000800f55cdc in tcsetattr (fd=Variable "fd" is not available. ) at /usr/src/lib/libc/gen/termios.c:76 #1 0x in ?? () #2 0x000800769168 in QProcessManager::run () from /usr/local/lib/qt4/libQtCore.so.4 #3 0x0008006c2e53 in QThreadPrivate::start () from /usr/local/lib/qt4/libQtCore.so.4 #4 0x000800d762b1 in thread_start (curthread=0x6) at /usr/src/lib/libthr/thread/thr_create.c:249 #5 0x in ?? () #6 0x in ?? () #7 0x in ?? () #8 0x in ?? () #9 0x7fffd8e8 in ?? () #10 0x in ?? () #11 0x in ?? () Error accessing memory address 0x7fbff000: Bad address. (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/automoc4, process 43403 [r...@sjakie ~]# gdb /usr/local/bin/automoc4 43403 4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging sy
Re: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566)
> >> ... or the database is configured in a risky way... But judging by > >> this thread, it seems dump with -L is indeed broken for some > >> people. Hence, I suggested dumping the database using the database's > >> backup tools and trying dump without -L > > > >Well, if dump -L is really broken I'd recommend just not using dump > >unless you absolutely have to. That is assuming snapshots are not > >broken so that you can still use mksnap_ffs with your favorite backup > >tool. > > > >-- > >/ Peter Schuller > > > > No one has said the dump "L" is broken -- and is NOT but now may mislead > others just tuning into this thread. I was commenting on the specific statement that I quoted above. I am not claiming anything about dump being broken. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org pgpXPhLNXJhUI.pgp Description: PGP signature
Re: support quality (Re: dump | restore fails: unknown tapeheadertype 1853384566)
Mike Tancsa wrote: At 01:11 PM 3/26/2009, Jack L. Stone wrote: No one has said the dump "L" is broken -- and is NOT but now may mislead others just tuning into this thread. OK, sorry I misunderstood that restore worked from dump files without -L I wonder if the original poster just needs to do an fsck on the disk. The only time I had dump crap out on me (other than with -L) was on a dirty filesystem. I regularly do stuff like cd /usr;dump 0f - /usr | (cd /tmp/usr; restore -rf - ) to duplicate partitions ---Mike I do as well but if the original user is trying to restore into a filesystem that is either not clean or not EMPTY for a full restore he could run into some trouble. I've never had dump/restore fail by the way, other than due to bad (tape) media (yes, it was that long ago :) ) -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Q: FreeBSD 7.1 stable boot failure
Sorry if this is a repost. My first request did not seem to come through... Greetings, I just re-installed an old file server from stable 6.1 to 7.1 stable, and I'm having a problem with my 3ware 7000-2 card. After sysinstall completes, and I try to boot from the SCSI HDD (not connected to the 3ware) for the first time, the system hangs immediatly after the POST completes. The keyboard goes dead (numlock and caps lock stop working) and it never starts to load. I can't get the system to a point where I can get an error to work with. When I remove the 3ware card, the system boot fine. FreeBSD is installed on my system's internal SCSI drives (the 3ware card manages data disks, not OS disks). I've checked the media md5, and the media checks out OK. I've tried manually setting the boot partition to the root partition on the SCSI drives. This problem is 100% repeatable on my system using 7.1 stable (and I did not experiance this with 6.1 stable). I've reinstalled several times with different options trying to get around this problem. The system is a Dell poweredge 2200 (dual PIII 333Mhz procs) SCSI drives (set to 4 and 5, controller set to 7), 128MB memory, and a 3ware 7000-2 card which should be supported by the twe0 driver. Would someone point me in the correct direction for resolving this? Something must have changed between 6.1 and 7.1 stable that is causing my hang. Thanks, John H. Nyhuis IT Manager Dept. of Pediatrics HS RR541C, Box 356320 University of Washington Desk: (206)-685-3884 jnyh...@u.washington.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: process hanging on 7.2-PRERELEASE
On Thu, Mar 26, 2009 at 07:44:41PM +0100, Ronald Klop wrote: > On Thu, 26 Mar 2009 19:23:42 +0100, Kostik Belousov > wrote: > > >On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote: > >>Hi, > >> > >>My brand new amd64 has a hanging process. > >># uname -a > >>FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar > >>25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC > >>amd64 > >> > >>I'm compiling a port of kde4. > >>top says this since a while: > >>43404 root 1 116 20 21304K 4148K umtxn 1 0:00 0.00% > >>automoc4 > >> > >># procstat -kk 43404 > >> PIDTID COMM TDNAME KSTACK > >>43404 100279 automoc4 -tdq_cpu+0x1218 > >> > >>Dmesg in the attachment. > >> > >>Can I provide more information to debug this? > > > >Did you rebuild both world and kernel ? (old world with new kernel shall > >work, I am just gathering information by this question). > > > >The most useful data would be usermode backtrace of all threads. > >For this to be useful, you probably need to build at least libc > >and libthr with debugging symbols. > > > Yes, world and kernel are in sync. > Ok, I've rebuild libc and libthr with doing: > export DEBUG_FLAGS=-g > cd /usr/src/lib/libc > make clean && make depend && make && make install > > And the same for /usr/src/lib/libthr. libthr debug symbols seems to be damaged. > > Now I did 'gdb /usr/local/bin/automoc4 ' for both programs (see my > other mail). The output is in the attachment. One of the processes (43403) > is threaded, but I don't know how to debug that. Hints are welcome. you should list the threads with gdb command 'threads', then switch consequently to each thread by 'thread ', and get a backtrace. Unfortunately, this is not useful without proper debugging information in system shared libraries. Also, looking at the mangled backtrace for pid 43403, it looks like ld.so also participates in the problem. It may be useful to install ld.so with debug symbols too. pgpzoyM0wqpbr.pgp Description: PGP signature
Re: remote debug over usb vs. old serial cable?
Ronald Klop wrote: On Thu, 26 Mar 2009 15:22:36 +0100, Andriy Gapon wrote: on 26/03/2009 15:06 Erik Trulsson said the following: On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote: Hello, In the past I could catch a panic during boot via a serial cable connected to another computer. My new computer only has USB-ports and ethernet. What kind of cable do I need now to do remote debugging? The old computer also has usb, so I think the connection should be in that corner. They all run 7-STABLE. USB won't work for that purpose. It requires far too much kernel support to be useful after a panic. Erik, in fact, there is a special USB (EHCI) mode for such purposes: http://www.coreboot.org/EHCI_Debug_Port But that requires some special HW in addition to SW support which our doesn't have. BTW, Ronald, it is possible that you might have a serial header on motherboard which is not connected to any traditional port. Is that this sio0 one? sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Yes. Mine (onboard) is recognized in a similar fashion: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled It actually is enabled and working... I am going to open my computer tonight to see what is in there. You want to look out for a 10 pin connector -- they usually look like jumper connectors (I don't know the correct word in english, in german it's called "Pfostenstecker"). It's even possible that it's there, but not connected in any way -- consult the manual of your mainboard to be sure. Regards, Philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dump | restore fails: unknown tape header type 1853384566
Mikhail, MT> I'm trying to migrate a filesystem from one disk to another using: MT> dump a0hCf 0 32 - /old | restore -rf - MT> (/old is already mounted read-only). The process runs for a while and MT> then stops with: MT> [...] MT> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 MT> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 MT> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 MT> unknown tape header type 1853384566 MT> abort? [yn] MT> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's MT> dump's output? Is your /tmp large enough to restore? -- Eugene Gladchenko EVG15-RIPE
Re: dump | restore fails: unknown tape header type 1853384566
Mikhail T. wrote: Hello! I'm trying to migrate a filesystem from one disk to another using: dump a0hCf 0 32 - /old | restore -rf - Try dump -a0 -h 0 -C 32 -f - /old instead. Your command line should work, but I've had trouble with similar ones and have been able to solve it by separating the options. (/old is already mounted read-only). The process runs for a while and then stops with: [...] DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009 DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009 DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009 unknown tape header type 1853384566 abort? [yn] Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's dump's output? The system runs 7.0-STABLE from July 6th, i386. I just tried updating the dump and restore from source (latest 7.x) -- the error is the same... Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Sincerly, Rolf Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: remote debug over usb vs. old serial cable?
On Friday 27 March 2009 00:52:36 Andriy Gapon wrote: > > USB won't work for that purpose. It requires far too much kernel support > > to be useful after a panic. > > Erik, > in fact, there is a special USB (EHCI) mode for such purposes: > http://www.coreboot.org/EHCI_Debug_Port That's pretty neat :) The dongle is pretty expensive relative to the cost of a Firewire card though. > But that requires some special HW in addition to SW support which our > doesn't have. > > BTW, Ronald, it is possible that you might have a serial header on > motherboard which is not connected to any traditional port. You could also purchase a Firewire PCI (or PCIe) card, they aren't very expensive. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: dump | restore fails: unknown tape header type 1853384566
On 2009-03-25, Mikhail T. wrote: > Greg Black ???(??): >> On 2009-03-24, Mikhail T. wrote: >> >>> That's true. I just wanted to point out, that someone running dump only >>> (to make backups) is not going to know, whether his dumps are usable >>> (for whichever of the two reasons), until he needs them... >> >> Such a person is not making backups and deserves what he gets. >> > But he *is* making backups -- kindly re-read my paragraph above... He > just is not routinely using them and thus does not know, that they > aren't usable... It is not unreasonable to expect the two utilities to > "just work", so I wouldn't be blaming such a person for not testing > restore. Sorry, this person is *not* making backups in any meaningful fashion. Unless you verify regularly (preferably every time you make a backup) that you can restore both parts of the backup and the entire thing, you are not making backups. You may be lucky, but you probably won't be lucky when it really matters. This is a long-standing issue with backups. But people who don't understand the tools they are using tend to make these mistakes. The result is bad. The solution is to employ competent people who both understand the issues and have the authority to carry out their task. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dump | restore fails: unknown tape header type 1853384566
Greg Black wrote: > Sorry, this person is *not* making backups in any meaningful fashion. > Unless you verify regularly (preferably every time you make a backup) > that you can restore both parts of the backup and the entire thing, you > are not making backups. You may be lucky, but you probably won't be > lucky when it really matters. s/making backups/employing an effective data recovery strategy/ Please don't feed the "proper use of language" trolls. :) Meanwhile, we may want to consider that this whole thread is veering off topic ... Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
backup strategy (Re: dump | restore fails)
Greg Black написав(ла): Sorry, this person is *not* making backups in any meaningful fashion. Unless you verify regularly (preferably every time you make a backup) that you can restore both parts of the backup and the entire thing, you are not making backups. To qualify for your (and your kind's) recognition then, a person needs to have at least as much extra storage capacity as the largest filesystem they are backing up. They also need non-trivial scripting abilities, because the OS doesn't include anything like what you are describing (and I already do consider scheduling dumps via cron "trivial", which may be a stretch). Yours may thus be an acceptable requirement for a multi-computer shop with dedicated system administration personnel, but for a private home user with only one computer this simply is not reasonable. Stating this as a requirement is ridiculous -- unless you are prepared to say, that such people should not own a computer (with worthy data) at all. And that's even more ridiculous... Make your pick. I would agree with you, if the chosen backup method involved some complex or third-party tools. But if the simple, OS-supplied orthogonal dump/restore don't work together, then the OS is broken -- plain and simple, and pointing a finger at the user: "Well, it is all your fault, because you relied on us providing you with working utilities, ha-ha-ha!" -- is the lamest excuse imaginable. -mi P.S. Some people have actually volunteered to help debug this problem and I'm working on providing them with data (the troublesome partition is, sadly, over 170Gb, so it takes a while). Any results/conclusions will be posted under the original subject. P.P.S. The data transferred fine using tar, but that is not the point -- the bug (confirmed by at least one more person) -- needs to be fixed before a higher-profile embarrassment... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: backup strategy (Re: dump | restore fails)
Mikhail T. wrote: > To qualify for your (and your kind's) recognition then, a person > needs to have at least as much extra storage capacity as the > largest filesystem they are backing up. They also need > non-trivial scripting abilities, because the OS doesn't > include anything like what you are describing Mikhail, users would be well advised to check their backups using this option, without having to have the space to restore: -N Do the extraction normally, but do not actually write any changes to disk. This can be used to check the integrity of dump media or other test purposes. RESTORE(8) FreeBSD System Manager's Manual ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: backup strategy (Re: dump | restore fails)
Andrew Snow написав(ла): Mikhail T. wrote: > To qualify for your (and your kind's) recognition then, a person > needs to have at least as much extra storage capacity as the > largest filesystem they are backing up. They also need > non-trivial scripting abilities, because the OS doesn't > include anything like what you are describing Mikhail, users would be well advised to check their backups using this option, without having to have the space to restore: -N Do the extraction normally, but do not actually write any changes to disk. This can be used to check the integrity of dump media or other test purposes. And then another "purist" will reject this as a fake and not sufficiently conclusive test... Just ask around... Because, you see, until you extract all data back and run a bit-by-bit comparison with the original, you don't really know, do you? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.2:named:max open files (3578) is smaller than max sockets (4096)
Greetings, On a fresh 7 install with a cvsup late morning 09-03-26 I performed a make buildworld > make buildkernel > make installkernel > reboot to single user > mergemaster -p > make installworld && mergemaster on an Intel based CPU. Upon reboot I now recieve the following message when named starts: max open files (3578) is smaller than max sockets (4096) Running named with all of the same files /prior/ to the new kernel/world did not produce this message. Any thoughts? Thank you for all your time and consideration in this matter. --Chris uname: FreeBSD 7.2-PRERELEASE Thu Mar 26 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE)
On Thu, Mar 26, 2009 at 11:23:09AM +, John wrote: > Weongyo Jeong wrote: > > > Could you please test it with attached patch to fix a page fault? I > > don't know why bus_dma_tag_create() returns ENOMEM that it looks > > temporary. > > Hi, > > Seems the patch failed to apply: > > [r...@potato /usr/src/sys/dev/malo]# ls -la > total 140 > drwxr-xr-x2 root wheel512 Mar 26 11:17 . > drwxr-xr-x 199 root wheel 3072 Mar 24 16:58 .. > -rw-r--r--1 root wheel 8 May 4 2008 if_malo.c > -rw-r--r--1 root wheel 19096 May 4 2008 if_malo.h > -rw-r--r--1 root wheel 9625 Mar 26 11:14 if_malo_pci.c > -rw-r--r--1 root wheel 22333 May 4 2008 if_malohal.c > -rw-r--r--1 root wheel 8266 May 4 2008 if_malohal.h > -rw-r--r--1 root wheel 3722 May 4 2008 if_maloioctl.h > -rw-r--r--1 root wheel375 Mar 26 11:15 > patch_malo_20090326_panic.diff > > [r...@potato /usr/src/sys/dev/malo]# patch < patch_malo_20090326_panic.diff > > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |Index: if_malo_pci.c > |=== > |--- if_malo_pci.c (revision 187939) > |+++ if_malo_pci.c (working copy) > -- > Patching file if_malo_pci.c using Plan A... > Hunk #1 failed at 260. > 1 out of 1 hunks failed--saving rejects to if_malo_pci.c.rej > done It looks something goes wrong so could you please patch if_malo_pci.c manually it's a very simple patch and test? Sorry for inconvenience. regards, Weongyo Jeong ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
