Addition to reboot(8): reboot / halt reasons

[Christopher Nehren]

While playing around with Win2K3 recently, I noticed that it brings up a
dialog at every reboot / shutdown and asks for a reason for said reboot
/ shutdown. So I was bored tonight, and decided to implement that
feature in FreeBSD's reboot(8) with a -r flag. Here's a diff against a
-CURRENT reboot.c, checked out about five minutes ago.
--- reboot.c.oldSat May  3 14:41:59 2003
+++ reboot.cMon Sep  1 22:23:56 2003
@@ -69,9 +69,10 @@
 main(int argc, char *argv[])
 {
struct passwd *pw;
-   int ch, howto, i, fd, kflag, lflag, nflag, qflag, pflag, sverrno;
+   int ch, howto, i, fd, kflag, lflag, nflag, qflag, pflag, rflag;
+   int sverrno;
u_int pageins;
-   char *kernel, *p;
+   char *kernel, *p, *reason;
const char *user;
 
if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) {
@@ -79,8 +80,8 @@
howto = RB_HALT;
} else
howto = 0;
-   kflag = lflag = nflag = qflag = 0;
-   while ((ch = getopt(argc, argv, "dk:lnpq")) != -1)
+   kflag = lflag = nflag = qflag = rflag = 0;
+   while ((ch = getopt(argc, argv, "dk:lnpqr:")) != -1)
switch(ch) {
case 'd':
howto |= RB_DUMP;
@@ -103,6 +104,10 @@
case 'q':
qflag = 1;
break;
+   case 'r':
+   rflag = 1;
+   reason = optarg;
+   break;
case '?':
default:
usage();
@@ -140,10 +145,10 @@
pw->pw_name : "???";
if (dohalt) {
openlog("halt", 0, LOG_AUTH | LOG_CONS);
-   syslog(LOG_CRIT, "halted by %s", user);
+   syslog(LOG_CRIT, "halted by %s: %s", user, rflag ? reason : 
"no reason");
} else {
openlog("reboot", 0, LOG_AUTH | LOG_CONS);
-   syslog(LOG_CRIT, "rebooted by %s", user);
+   syslog(LOG_CRIT, "rebooted by %s: %s", user, rflag ? reason : 
"no reason");
}
}
logwtmp("~", "shutdown", "");
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Addition to reboot(8): reboot / halt reasons

[Sean Kelly]

On Mon, Sep 01, 2003 at 10:25:42PM -0400, Christopher Nehren wrote:
> While playing around with Win2K3 recently, I noticed that it brings up a
> dialog at every reboot / shutdown and asks for a reason for said reboot
> / shutdown. So I was bored tonight, and decided to implement that
> feature in FreeBSD's reboot(8) with a -r flag. Here's a diff against a
> -CURRENT reboot.c, checked out about five minutes ago.

Err.. Wouldn't it just be easier to use the `shutdown` command?
I suggest you check `man 8 shutdown` out.

SYNOPSIS
 shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]

-- 
Sean Kelly  | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.sean-kelly.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Peter Jeremy]

On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote:
>Has it ever been suggested to create one or more "dependencies"
>ports (or more to the point, packages)?  I think it might be pretty
>useful to have something like that so that all of the "prerequisites"
>can be installed at once.

Maybe I'm missing something but how would that be an improvement on
what FreeBSD does now?  If I try to install package X, it will
automatically install dependencies A, B and C, as well as their
dependencies.

Peter

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Multiple keyboards for syscons?

[Geoff Buckingham]

I am trying to find a way to use two keyboards with syscons, something
like:

mkfifo /tmp/mykbds
cat /dev/kbd1 >/tmp/mykbds &
cat /dev/kbd2 >/tmp/mykbds &
kbdcontrol -k /tmp/mykbds http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Ugly Huge BSD Monster

[Sten Daniel Sørsdal]

> 
> On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote:
> >Has it ever been suggested to create one or more "dependencies"
> >ports (or more to the point, packages)?  I think it might be pretty
> >useful to have something like that so that all of the "prerequisites"
> >can be installed at once.
> 
> Maybe I'm missing something but how would that be an improvement on
> what FreeBSD does now?  If I try to install package X, it will
> automatically install dependencies A, B and C, as well as their
> dependencies.
> 

That would ease the installation of port X on Y number of machines.
Same libraries, same everything, precompiled.
Otherwise one needs to manually track dependencies (not a terribly
difficult job) and make those as packages, and keep doing this until
all dependencies are as packages (in my case, i have several 
light-weight servers/routers that have no gcc/make capabilities).

If anyone knows of a program/script that will do this for me, please speak up!

- Sten
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Igor Pokrovsky]

On Tue, Sep 02, 2003 at 01:07:34PM +0200, Sten Daniel S?rsdal wrote:
> > 
> > On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote:
> > >Has it ever been suggested to create one or more "dependencies"
> > >ports (or more to the point, packages)?  I think it might be pretty
> > >useful to have something like that so that all of the "prerequisites"
> > >can be installed at once.
> > 
> > Maybe I'm missing something but how would that be an improvement on
> > what FreeBSD does now?  If I try to install package X, it will
> > automatically install dependencies A, B and C, as well as their
> > dependencies.
> > 
> 
> That would ease the installation of port X on Y number of machines.
> Same libraries, same everything, precompiled.
> Otherwise one needs to manually track dependencies (not a terribly
> difficult job) and make those as packages, and keep doing this until
> all dependencies are as packages (in my case, i have several 
> light-weight servers/routers that have no gcc/make capabilities).
> 
> If anyone knows of a program/script that will do this for me, please speak up!
I guess you can easily build packages recursively with portupgrade.
And no need to track dependencies manually.

-ip

-- 
You cannot propel yourself forward by patting yourself on the back.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Addition to reboot(8): reboot / halt reasons

[Christopher Nehren]

On Tue, 2003-09-02 at 00:36, Sean Kelly wrote:
> Err.. Wouldn't it just be easier to use the `shutdown` command?
> I suggest you check `man 8 shutdown` out.

I'll concede and admit that I should have RTFM'd. But in the same vein,
if shutdown(8) provides the functionality of halt(8) and reboot(8), why
do they exist as separate programs? I'm probably missing something here,
but wouldn't it be easier to just combine shutdown and reboot / halt, as
reboot and halt already are?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Addition to reboot(8): reboot / halt reasons

[Daniel Lang]

Hi,

Christopher Nehren wrote on Tue, Sep 02, 2003 at 08:55:23AM -0400:
> On Tue, 2003-09-02 at 00:36, Sean Kelly wrote:
> > Err.. Wouldn't it just be easier to use the `shutdown` command?
> > I suggest you check `man 8 shutdown` out.
> 
> I'll concede and admit that I should have RTFM'd. But in the same vein,
> if shutdown(8) provides the functionality of halt(8) and reboot(8), why
> do they exist as separate programs? I'm probably missing something here,
> but wouldn't it be easier to just combine shutdown and reboot / halt, as
> reboot and halt already are?

Yes, you are missing something.

shutdown(8) is a sort-of frontend to reboot/halt. It contains
additional functionality and calls /sbin/halt or /sbin/reboot.
So the combination already exists. Further halt(8) and
reboot(8) are the same program, as you can easily verify using
ls -i.

The shutdown(8) frontend adds warning-messages and grace-time
features to reboot/halt. 

HTH,
 Daniel
-- 
IRCnet: Mr-Spock- All your .sigs are belong to us -
 Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/


smime.p7s
Description: S/MIME cryptographic signature

Re: Ugly Huge BSD Monster

[Leo Bicknell]

In a message written on Tue, Sep 02, 2003 at 01:07:34PM +0200, Sten Daniel S?rsdal 
wrote:
> all dependencies are as packages (in my case, i have several 
> light-weight servers/routers that have no gcc/make capabilities).

On things without gcc/make perhaps using pkg_add with binary packages
would be a far superior solution to using the ports tree.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgp0.pgp
Description: PGP signature

Re: /dev/lpt0 - always busy, except when acpi is disabled

[Mike Durian]

On Wednesday 27 August 2003 06:00 pm, Andrew Konstantinov wrote:
>
> I have a problem accessing the printer connected to the box via parallel
> port. Whenever I try to send something to /dev/lpt0, it always responds
> with 'device busy' error message,

Was there any follow-up on this?  I've noticed the same behavior -
introduced sometime in the last month or so.

mike


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Kris Kennaway]

On Tue, Sep 02, 2003 at 01:07:34PM +0200, Sten Daniel S?rsdal wrote:

> Otherwise one needs to manually track dependencies (not a terribly
> difficult job) and make those as packages, and keep doing this until
> all dependencies are as packages (in my case, i have several 
> light-weight servers/routers that have no gcc/make capabilities).
> 
> If anyone knows of a program/script that will do this for me, please speak up!

'make package-recursive'

Kris


pgp0.pgp
Description: PGP signature

Release (beta) driver for Atmel USB Wireless LAN adapters

[Daan Vreeken [PA4DAN]]

Hi,

After about a month of spare time work I have finally come to a point of 
releasing some software. I have written a driver for the Atmel AT76c503 
Wireless LAN adapters. At this moment the driver is capable of sending / 
receiving in Ad Hoc mode only. If you happen to own one of these adapters, 
please give the driver a try and let me know what you think of it.
(This is my first real kernel driver, so please kick it gently :)

You can find the driver here :
Driver home page :
http://www.vitsch.net/bsd/atuwi/
Release 0.1 file overview :
http://www.vitsch.net/bsd/atuwi/0.1/
Or grab the tarball imediately :
http://www.vitsch.net/bsd/atuwi/0.1/atuwi-0.1.tar.gz

At this moment I have a problem with the driver. After uploading the firmware 
to the device, the device needs to be resetted. I have the reset-code 
working, but after the reset the device changes it's descriptors and some 
kernel buffers/pointers have to be updated with the device. I don't know 
enough about the usb kernel internals to figure out what I'm doing wrong.
That's why I have attached the reset code to this email. If someone could tell 
me what I'm doing wrong I would be very thankfull.

grtz,
Daan___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Marcin Dalecki]

Peter Jeremy wrote:
On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote:

Has it ever been suggested to create one or more "dependencies"
ports (or more to the point, packages)?  I think it might be pretty
useful to have something like that so that all of the "prerequisites"
can be installed at once.


Maybe I'm missing something but how would that be an improvement on
what FreeBSD does now?  If I try to install package X, it will
automatically install dependencies A, B and C, as well as their
dependencies.
What I hate somehow is the proliferation of "scripting plugin interfaces"
which are optional in the src bunch but are not opt-in switches
in the actual packages. One example can be vim sucking in
perl ruby python and what a not. Esp. annoying is the
pyhon stuff visible in libxml2 and libxslt - not usefull at all.
One measure to controll this is under FreeBSD to place the following inside
/etc/make.conf:
# Kerberes. What the heck I never saw this in use.
NO_KERBEROS=yes
# My own site specific additions:
WITH_MOTIF= true
WITHOUT_PYTHON= true
WITHOUT_RUBY=   true
# Options for openoffice-pl:
WITH_BSD_JDK=TRUE
WITH_TTF_BYTECODE_ENABLED=YES
WITH_GIF_LZW_COMPRESSION=YES
# Options for Java
NATIVE_BOOTSTRAP=yes


Howver I strongly think that the WITHOYUT_PYTHON and
WITHOUT_RUBY items at least should be the defaults.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Dan Nelson]

In the last episode (Sep 02), Marcin Dalecki said:
> What I hate somehow is the proliferation of "scripting plugin
> interfaces" which are optional in the src bunch but are not opt-in
> switches in the actual packages. One example can be vim sucking in
> perl ruby python and what a not. Esp. annoying is the pyhon stuff
> visible in libxml2 and libxslt - not usefull at all. One measure to
> controll this is under FreeBSD to place the following inside
> /etc/make.conf:
[snip]
> Howver I strongly think that the WITHOYUT_PYTHON and WITHOUT_RUBY
> items at least should be the defaults.

Smart ports check to see whether the user has installed the optional
package.  See ports/audio/alsaplayer/Makefile, for example.  You're
welcome to submit PRs fixing the ports that hardcode unnecessary
dependencies :)

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Wes Peters]

On Tuesday 02 September 2003 04:07, Sten Daniel Sørsdal wrote:
> > On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote:
> > >Has it ever been suggested to create one or more "dependencies"
> > >ports (or more to the point, packages)?  I think it might be
> > > pretty useful to have something like that so that all of the
> > > "prerequisites" can be installed at once.
> >
> > Maybe I'm missing something but how would that be an improvement on
> > what FreeBSD does now?  If I try to install package X, it will
> > automatically install dependencies A, B and C, as well as their
> > dependencies.
>
> That would ease the installation of port X on Y number of machines.
> Same libraries, same everything, precompiled.
> Otherwise one needs to manually track dependencies (not a terribly
> difficult job) and make those as packages, and keep doing this until
> all dependencies are as packages (in my case, i have several
> light-weight servers/routers that have no gcc/make capabilities).
>
> If anyone knows of a program/script that will do this for me, please
> speak up!

portinstall -r -p pkgname will build a package for pkgname and all of 
it's dependencies.

-- 
 "Where am I, and what am I doing in this handbasket?"

Wes Peters  [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if_gre, ip_gre and the like (pseudo-interfaces)

[Bruce M Simpson]

On Sun, Aug 31, 2003 at 11:03:40PM -0700, Jerry Toung wrote:
> My understanding is that gre_input is called by IP everytime it receives a 
> packet with a gre headers which after some processing performs 
> IF_ENQUEUE(ifq,m) to put it back on the IPqueue so that higher protocol such 
> TCP can do their thing. :-)

Not quite correct. This is what my legacy GRE code does. The NetBSD-derived
if_gre in the tree passes the mbuf to netisr_dispatch(), which in turn calls
if_handoff(), which does something similar.

>  I don't see how /dev/gre is ever used on receiving or sending, through  
> if_clone_attach??. Somebody educate me on my missing link.

I don't see /dev/gre on my system.

If you're referring to the line 'device gre' in the kernel configuration,
that is there purely to ensure that the gre driver is statically linked
into the kernel.

BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ugly Huge BSD Monster

[Kris Kennaway]

On Tue, Sep 02, 2003 at 11:53:51AM -0700, Wes Peters wrote:

> portinstall -r -p pkgname will build a package for pkgname and all of 
> it's dependencies.

So will 'make package-recursive', as already suggested :-)

Kris


pgp0.pgp
Description: PGP signature

Booting a machine over the network without pxe.

[Josef Karthauser]

Does anyone have any experience of booting a machine over the
network, like pxeboot, but without running PXE on a network card.
I imagine that it should be possible to load pxeboot at the boot:
prompt and have everything just work.

I could really do with booting my laptop into -stable, where it's only
got -current installed.  I do however have a -stable server on site with
plenty of disk space.  It would be really cool to remote boot of that
via NFS mounts, etc.

Joe
-- 
Josef Karthauser ([EMAIL PROTECTED])   http://www.josef-k.net/
FreeBSD (cvs meisterk admin and hacker) http://www.uk.FreeBSD.org/
Physics Particle Theory (student)   http://www.pact.cpes.sussex.ac.uk/
 An eclectic mix of fact and theory. =


pgp0.pgp
Description: PGP signature

Re: Addition to reboot(8): reboot / halt reasons

[Wes Peters]

On Tuesday 02 September 2003 06:40, Daniel Lang wrote:
> Hi,
>
> Christopher Nehren wrote on Tue, Sep 02, 2003 at 08:55:23AM -0400:
> > On Tue, 2003-09-02 at 00:36, Sean Kelly wrote:
> > > Err.. Wouldn't it just be easier to use the `shutdown` command?
> > > I suggest you check `man 8 shutdown` out.
> >
> > I'll concede and admit that I should have RTFM'd. But in the same
> > vein, if shutdown(8) provides the functionality of halt(8) and
> > reboot(8), why do they exist as separate programs? I'm probably
> > missing something here, but wouldn't it be easier to just combine
> > shutdown and reboot / halt, as reboot and halt already are?
>
> Yes, you are missing something.
>
> shutdown(8) is a sort-of frontend to reboot/halt. It contains
> additional functionality and calls /sbin/halt or /sbin/reboot.
> So the combination already exists. Further halt(8) and
> reboot(8) are the same program, as you can easily verify using
> ls -i.
>
> The shutdown(8) frontend adds warning-messages and grace-time
> features to reboot/halt.

The true answer is "hysterical raisins."  Or was that "historical 
reasons?"  Something like that.

reboot and halt are BSD commands, shutdown SYSV-ish.  Shutdown has all 
those nice "professional" options to warn users, schedule a shutdown in 
a few minutes, etc.  Reboot and halt expect you to already know how to 
use at(1) and wall(1) to effect the same results, and to write a script 
if you really want to do that over and over again.


-- 
 "Where am I, and what am I doing in this handbasket?"

Wes Peters  [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Booting a machine over the network without pxe.

[Josef Karthauser]

On Tue, Sep 02, 2003 at 09:54:18PM +0100, Josef Karthauser wrote:
> Does anyone have any experience of booting a machine over the
> network, like pxeboot, but without running PXE on a network card.
> I imagine that it should be possible to load pxeboot at the boot:
> prompt and have everything just work.
> 
> I could really do with booting my laptop into -stable, where it's only
> got -current installed.  I do however have a -stable server on site with
> plenty of disk space.  It would be really cool to remote boot of that
> via NFS mounts, etc.

I should have said, my network card is an aue (usb) device which cuts
etherboot out of the equation.

Joe
-- 
Josef Karthauser ([EMAIL PROTECTED])   http://www.josef-k.net/
FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/
Physics Particle Theory (student)   http://www.pact.cpes.sussex.ac.uk/
 An eclectic mix of fact and theory. =


pgp0.pgp
Description: PGP signature

Re: Booting a machine over the network without pxe.

[Dirk-Willem van Gulik]

On Tue, 2 Sep 2003, Josef Karthauser wrote:

> Does anyone have any experience of booting a machine over the
> network, like pxeboot, but without running PXE on a network card.

The floppies of etherboot (see ports) work just fine. Or use the
bootloader on your IDE disk.

Dw
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if_gre, ip_gre and the like (pseudo-interfaces)

[Jerry Toung]

BMS,
please be patient. I guess I am still a little bit confuse as to how a
packet goes from a real NIC (i.e xl0) to the gre pseudo-device.
in if_gre.c, you define a new protocol switch in the inetdomain and
gre_input as the input processing function.
My understanding is that NIC receives a data, device driver unwraps it and
places it in &ipintrq. Then (*inetsw[ip_protox[ip->ip_p]].pr_input) in 
ip_input.c points to gre_input and that's how we land in the gre module.

gre_output on the other hand prepends or insert headers and make a call
to ip_output which I think will transmit the packet to the physical interface 
(i.e xl0).

With all respect, I don't see any call to IF_HANDOFF in the gre code. only in 
if_gif that you also wrote.
which fit the explaination you gave previously. As for /dev/gre, we can ignore 
that statement.
Thanks lot,
Jerry.



On Tuesday 02 September 2003 12:12 pm, Bruce M Simpson wrote:
> On Sun, Aug 31, 2003 at 11:03:40PM -0700, Jerry Toung wrote:
> > My understanding is that gre_input is called by IP everytime it receives
> > a packet with a gre headers which after some processing performs
> > IF_ENQUEUE(ifq,m) to put it back on the IPqueue so that higher protocol
> > such TCP can do their thing. :-)
>
> Not quite correct. This is what my legacy GRE code does. The NetBSD-derived
> if_gre in the tree passes the mbuf to netisr_dispatch(), which in turn
> calls if_handoff(), which does something similar.
>
> >  I don't see how /dev/gre is ever used on receiving or sending, through
> > if_clone_attach??. Somebody educate me on my missing link.
>
> I don't see /dev/gre on my system.
>
> If you're referring to the line 'device gre' in the kernel configuration,
> that is there purely to ensure that the gre driver is statically linked
> into the kernel.
>
> BMS

-- 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Automated Reply from SR Info

[SR Info]

Thanks for asking about Software Research's eValid and TestWorks product
suites.  We have Regression and Coverage tools for Web, Windows and UNIX
platforms.

This automated response gives you some basic information about our
products.  We'll respond to your specific question as soon as we can.

* Our current eValid Test Enabled Web Browser, Ver. 4.0, will change 
  the way you think about website testing.  Combined with our eV.Manager
  test management product, both for Windows, you have a complete 
  solution for Website functional testing, tuning, loading and regression 
  testing.  Complete information is at the eValid website:

  

* eValid(tm) Test Services offering gives you detailed, 7x24x365
  coverage of your WebSite at varying levels of test sophistication on a
  monthly subscription basis at very attractive pricing.  Full details
  at:

  

* TestWorks/Regression tools include tree-based multiple test
  management, capture replay of GUI tests in True-Time Mode (keyboard
  and mouse) and in Object-Mode (screen objects), plus a built-in OCR-
  based "screen-scraping" capability to let you validate tests from
  ASCII text extraction from screens.  Complete information at:

   for Windows
   for UNIX

* TestWorks/Coverage tools support instrumentation-based analysis of
  test coverage with both module (branch coverage) and interface (call-
  pair) coverage metrics.  Our TCAT products work on C/C++ (including
  support for both VC5 and VC6), Java and other languages, support
  branch and call-pair coverage measurements, and feature sophisticated
  displays of test completeness data.  You can get complete data at:

   for Windows
   for UNIX

* You can DOWNLOAD TestWorks products for Windows, and UNIX platforms
  from our WebSite.  We can handle the paperwork needed for your no-cost
  evaluation license key by E-mail.  Downloads are available at:

   
To help you get the most out of the TestWorks products we have provided
a wealth of information about software testing and test technology on
the TestWorks WebSite.  Simply point your browser to:

 

If we can be of help in providing any kind of information about
TestWorks or about software quality in general be sure to ask!

+---+--+
| TestWorks for Web/Windows/Unix| Phone:   [+1] (415) 861-2800 |
| Software Research, Inc.   | Toll Free:1-800-942-SOFT |
| 1663 Mission Street, Suite 400| FAX: [+1] (415) 861-9801 |
| San Francisco, CA  94103  USA | E-Mail:[EMAIL PROTECTED] |
|   | URL:    |
+---+--+

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mksnap_ffs, snapshot issues, again

[Matthew Dillon]

:
:Thanks for your thoughts. Let me know how your idea progresses
:(e.g., whether you get to work :-)
:
:   ~Kirk

I am starting work on on cache_lookup() and related functions now in
DragonFly.  I expect it will take at least the week to get a prototype
working and I believe the resulting patch set will be fairly easy to
port to FreeBSD.

The first step I am taking is to make the namecache more persistent.
*ALL* active vnodes accessed via lookup() will be guarenteed to have a
namecache entry.  I have successfully booted a test system with this
change, though I am sure there are bugs :-).  I am not entirely sure what
to do about the filehandle functions but I am not going to worry about
it for the moment.  What this basically means is that vnodes cannot be
recycled in the 'middle' of the topology, only at the leafs.  This does
not present a big problem since files are always leafs.  The namecache
topology will be guarenteed to remain unbroken except in cases where
the namespace is deleted (e.g. removing a file with active descriptors).

The second step will be to use a namecache structural pointer for our
'directory handle' in all places in the system where a directory handle
is expected (e.g. 'dvp').  This will also involve getting rid of the
vnode-based parent directory support (v_dd).  Since the namecache
structure has a pointer to the vnode this is a pretty easy step.  A
little harder will be to fix all the directory scanning functions to
use the namecache topology instead of the vnode topology. 

The third step will be to use the namecache for all name-based locking
operations instead of the underlying vnodes.  For example, if you
are renaming a/b to c/d you only need to hold locks on the namecache
entry representing "b" and the one representing "d" prior to executing
the rename operation.  The one representing "d" will be a negative
cache entry, placemarking the operation.  This will not only completely
solve the locking issues with rename(), remove(), and create, it also
completely solves directory recursion stalls in both directions, 
completely solves the race to root issue, solves most of the directory
lookup stalls (cache case lookups will not need a vnode lock and can
run in parallel with directory operations that do need the vnode lock),
gets rid of all name-related deadlock situations, and potentially allows
modifying directory operations to become reentrant down the line.

The fourth step will be a *BIG* Carrot... the namecache topology does
not have a problem with vnodes appearing in multiple places in the
filesystem.  This means that (A) it will be possible to hardlink
directories and (B) it will be possible to implement semi-hard links,
basically softlinks that *look* like hardlinks and (C) to be able to 
CD forwards and backwards without the system getting confused about
paths.  In other words, some way cool shit.

Additional optimizations are possible for the future.  For example,
it will be possible to cache ucred pointers in the namecache structure
and thus allow namei() to *COMPLETELY* resolve a path without making
any VOP calls at all, which will at least double and probably quadruple
best case path lookup performance.

I'll post an update after step 3, probably near the end of the week or
on the weekend.  I expect people will start screaming for Step 4 now
that they know it is possible :-)

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

FW: 20TB Storage System

[Max Clark]

Sorry for the cross post.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Max Clark
Sent: Tuesday, September 02, 2003 11:00 AM
To: [EMAIL PROTECTED]
Subject: 20TB Storage System


Hi all,

I need to attach 20TB of storage to a network (as low cost as possible), I
need to sustain 250Mbit/s or 30MByte/s of sustained IO from the storage to
the disk.

I have found external Fibre Channel -> ATA 133 Raid enclosures. These
enclosures will house 16 drives so with 250GB drives a total of 3.5TB each
after a RAID 5 format. These enclosures have advertised sustained IO of
90-100MByte/s each.

One solution we are thinking about is to use a Intel XEON server with 3x FC
HBA controller cards in the server each attached to a separate storage
enclosure. In any event we would be required to use ccd or vinum to stripe
multiple storage enclosures together to form one logical volume.

I can partition this system into two separate 10TB storage pools.

Given the above:
1) What would my expected IO be using vinum to stripe the storage enclosures
detailed above?
2) What is the maximum size of a filesystem that I can present to the host
OS using vinum/ccd? Am I limited anywhere that I am not aware of?
3) Could I put all 20TB on one system, or will I need two to sustain the IO
required?
4) If you were building this system how would you do it? (The installed $/GB
must be below $5.00 dollars).

My other options are to use Solaris or Windows (which I would rather not
do).

Thanks in advance,
Max

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FW: 20TB Storage System

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Max Clark" writ
es:

>Given the above:
>1) What would my expected IO be using vinum to stripe the storage enclosures
>detailed above?

That depends a lot on the applications I/O pattern, an I doubt a
precise prediction is possible.

In particular the FibreChannel is hard to predict the throughput off
because the various implementations seems to have each their own
peculiar quirks performance wise.

On a SEAGATE ST318452 disks, I see sequential transfer rates
at the outside rim of the disk of 58MB/sec.  If I stripe two of
them them with CCD I get 107MB/sec.

CCD has a better performance than Vinum where they compare.

RAID-5 and striping a large number of disks does not scale linearly
performance wise, in particular you _may_ see your average access
time drop somewhat, but there is by far no guarantee that it will
be better than the individual drive.

>2) What is the maximum size of a filesystem that I can present to the host
>OS using vinum/ccd? Am I limited anywhere that I am not aware of?

Good question, I'm not sure we currently know the exact barrier.

>3) Could I put all 20TB on one system, or will I need two to sustain the IO
>required?

Spreading it will give you more I/O bandwidth.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FW: 20TB Storage System

[Brooks Davis]

[This isn't really a performance issue so I trimmed it.]

On Tue, Sep 02, 2003 at 12:48:29PM -0700, Max Clark wrote:
> I need to attach 20TB of storage to a network (as low cost as possible), I
> need to sustain 250Mbit/s or 30MByte/s of sustained IO from the storage to
> the disk.
> 
> I have found external Fibre Channel -> ATA 133 Raid enclosures. These
> enclosures will house 16 drives so with 250GB drives a total of 3.5TB each
> after a RAID 5 format. These enclosures have advertised sustained IO of
> 90-100MByte/s each.
> 
> One solution we are thinking about is to use a Intel XEON server with 3x FC
> HBA controller cards in the server each attached to a separate storage
> enclosure. In any event we would be required to use ccd or vinum to stripe
> multiple storage enclosures together to form one logical volume.
> 
> I can partition this system into two separate 10TB storage pools.
> 
> Given the above:
> 1) What would my expected IO be using vinum to stripe the storage enclosures
> detailed above?
> 2) What is the maximum size of a filesystem that I can present to the host
> OS using vinum/ccd? Am I limited anywhere that I am not aware of?

Paul Saab recently demonstated a 2.7TB ccd so you shouldn't hit any
major limits there (I'm not sure where the next barrier is, but it
should be a ways off).  I'm not sure about UFS.

> 3) Could I put all 20TB on one system, or will I need two to sustain the IO
> required?

In theory you should be able to do 250Mbps on a single system, but I'm
not sure how well you will do in practice.  You'll need to make sure you
have sufficent PCI bus bandwidth.

> 4) If you were building this system how would you do it? (The installed $/GB
> must be below $5.00 dollars).

If you are willing to accept the management overhead of multiple
volumes, you will have a hard time beating 5U 24-disk boxes with 3
8-port 3ware arrays of 300GB disks.  That gets you 6TB per box (due to
controler limitations restricting you to 2TB per controler) for a bit
under $15000 or $2.5/GB.  The raw read speed of the arrays is around
85MBps so each array easily meets your throughput requirements.  Since
you'd have 20 arrays in 4 machines, you'd easily get meet your bandwith
requirements.  If you can't accept multiple volumes, you may still be
able to use a configuration like this using either target mode drivers
or the disk over network GEOM module that was posted recently.

You will need to use 5.x to make this work.

-- Brooks


pgp0.pgp
Description: PGP signature

RE: FW: 20TB Storage System

[Max Clark]

I know adding ccd/vinum to the equation will lower my IO throughput, but the
question is... if I have an external hardware shelf with 3.5TB (16 250GB
drives w/ Raid 5 from hardware) and I put a Raid 0 stripe across 3 of these
shelves what would my expected loss of IO be?

Thanks,
Max

-Original Message-
From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 1:02 PM
To: Max Clark
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: FW: 20TB Storage System


In message <[EMAIL PROTECTED]>, "Max Clark"
writ
es:

>Given the above:
>1) What would my expected IO be using vinum to stripe the storage
enclosures
>detailed above?

That depends a lot on the applications I/O pattern, an I doubt a
precise prediction is possible.

In particular the FibreChannel is hard to predict the throughput off
because the various implementations seems to have each their own
peculiar quirks performance wise.

On a SEAGATE ST318452 disks, I see sequential transfer rates
at the outside rim of the disk of 58MB/sec.  If I stripe two of
them them with CCD I get 107MB/sec.

CCD has a better performance than Vinum where they compare.

RAID-5 and striping a large number of disks does not scale linearly
performance wise, in particular you _may_ see your average access
time drop somewhat, but there is by far no guarantee that it will
be better than the individual drive.

>2) What is the maximum size of a filesystem that I can present to the host
>OS using vinum/ccd? Am I limited anywhere that I am not aware of?

Good question, I'm not sure we currently know the exact barrier.

>3) Could I put all 20TB on one system, or will I need two to sustain the IO
>required?

Spreading it will give you more I/O bandwidth.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FW: 20TB Storage System

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Max Clark" writ
es:
>I know adding ccd/vinum to the equation will lower my IO throughput, but the
>question is... if I have an external hardware shelf with 3.5TB (16 250GB
>drives w/ Raid 5 from hardware) and I put a Raid 0 stripe across 3 of these
>shelves what would my expected loss of IO be?

The loss will mostly be from latency, but how much is impossible to
tell I think.

The statistics of this, even with my trusty old Erlang table would
still be too uncertain to be of any value.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FW: 20TB Storage System

[Petri Helenius]

Poul-Henning Kamp wrote:

2) What is the maximum size of a filesystem that I can present to the host
OS using vinum/ccd? Am I limited anywhere that I am not aware of?
   

Good question, I'm not sure we currently know the exact barrier.

Just make sure you run UFS2, which is the default on -CURRENT because 
UFS1 has
a 1TB limit.

3) Could I put all 20TB on one system, or will I need two to sustain the IO
required?
   

Spreading it will give you more I/O bandwidth.

 

Can you say why? Usually putting more spindles into one pile gives you 
more I/O,
unless you have very evenly distributed sequential access in pattern you 
can predict
in advance.

Pete

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: FW: 20TB Storage System

[Max Clark]

Just make sure you run UFS2, which is the default on -CURRENT because
UFS1 has
a 1TB limit.

- What's the limit with UFS2?

Are there major requirements to run FreeBSD 5.x or can I still run stable
with this?

Thanks,
Max

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 20TB Storage System

[Dan Nelson]

In the last episode (Sep 02), Max Clark said:
> 2) What is the maximum size of a filesystem that I can present to the
> host OS using vinum/ccd? Am I limited anywhere that I am not aware
> of?

Depends on whether you plan on crashing or not :)  According to
http://lists.freebsd.org/pipermail/freebsd-fs/2003-July/000181.html,
you may not want to create filesystems over 3TB if you want fsck to
succeed.  I don't know if that's using the default newfs settings
(which would create an insane number of inodes), though.

> 3) Could I put all 20TB on one system, or will I need two to sustain
> the IO required?

To sustain only 30MByte/s across the entire set?  Doesn't really
matter, since even a single disk could do that.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: 20TB Storage System

[Max Clark]

Depends on whether you plan on crashing or not :)  According to
http://lists.freebsd.org/pipermail/freebsd-fs/2003-July/000181.html,
you may not want to create filesystems over 3TB if you want fsck to
succeed.  I don't know if that's using the default newfs settings
(which would create an insane number of inodes), though.

- This is a big problem (no pun intended), my smallest requirement is still
5TB... what would you recommend? The smallest file on the storage will be
500MB.

To sustain only 30MByte/s across the entire set?  Doesn't really
matter, since even a single disk could do that.

- What would I see better performance with ccd or vinum? So a better
question isn't if I can sustain with 30MByte/s but what would I expect to
maintain?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 20TB Storage System

[Dan Nelson]

In the last episode (Sep 02), Max Clark said:
[ quoting format manually recovered ]

> Dan Nelson wrote
> > Depends on whether you plan on crashing or not :)  According to
> > http://lists.freebsd.org/pipermail/freebsd-fs/2003-July/000181.html,
> > you may not want to create filesystems over 3TB if you want fsck to
> > succeed.  I don't know if that's using the default newfs settings
> > (which would create an insane number of inodes), though.
> 
> This is a big problem (no pun intended), my smallest requirement is
> still 5TB... what would you recommend? The smallest file on the
> storage will be 500MB.

I'd say try formatting a 5TB filesystem with the values you'd use (use
a very large -i; 1048576 maybe?) and see how much memory fsck consumes. 
I don't know what UFS2's max blocksize is, but a larger blocksize would
help too.  You should be able to fake enough storage to do the test
with mdconfig and some large sparse files.
 
> > To sustain only 30MByte/s across the entire set?  Doesn't really
> > matter, since even a single disk could do that.
> 
> What would I see better performance with ccd or vinum? So a better
> question isn't if I can sustain with 30MByte/s but what would I
> expect to maintain?

For sequential access to mirrored arrays, your bottleneck will probably
be the ATA->FC bridges, since they claim to only do 100MBytes/sec.  If
your three HBAs are 1gbit, then those will be your bottleneck and
you'll be able to do 300MB/s reads, and 150MB/s writes (50% mirror
penalty).  If they're 2gbit and you have 6 bridges, you'll max out at
600MB/s and 300MB/s.  If you want to use vinum raid5, cut those write
speeds in half again (25% raid-5 penalty).

Theoretically, assuming you can max your FC links and your server can
handle the load :)  I do mrtg graphs of my fibre switches, and I haven't
seen it peak over 80MB/sec through a 1gbit link, but I regularly see
70MB/sec sustained to some Tru64 Alpha servers.  I only have external
hardware raid, though, so I don't know what kind of penalty ccd/vinum
will add on top of that.  Shouldn't be too much.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"