Re: disklabel differences FreeBSD, DragonFly
to followup myself ... I just see, we also have pack identifier, its the additional struct behind it that differs. "Bootstrap name" etc... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How to Use ddb(4)?
I have add relevant options into my kernel (7.0-CURRENT) configuration file: makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN When kernel panics, the prompt "db>" will appear. But at this time I cannot control my computer with keyboard any longer. What's wrong with me? In my mind, both 7.0-CURRENT and 6.x-STABLE halt a year ago are all right in ddb(4). By the way, the loader(8) option "-a" (to let user decide which file system is taken as root file system) is also unusable. From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
"Intron" <[EMAIL PROTECTED]> writes: > When kernel panics, the prompt "db>" will appear. But at this time > I cannot control my computer with keyboard any longer. What's wrong > with me? I don't know what's wrong with you, but as regards your computer: disable kbdmux and use a PS/2 keyboard. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Need some articles on routing sockets in FreeBSD
I need to understand the usage and to some level details of the routing sockets (internals may not be the exact word but still ... :-] ) there is this scenario of this multiple daemons that are communicating using *rt_sock *and need to trace the communication that is happening ... for this I need to know rt_sock ... are there any articles on Routing Sockets ... and their usage / internals ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
Eric Anderson <[EMAIL PROTECTED]> wrote: > I'm tired of trying to use rsync or gcp (which doesn't like symlinks > often) to copy trees of files/directories using hard links, so I added > the gcp-ish options -a and -l. > > -a is 'archive' mode, which is just a quick form of -PpR. -P is the default anyway, so -a would only replace -Rp. I don't think saving one letter justifies introducing a new option. You can use an alias or shell function. > -l is 'link' mode, where regular files get hard linked instead of copied. > > So, you can mimic an entire tree with something like: > > cp -al /from/ /to/ > > and it's fast too! You can do the same with existing tools in a portable (and thus preferable) way: cd /from; find -d . | cpio -dumpl /to Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, > of course still my main Unix ;-) But it wasn't possible. DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: > > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, > > of course still my main Unix ;-) But it wasn't possible. > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. On very large disks (or arrays that appear as a single disk) I have to create multiple slices in order to get more than 8 mountpoints. Its an extra hoop to jump through. -steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: disklabel differences FreeBSD, DragonFly
>to followup myself ... I just see, we also have pack identifier, >its the additional struct behind it that differs. >"Bootstrap name" etc... Those are parts of an union, so the total size still shouldn't change. I'd guess that the char[] format is used on-disk and the pointers are used in-memory. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Dag-Erling [iso-8859-1] Smo/rgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: When kernel panics, the prompt "db>" will appear. But at this time I cannot control my computer with keyboard any longer. What's wrong with me? I don't know what's wrong with you, but as regards your computer: disable kbdmux and use a PS/2 keyboard. DES -- Dag-Erling Smo/rgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I've been comforted by you that there's nothing wrong with me. Well, FreeBSD Developers' Handbook needs to be updated now. http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html The same to manual page ddb(4). From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
"Intron" <[EMAIL PROTECTED]> writes: > Dag-Erling [iso-8859-1] Smo/rgrav wrote: > > "Intron" <[EMAIL PROTECTED]> writes: > > > When kernel panics, the prompt "db>" will appear. But at this > > > time I cannot control my computer with keyboard any longer. > > > What's wrong with me? > > I don't know what's wrong with you, but as regards your computer: > > disable kbdmux and use a PS/2 keyboard. > I've been comforted by you that there's nothing wrong with me. Glad to help :) > Well, FreeBSD Developers' Handbook needs to be updated now. No, kbdmux needs to be fixed so it works in DDB. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Warning Message from uma_zdestroy(9)
Why does uma_zdestroy(9) print message like: Freed UMA keg was not empty (100 items). Lost 2 pages of memory. But actually I have made sure that uma_zalloc(9) and uma_zfree(9) appear in pair in my code. Does it represent any problems? From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Dag-Erling Smørgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: Dag-Erling [iso-8859-1] Smo/rgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: When kernel panics, the prompt "db>" will appear. But at this time I cannot control my computer with keyboard any longer. What's wrong with me? I don't know what's wrong with you, but as regards your computer: disable kbdmux and use a PS/2 keyboard. I've been comforted by you that there's nothing wrong with me. Glad to help :) Well, FreeBSD Developers' Handbook needs to be updated now. No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support "polled" mode :) however, this kbdmux(4) hack will, hopefully, make it work for everyone. http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064727.html thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bug in semctl()
* Maxim Konovalov <[EMAIL PROTECTED]> wrote: > What version of the file do you read? We have a different code in > HEAD. It looks like he's using RELENG_6, src/sys/kern/sysv_sem.c, 1.78. Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpyVMxtlWpTD.pgp Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: > > > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, > > > of course still my main Unix ;-) But it wasn't possible. > > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > it to 8. That's why you can't read it directly. > > Are there plans to bump the default up from 8? I'm honestly torn on > this topic whenever I install a new system. On the one hand I like > having a lot of discrete mountpoints to control potential usage. On > the other hand with drive space being so inexpensive I sometimes > wonder if I need to bother and can get away with very few mountpoints. > > On very large disks (or arrays that appear as a single disk) I have > to create multiple slices in order to get more than 8 mountpoints. Its > an extra hoop to jump through. In most respects it's a pointless change since it just increases the cound from one small number to another one. If you need lots of partitions, gpt is your friend. The only problem with it at this point is that we haven't done the work to boot from it and thus do away with bsdlabels entierly. -- Brooks pgp553vxyVHKB.pgp Description: PGP signature
RE: puc question
> > 20060428: > > The puc(4) driver has been overhauled. The ebus(4) and sbus(4) > > attachments have been removed. Make sure to configure scc(4) > > on sparc64. Note also that by default puc(4) will use uart(4) > > and not sio(4) for serial ports because interrupt handling has > > been optimized for multi-port serial cards and only uart(4) > > implements the interface to support it. > > Does the puc driver now obsoletes sio as it's going to use uart instead? # dmesg -a | egrep 'uart|puc' puc0: port 0x2000-0x201f irq 10 at device 14.0 on pci0 uart0: <16550 or compatible> on puc0 uart1: <16550 or compatible> on puc0 uart2: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart3: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 # I have "nodevice sio" in my kernel config and kldloaded puc.ko and uart.ko. Helge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WINE vs. FreeBSD
On Monday 24 July 2006 21:58, Tijl Coosemans wrote: > On Monday 24 July 2006 18:49, Daniel Eischen wrote: > > On Mon, 24 Jul 2006, Tijl Coosemans wrote: > > > On Monday 24 July 2006 17:39, Daniel Eischen wrote: > > >> On Mon, 24 Jul 2006, Tijl Coosemans wrote: > > >>> I've attached two patches that accomplish this, but this seems to > > >>> trigger other problems, so use at your own risk. If you want to > > >>> try them, place them in the port's files/ directory and add a > > >>> line containing "USE_AUTOTOOLS= autoconf:259" to the Makefile. > > >>> This seems to break wine+libpthread, so I've also changed the > > >>> port to use libthr instead. > > >>> > > >>> For the libpthread experts, I haven't investigated that much > > >>> further yet, but libpthread seems to fail in create_stack() from > > >>> _pthread_create() from _thr_start_sig_daemon(). > > >> > > >> See my response to this in a previous reply to this thread. > > >> libthr and libpthread use LDT's for TLS. WINE is stomping on them > > >> because it doesn't properly create LDTs. This is not a problem > > >> with either of the thread libraries and this issue has been known > > >> ever since we implemented TLS years ago. > > > > > > And as I stated later on in that thread, I don't see where > > > libpthread and libthr still use LDT entries. As far as I understand > > > the code, instead of using an LDT entry per thread (as it sure used > > > to be), only one single GDT entry is used whose base address is > > > updated during a context switch. Looking at the cvs history, it has > > > been working like this since a couple commits of Peter Wemm about a > > > year ago. > > > > > > And if nothing but Wine uses the LDT, Wine's static allocation of > > > LDT entries can't be the problem. > > > > Look, we use %gs for TLS, period. Go see > > libpthread/arch/i386/i386/pthread_md.c for how libpthread does it. > > TLS would not work without setting aside a register for the threads > > library (and rtld) to use. > > Aaagghhh :) > > What you say is true of course, but %gs points to a GDT entry, not LDT. > libpthread and libthr no longer use LDT entries... > > There would be a problem of course if Wine or Windows programs > change %gs. Wine does seem to touch %gs but I've never actually seen it > change. It's always 0x001B, which is the correct value (GUGS_SEL). > > However, Wine/Windows uses %fs for TLS and it appears that the FreeBSD > kernel doesn't preserve it. It always ends up pointing to GUDATA_SEL. The kernel should preserve %fs across syscalls, traps, and faults. Can you point to a specific case where %fs is not preserved? It sounds like %fs is never set to a value in Wine. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A question about ipcperm() call?
On Sunday 23 July 2006 22:07, 李尚杰 wrote:
> The code for ipcperm() call :
> 93 if (mode & IPC_M) {
> 94 error = suser(td);
> 95 if (error)
> 96 return (error);
> 97 }
> 116 if ((mode & perm->mode) != mode) {
> 117 if (suser(td) != 0)
> 118 return (EACCES);
> 119 }
>
> why not directly return the error in line 94?
If suser() returns 0 and you just did 'return(suser(td))' then you would not
perform the additional security check in lines 116-119 which could result in
allowing access to an IPC object when it should be restricted.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bug in semctl()
On Wednesday 26 July 2006 03:50, 李尚杰 wrote:
> In file kern/sysv_sem.c:
> 554 __semctl(td, uap)
> 555 struct thread *td;
> 556 struct __semctl_args *uap;
> 557 {
> 558 int semid = uap->semid; << 559 int semnum = uap->semnum;
> 560 int cmd = uap->cmd;
> 561 u_short *array;
> 562 union semun *arg = uap->arg;
> 563 union semun real_arg;
> 564 struct ucred *cred = td->td_ucred;
> 565 int i, rval, error;
> 566 struct semid_ds sbuf;
> 567 struct semid_kernel *semakptr;
> 568 struct mtx *sema_mtxp;
> 569 u_short usval, count;
> 570
> 571 DPRINTF(("call to semctl(%d, %d, %d, 0x%x)\n",
> 572 semid, semnum, cmd, arg));
> 573 if (!jail_sysvipc_allowed && jailed(td->td_ucred))
> 574 return (ENOSYS);
> 575
> 576 array = NULL;
> 577
> 578 switch(cmd) {
> 579 case SEM_STAT:
> 580 if (semid < 0 || semid >= seminfo.semmni) << 581 return (EINVAL);
> 582 if ((error = copyin(arg, &real_arg,
sizeof(real_arg))) != 0)
> 583 return (error);
> 584 semakptr = &sema[semid];<<
> >From line 558 to line 578, there must be a mechism to convert the
> sem_id to the internal sema array index. In fact, it was missing,
> which make the semctl syscall not work well.
Actually, this is on purpose. SEM_STAT is just used for Linux binaries, and
they apparently specify a kernel semid rather than a user one for this
specific request.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Building a sandboxed kernel
On Saturday 22 July 2006 21:07, R. Tyler Ballance wrote: > I'm working on a project that relies on me building kernels outside > of the standard /usr/src (typically ~/perforce/projects/ ) on my > relatively standard 6.1-STABLE workstation. I'm wondering if I'd be > best suited by setting up a jail for kernel builds, I'm following > this doc: http://people.freebsd.org/~cognet/freebsd_arm.txt loosely > because I've created a new "arch folder" in src/sys for the kernel > code that I want to build (right now it's unmodified i386 code) > > Between varying versions of userland tools (like config(8)) and path > troubles, I'm wondering what tips anybody has to doing non-standard > builds of the kernel (non-standard being not in /usr/src and not the > host arch) > > Currently the make command I'm using, which doesn't work, is (/usr/ > obj is chmod'd 777): > > make TARGET_ARCH=iguana DESTDIR=/home/tyler/iguana buildkernel > > > Any suggestions? For the case where /usr/src is the same branch you can do this (I do this to test-compile cross-builds where the kernel tree isn't in /usr/src/sys): % cd /usr/src % make TARGET_ARCH=amd64 kernel-toolchain % make TARGET_ARCH=amd64 buildkernel KERNSRCDIR=/home/jhb/work/p4/smpng \ NO_KERNELCLEAN=yes -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
Oliver Fromme wrote: > Eric Anderson <[EMAIL PROTECTED]> wrote: > > I'm tired of trying to use rsync or gcp (which doesn't like symlinks > > often) to copy trees of files/directories using hard links, so I added > > the gcp-ish options -a and -l. > > > > -a is 'archive' mode, which is just a quick form of -PpR. > > -P is the default anyway, so -a would only replace -Rp. > I don't think saving one letter justifies introducing a new > option. You can use an alias or shell function. > > > -l is 'link' mode, where regular files get hard linked instead of copied. > > > > So, you can mimic an entire tree with something like: > > > > cp -al /from/ /to/ > > > > and it's fast too! > > You can do the same with existing tools in a portable > (and thus preferable) way: > > cd /from; find -d . | cpio -dumpl /to While I don't want to stifle anyone's creativity, I agree with Oliver (and other posters) on this one. The Unix way of doing things is small programs that do their jobs well, tied together to accomplish bigger things. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > it to 8. That's why you can't read it directly. > > Are there plans to bump the default up from 8? I'm honestly torn on > this topic whenever I install a new system. On the one hand I like > having a lot of discrete mountpoints to control potential usage. On > the other hand with drive space being so inexpensive I sometimes > wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? > On very large disks (or arrays that appear as a single disk) I have > to create multiple slices in order to get more than 8 mountpoints. Its > an extra hoop to jump through. Use gpt on non boot-disks, or use gvinum if you have lots of storage and like the inherent advantage of named labels, striping, and redundancy. I wasn't very happy with gpt or bsdlabel recently because you aren't allowed to modify the partitions if the gpt/bsdlabel is in use (i.e. one of the other partitions is currently mounted as a filesystem). I hope the GEOM people are working to improve this. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A bug in semctl()
* John Baldwin <[EMAIL PROTECTED]> wrote: > Actually, this is on purpose. SEM_STAT is just used for Linux binaries, and > they apparently specify a kernel semid rather than a user one for this > specific request. Yes. Below is a snippet from the semctl(2) manpage on a Linux machine: | SEM_STAT (Linux specific) | Returns a semid_ds structure as for IPC_STAT. However, the | semid argument is not a semaphore identifier, but instead | an index into the kernel's internal array that maintains | information about all semaphore sets on the system. Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgppMFZMAR2RI.pgp Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > > it to 8. That's why you can't read it directly. > > Are there plans to bump the default up from 8? I'm honestly torn on > > this topic whenever I install a new system. On the one hand I like > > having a lot of discrete mountpoints to control potential usage. On > > the other hand with drive space being so inexpensive I sometimes > > wonder if I need to bother and can get away with very few mountpoints. > I would think that cheap disk space would mean larger disks which implies > more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to "deal with the issue" less often. These days, the only technical reason I know of for having separate mountpoints is because you want to run commands that work on filesystems on the two parts with different arguments or under different conditions. > I wasn't very happy with gpt or bsdlabel recently because you aren't > allowed to modify the partitions if the gpt/bsdlabel is in use (i.e. one > of the other partitions is currently mounted as a filesystem). I hope the > GEOM people are working to improve this. Yet another reason for having fewer partitions: you're less likely to want to modify them :-). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
maksim yevmenkin <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > No, kbdmux needs to be fixed so it works in DDB. > actually, atkbd(4) needs to be fixed to support "polled" mode :) It used to work fine before kbdmux(4) came along... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Dag-Erling Smørgrav wrote: maksim yevmenkin <[EMAIL PROTECTED]> writes: Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support "polled" mode :) It used to work fine before kbdmux(4) came along... because it makes certain assumptions about console (i.e. syscons(4)) driver. anyway, the link i posted in previous email contains a patch that should fix problems with kbdmux(4) and atkbd(4) not working in ddb(4), mid-boot (rootfs prompt, geli prompt, etc). so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
On Thursday 27 July 2006 20:40, Dag-Erling Smørgrav wrote: > maksim yevmenkin <[EMAIL PROTECTED]> writes: > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > No, kbdmux needs to be fixed so it works in DDB. > > > > actually, atkbd(4) needs to be fixed to support "polled" mode :) > > It used to work fine before kbdmux(4) came along... > Just a comment: Don't forget to lock Giant before calling anything in the keyboard layer. That means DDB must lock Giant, else at least my new USB keyboard driver will panic, saying Giant is not owned. The old USB keyboard driver did not care about this. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > so far i only got one (successful) report. would people please give > it a try to see if work, so i can commit it. Please commit it. I don't see how it can do any harm. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: DragonFly disklabels allow 16 entries by default, FreeBSD still limits it to 8. That's why you can't read it directly. Are there plans to bump the default up from 8? I'm honestly torn on this topic whenever I install a new system. On the one hand I like having a lot of discrete mountpoints to control potential usage. On the other hand with drive space being so inexpensive I sometimes wonder if I need to bother and can get away with very few mountpoints. I would think that cheap disk space would mean larger disks which implies more mountpoints ??? Nope. One of the historical uses of partitions was to act as firewalls between subsystems, so that subsystem A running out of space didn't cause subsystem B to die for lack of space. This had the downside of making it more likely that one of the two would run out of space because the excess space from another subsystem could only be used by it. With cheap disk space, you overallocate by enough to give you plenty of warning before you have to deal with the issue. You can safely share that space, and doing so means you have to "deal with the issue" less often. You assume that "running out of space" happens over time, but with some runaway process logging to a file, for example, the partition filling up will still happen without you expecting it. It might take a bit longer with a big disk, but 20 minutes instead of 5 minutes isn't much different in terms of warning. Fill /tmp or /var and many things can fail. Fill /home and it's just users who suffer a little but mail, demons etc. just carry on. A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. In some environments, fewer partitions may indeed be the new norm, but in others it would not. Personally, I would like a limit of 16. It would mean that I could fit all my regular partitions inside a single slice, freeing up other slices for, for example, experimenting with 64-bit, or -current, or whatever. Bootable FreeBSD slices will be stuck at 4 for the foreseeable future - extending the number of partitions within a slice frees up slices, which are the really limited resource. I have no real idea how hard it would be to extend from 8 to 16, but if the effort required were reasonably low, then it would get my vote. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > > On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > > > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > > > it to 8. That's why you can't read it directly. > > > Are there plans to bump the default up from 8? I'm honestly torn on > > > this topic whenever I install a new system. On the one hand I like > > > having a lot of discrete mountpoints to control potential usage. On > > > the other hand with drive space being so inexpensive I sometimes > > > wonder if I need to bother and can get away with very few mountpoints. > > I would think that cheap disk space would mean larger disks which implies > > more mountpoints ??? > > Nope. One of the historical uses of partitions was to act as firewalls > between subsystems, so that subsystem A running out of space didn't > cause subsystem B to die for lack of space. This had the downside of > making it more likely that one of the two would run out of space > because the excess space from another subsystem could only be used by > it. With cheap disk space, you overallocate by enough to give you > plenty of warning before you have to deal with the issue. You can > safely share that space, and doing so means you have to "deal with the > issue" less often. > > These days, the only technical reason I know of for having separate > mountpoints is because you want to run commands that work on > filesystems on the two parts with different arguments or under > different conditions. Well I still prefer to "design" my filesystems no matter how big disks are. So I have better control of what needs backup using dump and when I need to restore parts of my disk its also quicker and more reliable to restore a subtree. Also I'd gues that its still valid that less file movement in root filesystem increases robustness if you have a power outage. Same true for other important filesystems. Also it makes it easier to upgrade a system, since you only nail / and /usr, if the rest is in other filesystems. Also its easier to newfs "/" and "/usr", if "/var", "/usr/local" and "/usr/X11R6", "/home", ... are on differnet filesystems. Also you can increase system performance by choosing bigger block and frag size in filesystems with bigger files on average. If you have a news filesystem you perhaps want to finetune settings of filesystem to have more inodes available ... You see, I think there is still demand for using many filesystems if you are open minded for having the best support in every "shitty" situation ;-) Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: > > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, > > of course still my main Unix ;-) But it wasn't possible. > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > it to 8. That's why you can't read it directly. > Hmm, for the sake of compatibility, wouldn't it have been an option, to add this extra bit to the end of the struct ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Hans Petter Selasky wrote: On Thursday 27 July 2006 20:40, Dag-Erling Smørgrav wrote: maksim yevmenkin <[EMAIL PROTECTED]> writes: Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support "polled" mode :) It used to work fine before kbdmux(4) came along... Just a comment: Don't forget to lock Giant before calling anything in the keyboard layer. That means DDB must lock Giant, else at least my new USB keyboard driver will panic, saying Giant is not owned. The old USB keyboard driver did not care about this. well, there is more work to it, imo. we will have to address this when new usb sub-system comes into the three. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Michael R. Wayne <[EMAIL PROTECTED]> typed: > On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: > > These days, the only technical reason I know of for having separate > > mountpoints is because you want to run commands that work on > > filesystems on the two parts with different arguments or under > > different conditions. > Or you want to run a bunch of jails. You don't need mount points to run jails. In fact, the man page (on 5.5, anyway) provides examples that *break* if you put the jails on a separate mount point. > Or you want to give a bunch > of users a big chunk of space and > quotas are a bad fit. That's a social reason, not a technical one. That used to be really common as well, but these days "a bunch of users" tend to get their own machine. In <[EMAIL PROTECTED]>, Alex Zbyslaw <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > >In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > >>On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote: > >>>On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > it to 8. That's why you can't read it directly. > >>>Are there plans to bump the default up from 8? I'm honestly torn on > >>>this topic whenever I install a new system. On the one hand I like > >>>having a lot of discrete mountpoints to control potential usage. On > >>>the other hand with drive space being so inexpensive I sometimes > >>>wonder if I need to bother and can get away with very few mountpoints. > >>I would think that cheap disk space would mean larger disks which implies > >>more mountpoints ??? > >Nope. One of the historical uses of partitions was to act as firewalls > >between subsystems, so that subsystem A running out of space didn't > >cause subsystem B to die for lack of space. This had the downside of > >making it more likely that one of the two would run out of space > >because the excess space from another subsystem could only be used by > >it. With cheap disk space, you overallocate by enough to give you > >plenty of warning before you have to deal with the issue. You can > >safely share that space, and doing so means you have to "deal with the > >issue" less often. > You assume that "running out of space" happens over time, but with some > runaway process logging to a file, for example, the partition filling up > will still happen without you expecting it. It might take a bit longer > with a big disk, but 20 minutes instead of 5 minutes isn't much > different in terms of warning. Yes, I'm assuming that "running out of space" happens over time. Sustained I/O speeds on modern hardware was around 100MB/sec last time I looked. So a good, large disk - say a terabyte raid (you need raid to get those performance numbers, so call it 2 500GB disks to keep it simple) - will take about three hours to fill *if you do nothing but write to the disk*. A runaway process - especially one generating log data - is normally doing other things that it's trying to log information about. A typical installation will have smaller, slower disks. A high-end installation with faster disks will almost certainly have lots more space as well. So it's perfectly reasonable to rely on disks to not fill up in a matter of minutes. In practice, log files are several orders of magnitude smaller than the actual data dealt with by most application. A few hundred megabytes is more than adequate log space for most systems, with runaway processes filling them in a day or so. So I give those systems a gigabyte of log space, 'cause disk is *cheap*. And yes, I separate /var from /home and /usr, but not because I'm worried about them running out of space. > Fill /tmp or /var and many things can fail. Fill /home and it's just > users who suffer a little but mail, demons etc. just carry on. You're being inconsistent. Log files normally go on /var, so if you fill that, your demons may well fail, depending on how they react to not being able to log messages. On the other hand, for some demons it makes sense to treat their data just like any other user data, so they'd be on /home, and suddenly they're failing when /home fills up. I had a system fall over for lack of disk space this month. It was an old system, that only had 16GB of disk for file storage, and the 300GB drive upgrade had already been ordered. It's a four-core 3GHz opteron system, doing ETL processing as fast as it's little chips can cycle. It took *five hours* to fill up when half of the data started collecting on it instead of being loaded into the database. If it had had the disk upgrade, it would have take a couple of days. > A further reason to separate partitions is that dump works at the level > of a partition. Different partitions may have very different backup > requirements, and for those of us without huge tape drives, partitioning > to a size that can be dumped on one tape makes life easie
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Andreas Klemm <[EMAIL PROTECTED]> typed: > On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote: > > These days, the only technical reason I know of for having separate > > mountpoints is because you want to run commands that work on > > filesystems on the two parts with different arguments or under > > different conditions. > Well I still prefer to "design" my filesystems no matter how big > disks are. Yes, and most of those qualify as needing to "run commands that workon filesystems on the two parts with different arguments ...". > Also I'd gues that its still valid that less file movement > in root filesystem increases robustness if you have a power outage. > Same true for other important filesystems. Actually, it one of the FS gurus convincing me that this was no longer true that converted me to the idea that reducing the file system count was a good idea. What you say was certainly true for 4.2BSD, but when was the last time you saw an entire file system toasted when something failed hard? Or even significant damage to files that weren't actually in transit at the time? I know the last time it happened to me - it was over a decade ago. I had a desktop Solaris box I'd set up as web server because the IT department was a typical IT department. So it wasn't on batteries like every other server in the place. We took a power hit, and it crashed hard. Power came back, and it started fsck'ing it's file system. Partway through that we got a *second* power hit, so it crashed hard in the middle of fsck'ing. This power outage lasted long enough that the backup generators kicked in, so it came back up and started fsck'ing again. At which piont the backup generators cut out, because they hadn't been refueled after the last outage. So it crashed hard *again* in the middle of fsck'ing the file system. The file system was unrecoverable. > Also it makes it easier to upgrade a system, since you only nail > / and /usr, if the rest is in other filesystems. > > Also its easier to newfs "/" and "/usr", if "/var", "/usr/local" > and "/usr/X11R6", "/home", ... are on differnet filesystems. Right. I typically install / and /usr as distinct files systems for just that reason (/ and /usr have different backup & recovery strategies and I use dump, so that's why they are two partitions). So why does / need to be different from /var, /usr different from /usr/X11R6 and /home different from /usr/local? Seriously now - what I just described is my typical install. > You see, I think there is still demand for using many filesystems > if you are open minded for having the best support in every "shitty" > situation ;-) Well, there are always special cases. But hardware is so cheap these days, I'm used to fine-tuning the *system*, not just the partition. If something is so critical that it needs it's own partition, it's probably so critical that it needs it's own system as well. In fact, most of the thing I work on these days are so critical that they need several systems, half of them at a second site with automatic failover between them. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WINE vs. FreeBSD
On Thursday 27 July 2006 17:21, John Baldwin wrote: > On Monday 24 July 2006 21:58, Tijl Coosemans wrote: > > However, Wine/Windows uses %fs for TLS and it appears that the > > FreeBSD kernel doesn't preserve it. It always ends up pointing to > > GUDATA_SEL. > > The kernel should preserve %fs across syscalls, traps, and faults. > Can you point to a specific case where %fs is not preserved? It > sounds like %fs is never set to a value in Wine. Yes, it was a combination of compiler optimizations and an inline assembly block missing __volatile__. pgpwq6J5daZJN.pgp Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 10:25:28PM +0200, Andreas Klemm wrote: > On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: > > On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: > > > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, > > > of course still my main Unix ;-) But it wasn't possible. > > > > DragonFly disklabels allow 16 entries by default, FreeBSD still limits > > it to 8. That's why you can't read it directly. > > > > Hmm, for the sake of compatibility, wouldn't it have been an option, > to add this extra bit to the end of the struct ? The layout of the struct has not changed. FreeBSD simply rejects the disk label because the number of entries is too large. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] adding two new options to 'cp'
On Thursday 27 July 2006 13:44, Doug Barton wrote: > Oliver Fromme wrote: > > Eric Anderson <[EMAIL PROTECTED]> wrote: > > > I'm tired of trying to use rsync or gcp (which doesn't like symlinks > > > often) to copy trees of files/directories using hard links, so I added > > > the gcp-ish options -a and -l. > > > > > > -a is 'archive' mode, which is just a quick form of -PpR. > > > > -P is the default anyway, so -a would only replace -Rp. > > I don't think saving one letter justifies introducing a new > > option. You can use an alias or shell function. > > > > > -l is 'link' mode, where regular files get hard linked instead of copied. > > > > > > So, you can mimic an entire tree with something like: > > > > > > cp -al /from/ /to/ > > > > > > and it's fast too! > > > > You can do the same with existing tools in a portable > > (and thus preferable) way: > > > > cd /from; find -d . | cpio -dumpl /to > > While I don't want to stifle anyone's creativity, I agree with Oliver (and > other posters) on this one. The Unix way of doing things is small programs > that do their jobs well, tied together to accomplish bigger things. OTOH, 'cp -al' is a lot less to type. :) It also is not NIH as it is simulating the interface of another system. Maybe I'm just stodgy b/c I never use cpio(8) (it seems to be one of the more cryptic programs). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thursday 27 July 2006 16:58, Mike Meyer wrote:
> Right. I typically install / and /usr as distinct files systems for
> just that reason (/ and /usr have different backup & recovery
> strategies and I use dump, so that's why they are two partitions). So
> why does / need to be different from /var, /usr different from
> /usr/X11R6 and /home different from /usr/local? Seriously now - what I
> just described is my typical install.
In my case I still have /home in /usr/home, but I should start making it
separate in the hope that I could mount /usr read-only most of the time
reducing the time it takes to fsck when I crash my test machines. This is
peculiar to an environ where one expects to crash a lot though. :) Even so,
I would be looking at /, /usr, /var, /tmp, /home, and swap. Still under 7
('c' is reserved).
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
On Thursday 27 July 2006 15:04, Hans Petter Selasky wrote: > On Thursday 27 July 2006 20:40, Dag-Erling Smørgrav wrote: > > maksim yevmenkin <[EMAIL PROTECTED]> writes: > > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > > No, kbdmux needs to be fixed so it works in DDB. > > > > > > actually, atkbd(4) needs to be fixed to support "polled" mode :) > > > > It used to work fine before kbdmux(4) came along... > > > > Just a comment: Don't forget to lock Giant before calling anything in the > keyboard layer. That means DDB must lock Giant, else at least my new USB > keyboard driver will panic, saying Giant is not owned. The old USB keyboard > driver did not care about this. DDB should not be acquiring locks or depend on being able to do so. When you panic the machine is an unknown state for one, and you really want to leave the overall system state as undisturbed as possible while in the debugger to aid in debugging. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: You assume that "running out of space" happens over time, but with some runaway process logging to a file, for example, the partition filling up will still happen without you expecting it. It might take a bit longer with a big disk, but 20 minutes instead of 5 minutes isn't much different in terms of warning. Yes, I'm assuming that "running out of space" happens over time. Sustained I/O speeds on modern hardware was around 100MB/sec last time I looked. So a good, large disk - say a terabyte raid (you need raid to get those performance numbers, so call it 2 500GB disks to keep it simple) - will take about three hours to fill *if you do nothing but write to the disk*. A runaway process - especially one generating log data - is normally doing other things that it's trying to log information about. I don't have terabyte raids and for me a "big" disk is 250Gb. A runaway system demon writing to disk might well do other things. A badly written user program might do nothing but write to disk. If you run servers that just run a bunch of standard ports and system demons, then this is unlikely to happen to you. If you work in an environment where one or more fallible programmers churn through gigabytes of data it's depressingly easy to accidentally do *nothing* but write to disk. A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. That's one of the technical reasons I mentioned in the part you didn't quote. To my mind, it only takes *one* technical reason. If I need multiple partitions to make backups easy, then arguments about log files are irrelevant :-) Well, there are always special cases. But hardware is so cheap these days, I'm used to fine-tuning the *system*, not just the partition. If something is so critical that it needs it's own partition, it's probably so critical that it needs it's own system as well. In fact, most of the thing I work on these days are so critical that they need several systems, half of them at a second site with automatic failover between them. Not everyone is in a position to throw money at everything and what's cheap to you isn't cheap to everyone. I can't possibly justify one system for everything that needs a partition, nor do I even feel the need to do that. If anything, it would be a major inconvenience. Frankly, if you're really worried about bootable slices, you should be advocating giving FreeBSD the ability to boot from a logical volume. Who said I didn't? I have no objection to such a facility and would welcome it. It just imagined that extending the number of partitions from 8 to 16 would have been easier than booting from logical slices. If booting from logical slices is easier then I'm all for it. --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WINE vs. FreeBSD
Tijl Coosemans wrote: On Thursday 27 July 2006 17:21, John Baldwin wrote: On Monday 24 July 2006 21:58, Tijl Coosemans wrote: However, Wine/Windows uses %fs for TLS and it appears that the FreeBSD kernel doesn't preserve it. It always ends up pointing to GUDATA_SEL. The kernel should preserve %fs across syscalls, traps, and faults. Can you point to a specific case where %fs is not preserved? It sounds like %fs is never set to a value in Wine. Yes, it was a combination of compiler optimizations and an inline assembly block missing __volatile__. does this mean that wine will work from now on? i.e. is the fix being fed back into wine sources? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Alex Zbyslaw <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > >> You assume that "running out of space" happens over time, but with some > >>runaway process logging to a file, for example, the partition filling up > >>will still happen without you expecting it. It might take a bit longer > >>with a big disk, but 20 minutes instead of 5 minutes isn't much > >>different in terms of warning. > >Yes, I'm assuming that "running out of space" happens over > >time. Sustained I/O speeds on modern hardware was around 100MB/sec > >last time I looked. So a good, large disk - say a terabyte raid (you > >need raid to get those performance numbers, so call it 2 500GB disks > >to keep it simple) - will take about three hours to fill *if you do > >nothing but write to the disk*. A runaway process - especially one > >generating log data - is normally doing other things that it's trying > >to log information about. > I don't have terabyte raids and for me a "big" disk is 250Gb. In that case, you don't get 100MB/sec of throughput, either. Even if you've got a relatively fast single disk, you're going to be getting maybe 50MB/sec of throughput. So it's *still* going to take hours to fill the disk even if you do nothing but write to disk. And to complete the reprise of the paragraph you elided, if you've got a system that gets a lot more than 100MB/sec to disk, you almost certainly have a lot more disk than a terabyte. > A runaway system demon writing to disk might well do other things. A > badly written user program might do nothing but write to disk. If you > run servers that just run a bunch of standard ports and system demons, > then this is unlikely to happen to you. If you work in an environment > where one or more fallible programmers churn through gigabytes of data > it's depressingly easy to accidentally do *nothing* but write to disk. You know, that's exactly the kind of environment I work in. We churn through gigaROWS of data. We have processes whose sole job is to pull data and write it to disk. Even major failures (like losing the network connection to half the consumer machines) don't cause the disk to fill in minutes. More like days on a properly configured machine. That's because, even if your system is spending *all* of it's time doing nothing but writing to the disk, it'll take hours to fill the disk given most modern disk configurations. Disks have gotten bigger faster than they've gotten faster. So while you used to be able to fill a disk in minutes (or could you?), it takes a really strange configuration to do that now. > >> A further reason to separate partitions is that dump works at the level > >> of a partition. Different partitions may have very different backup > >> requirements, and for those of us without huge tape drives, partitioning > >> to a size that can be dumped on one tape makes life easier. > >That's one of the technical reasons I mentioned in the part you > >didn't quote. > To my mind, it only takes *one* technical reason. If I need multiple > partitions to make backups easy, then arguments about log files are > irrelevant :-) If you're going to count 1, 2, many, then we already have "many" partitions, and don't need more. Once you get into finer distinctions of "many", you need to figure out which reasons are actually valid, and which are spurious, so you can pick from among those manys. > >Well, there are always special cases. But hardware is so cheap these > >days, I'm used to fine-tuning the *system*, not just the partition. > >If something is so critical that it needs it's own partition, it's > >probably so critical that it needs it's own system as well. In fact, > >most of the thing I work on these days are so critical that they need > >several systems, half of them at a second site with automatic failover > >between them. > Not everyone is in a position to throw money at everything and what's > cheap to you isn't cheap to everyone. Boxes are cheaper than disk space - my last two low-end boxes cost less than my last small disk drive, even though I ordered them all about the same time. If you can afford the disk for some process, then chances are good you can afford a system instead, or as well. > I can't possibly justify one system for everything that needs a > partition, nor do I even feel the need to do that. If anything, it > would be a major inconvenience. My claim is that your "everything that needs a partition" probably includes things that don't. But to prove that, we need to examine the reasons you think those things need a partition. I believe the only one you've given so far - as a space firewall - is specious. Your arguments remind me of the environments I worked on in the 70s and 80s. Minis and mainframes that did all the computing for an organization. All the daemons that talked to the outside world ran on the same box as the developers ran compiles and tests on, etc. While that worked really well when it came to g
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: A further reason to separate partitions is that dump works at the level of a partition. Different partitions may have very different backup requirements, and for those of us without huge tape drives, partitioning to a size that can be dumped on one tape makes life easier. That's one of the technical reasons I mentioned in the part you didn't quote. To my mind, it only takes *one* technical reason. If I need multiple partitions to make backups easy, then arguments about log files are irrelevant :-) If you're going to count 1, 2, many, then we already have "many" partitions, and don't need more. Once you get into finer distinctions of "many", you need to figure out which reasons are actually valid, and which are spurious, so you can pick from among those manys. I have no real idea what this means, sorry. It seems to me that whoever made the initial decision to stop at 8 (size of an integer?) clearly thought counting past 2 was worthwhile. Maybe the original reasons no longer apply since quite a lot has changed since then :-) Well, there are always special cases. But hardware is so cheap these days, I'm used to fine-tuning the *system*, not just the partition. If something is so critical that it needs it's own partition, it's probably so critical that it needs it's own system as well. In fact, most of the thing I work on these days are so critical that they need several systems, half of them at a second site with automatic failover between them. Not everyone is in a position to throw money at everything and what's cheap to you isn't cheap to everyone. Boxes are cheaper than disk space - my last two low-end boxes cost less than my last small disk drive, even though I ordered them all about the same time. If you can afford the disk for some process, then chances are good you can afford a system instead, or as well. I don't understand this either. Surely the box has to include the disk space so how can it cost less? If it costs less because it's a cheap piece of junk, why would I even want it? And the "cost" of the system doesn't stop at the up front price - running costs including maintaining the box surely count (not to mention that I have nowhere to put the damn thing). And I'm not sure where needing a separate partition and criticality became the same thing. I don't claim to want or need separate partitions because any particular subset of the filesystem is critical, but because I want it to be separate for at least the two reasons outlined below. I can't possibly justify one system for everything that needs a partition, nor do I even feel the need to do that. If anything, it would be a major inconvenience. My claim is that your "everything that needs a partition" probably includes things that don't. But to prove that, we need to examine the reasons you think those things need a partition. I believe the only one you've given so far - as a space firewall - is specious. Except that we also have the "dump", and the "different params for different parts of the filesystem" arguments. I think you agreed that you counted those as technical reasons. Your arguments remind me of the environments I worked on in the 70s and 80s. Minis and mainframes that did all the computing for an organization. All the daemons that talked to the outside world ran on the same box as the developers ran compiles and tests on, etc. While that worked really well when it came to generating a robust OS, I haven't seen an environment like that in decades. Hell, most of my clients would shit bricks at the thought of putting their source or data on a machine that could be reached from the internet at large at all. Every developler has a box - or three - on their desks. The ETL boxes are distinct from the database boxes are distinct from the internal mail server is distinct from the external mail server, etc. If I want to have a process send email notices about something, I usually have to beat on them if I want a mail server on the box. And so on Fine. You have access to lots of money and infrastructure. I don't. Throwing money at a problem is not a solution available to everyone. Frankly, if you're really worried about bootable slices, you should be advocating giving FreeBSD the ability to boot from a logical volume. Who said I didn't? I have no objection to such a facility and would welcome it. It just imagined that extending the number of partitions from 8 to 16 would have been easier than booting from logical slices. If booting from logical slices is easier then I'm all for it. You're not asking the right question just yet. The question shouldn't be "which is easier to add", but "which provides the most benefit for the least pain" (which subsumes the pain involved in adding it). I believe that the benefits of adding more partitions per slice are minimal - there are at least three ways to add m
Any success with bacula and DVD
Is anybody successfully using bacula with DVD? When I install the bacula-server port, it cannot pass even the trivial "btape FileStorage/temp" test, let alone trying to write to DVD. Advice cheerfully accepted! -- George Mitchell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WINE vs. FreeBSD
On Thursday 27 July 2006 23:53, Julian Elischer wrote: > Tijl Coosemans wrote: > > On Thursday 27 July 2006 17:21, John Baldwin wrote: > > > The kernel should preserve %fs across syscalls, traps, and faults. > > > Can you point to a specific case where %fs is not preserved? It > > > sounds like %fs is never set to a value in Wine. > > > > Yes, it was a combination of compiler optimizations and an inline > > assembly block missing __volatile__. > > does this mean that wine will work from now on? > i.e. is the fix being fed back into wine sources? Not yet. Windows9x mode should work again as well as threading and TLS, but there are still some open issues, mainly with exception handling and file access. Exception handling was completely broken and is now mostly working, but sometimes gets stuck in a loop generating exceptions and eventually overflowing the stack. I'll submit patches once Wine passes the most important unit tests, unless someone already wants to have a look at them of course... pgpeDoM6mVXmd.pgp Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
Mike Meyer wrote: >Boxes are cheaper than disk space - my last two low-end boxes cost >less than my last small disk drive, even though I ordered them all >about the same time. If you can afford the disk for some process, then >chances are good you can afford a system instead, or as well. I'm not sure how that's even possible. A quick glance at newegg.com: $17.99 (+$6.13) [recertified] socket A motherboard $39.99 [oem] AMD Duron socket A processor $13.99 (+$4.99) 128MB RAM === $71.97 (+$11.12 shipping) = $83.09. This is assuming you have an extra case, power supply, and video card to throw in it. What do you consider a "small disk drive"? Newegg has a 40G for $39.99 + $5.64 shipping. Yeah, so small disk drives seem to be half the price of the cheapest possible "box". Feel free to enlighten me, I'd love to know where you shop that has a system under US$50 ! -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > >Boxes are cheaper than disk space - my last two low-end boxes cost > >less than my last small disk drive, even though I ordered them all > >about the same time. If you can afford the disk for some process, then > >chances are good you can afford a system instead, or as well. > > I'm not sure how that's even possible. A quick glance at newegg.com: > > $17.99 (+$6.13) [recertified] socket A motherboard > $39.99[oem] AMD Duron socket A processor > $13.99 (+$4.99) 128MB RAM > === > $71.97 (+$11.12 shipping) = $83.09. > > This is assuming you have an extra case, power supply, and video card to > throw in it. What do you consider a "small disk drive"? Newegg has a 40G > for $39.99 + $5.64 shipping. Yeah, so small disk drives seem to be half > the price of the cheapest possible "box". Feel free to enlighten me, I'd > love to know where you shop that has a system under US$50 ! "Small disk drive" means "smaller than any drive I can buy at the local Best Buy/Circuit City/CompUSA/similar". At the time, I needed an 80GB drive, and paid about $60 for it. Try http://www.pcretro.com/. Their current special is the Dell PowerEdge 6350 (dual CPU, 255MB ram, 2 9GB hot swap drives on separate controllers) for $49.95. The boxes I bought had a mouse and keyboard included, no monitor or speakers. Not that I cared - I tossed the mouse and keyboard on the spare parts pile and plugged them into a KVM. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 5.5 and software timers
In message: <[EMAIL PROTECTED]>
Michael Scheidell <[EMAIL PROTECTED]> writes:
: Found it! library libc_r
:
: Given POC:
:
: int main( int argc, char **argv )
: {
: char execs1[256] = "/bin/date +A%Y%m%d%H%M.%S";
: char execs2[256] = "/bin/date +B%Y%m%d%H%M.%S";
: int a;
:
: while ( 1) {
:
: system( execs1 );
: usleep( 500*1000);
: system( execs2 );
: }
:
: return 0;
: } /* main */
:
: compile with:
: cc -g -c nanotest.c
: cc -g -o nanotest nanotest.o
:
: everything works as expected.
:
: time forward, back, doesn't matter (date prints out wallclock,
: nanosleep() sleeps 500*1000*1000us (.5 seconds)
:
: this breaks it:
: cc -g -c nanotest.c
: cc -g -o nanotest nanotest.o -lc_r
:
: setting clock back 'hangs' during usleep (500*1000)
: didn't hang on 5.4.
: I will be writing up a bug report shortly.
libc_r depends on absolute system time to do its sleeps and timeouts,
and has since FreeBSD 3.4. This dependency has been the result of
many conversations over time, and has had several patches posted.
Since libc_r is dead technology, there's little chance they will be
adopted.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Programs not accepting input?
On 07/21/2006 08:32, Robert Watson wrote: On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote: I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. I've occasionally also had weird focus problems with KDE. Among other things, it looks like occasionally the mouse release event is lost somewhere in the system (or something along these lines) -- I don't know if it's a driver problem, a moused problem, an X11 probem, or a KDE problem. If I press and release each of the buttons, especially the third button, things will often recover. As long as the button is "held down", KDE doesn't switch the focus and other events are largely ignored. Odd, eh? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I think I'm seeing something similar (not sure) so I thought I'd mention it. I can repeat the effect on demand. If I open my opera browser it launches a weather widget. If I then open a terminal (aterm in this case) and give it focus, everything is good. If I bring my mouse over the widget, it appears to capture the keybaord input. My terminal cursor goes to an empty square. (My window manager is not setup to have the focus follow the mouse. I focus on clicks.) My terminal window is still highlighted as if it actually has focus. If I then click on the terminal window, or within the window in an attempt to give it focus... I still can not type in it (the cursor is still hollow). Keypresses affect the widget only at this point. The only way is to either pick a third window, or actually click in the widget, and then back to the terminal. In fact I've done the same thing with the composing of this e-mail. The focus can be stolen from this "compose" window in a similar fashion. I've only just started using this widget today, so this is the first time I've come across this effect. If you think this is a similar problem... and there is anything I could do to help examine it, let me know. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any success with bacula and DVD
On Thu, 27 Jul 2006 17:11:11 -0700 (PDT) [EMAIL PROTECTED] mentioned: > Is anybody successfully using bacula with DVD? When I install the > bacula-server port, it cannot pass even the trivial > "btape FileStorage/temp" test, let alone trying to write to DVD. > Advice cheerfully accepted! -- George Mitchell > I don't use bacula actually, but, IMO, this problem is linked with burncd's inability to work with DVDs. Try to install dvd+rw tools and point bacula to use them. Also try to contact with bacula port maintainer. PS: freebsd-ports@freebsd.org is better suited for this question. -- Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]> Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 05:34:23PM -0400 I heard the voice of John Baldwin, and lo! it spake thus: > On Thursday 27 July 2006 16:58, Mike Meyer wrote: > > Right. I typically install / and /usr as distinct files systems > > for just that reason (/ and /usr have different backup & recovery > > strategies and I use dump, so that's why they are two partitions). > > So why does / need to be different from /var, /usr different from > > /usr/X11R6 and /home different from /usr/local? Seriously now - > > what I just described is my typical install. > > In my case I still have /home in /usr/home, but I should start > making it separate in the hope that I could mount /usr read-only > most of the time reducing the time it takes to fsck when I crash my > test machines. I have / and /usr [sometimes one partition] mounted read-only on many of my systems. I like the peace of mind of KNOWING nothing'll go wonky on 'em on a crash, I like the shorter fsck times, I kinda like knowing there's that extra (very thin, but still extant) layer of protection against a lot of automated attacks... And, darnit, it just feels cleaner. I tend to have separate /var, /tmp, /home, and /usr/local which are kept rw since they have live and constantly-fiddled data on them, but everything else generally ends up ro since I only need to write them at specific discrete times. Out of the 11 partitions (multiple disks) on my workstation, only those 4 are generally rw. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
