Re: Routing Networks
Nicolás de Bari Embríz G. R. escribió: Hi all, I need some help routing or making Nat on a LAN. I have something like this: I N T E R N E T - ^ ^ | | fxp0 public IP public IP | | FreeBSD server LINUX server | | dc0 192.168.10.1| dc1 192.168.1.1 ^ 192.168.1.3 ^ | ^ | | | | | | | Switch/Hub | | | -- - | LAN A | | LAN B | | 192.168.10.2-254 | | 192.168.1.4-100 | -- - What i want to do is that a computer on LAN A with an IP on the range of 192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B "192.168.1.X". How can i solve this problem, is this is a route or Nat problem ? I think it is a route problem. You must add next static route: - On the linux machine route all incoming packets with dest addr 192.168.10.x to 192.168.1.1 It shouldn't be necesary a static route on the freebsd machine since it has a network device with an addr of LAN B. Of course you must run a route daemon in both machines (I supouse it's running now since they are working as gateways) and the previous route must be added to the route daemon running on the linux machine. You can allways check that packets are going by the correct way with traceroute. Regards, Isaac -- __ |Isaac Gelado | | | Telefónica I+D | Tlf 983367649| |Paq. Tec. de Boecillo | | |Valladolid | [EMAIL PROTECTED] | |___|__| | As gold which he cannot spend will make no man rich| | so knowledge which he cannot apply will make no man wise | |__| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: beastie boot menu, 4th (forth)
I'd like to thank everyone who's replied to my questions regarding the beastie menu and 4th. my mail has attracted far more attention than I expected. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TOS bit
Hi, I want to know the TOS bit at server side which is set at the client side. i have a TCP connection. I do not want a RAW socket connection. I require it urgently If anyone can help me reply soon. I have not subscribed to this mailing list please cc the mail to mail id [EMAIL PROTECTED] see u soon . . . * SUDHAKAR MOHARANA Innomedia technologies pvt ltd. #3278,12th main,100ft road,HAL 2nd stage, indiranagar,bangalore-8 ph :-(080)5252807,5278444,ext-144 (O) * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Filesystem marker.
Is there a set of bytes at some offset in a block that is common to any instance of a BSD ufs filesystem? I ask because recently my home machine erased it's fdisk block _and_ the bsdlabel with it. It certainly didn't have time to erase the whole disk, but I'm having trouble guessing where the partitions are. /usr/ports/sysutils/gpart will look for partitions on a disk ... but it only knows to look for bsd disklabels ... not bsd filesystems. Ideally, I'd like to make a bsd filesystem module for gpart with some pointers from the group. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mergemaster+RCS
Woo hoo! We'll test this here the next time we upgrade.
Could you send-pr this, so it doesn't get lost?
Thanks!
==ml
On Tue, Jan 13, 2004 at 02:46:23AM -0500, Michael R. Wayne wrote:
>
> Although Doug Barton has written a wonderful tool, it has always
> seemed to have a major deficiency: it completely ignores the
> existance of RCS files. I've exchanged some email with Doug and
> he has no interest in adding RCS support to mergemaster. So I did.
>
> Doug has mentioned that some people solve this problem by using
> the precompare script or by checking out all RCS files before
> running mergemaster then checking them in afterwards. These
> solutions are highly unattractive to me since they require sysadmins
> to remember far too much, especially given that systems are often
> upgraded at off hours to minimize user impact.
>
> The attached patch to the mergemaster in 4.9-RELEASE-p1 addresses
> this issue. Specifically, it does the following, automatically:
>
>For every file that mergemaster replaces, check for the existance
> of an associated RCS log file in the RCS subdirectory. (I do
> NOT check for the logfile in the current directory).
>If such a logfile exists
> If the file is currently checked out, check it in with an automated comment.
> Check the file out.
> Apply the upgrade.
> Check the file in with an automated comment.
> If the file was originally checked out, check it back out again.
>If no associated RCS log file exists, there is no change in the
> operation of mergemaster.
>
> I take care to leave the log file in the original checked in/out
> state: People have tools that "know" the state of logfiles and
> these tools should not be broken.
>
> This seems to work for us. Comments/suggestions welcome.
>
> /\/\ \/\/
>
>
> *** /usr/sbin/mergemaster Thu Jan 8 17:03:30 2004
> --- mergemaster+rcs Fri Jan 9 08:45:19 2004
> ***
> *** 8,20
> # Copyright 1998-2003 Douglas Barton
> # [EMAIL PROTECTED]
>
> # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41
> dougb Exp $
>
> PATH=/bin:/usr/bin:/usr/sbin
>
> display_usage () {
> VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
> ! echo "mergemaster version ${VERSION_NUMBER}"
> echo 'Usage: mergemaster [-scrvahipCP] [-m /path]'
> echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]'
> echo "Options:"
> --- 8,22
> # Copyright 1998-2003 Douglas Barton
> # [EMAIL PROTECTED]
>
> + # Automated support for RCS log files added 2004 by [EMAIL PROTECTED]
> +
> # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41
> dougb Exp $
>
> PATH=/bin:/usr/bin:/usr/sbin
>
> display_usage () {
> VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
> ! echo "mergemaster version ${VERSION_NUMBER} with RCS support"
> echo 'Usage: mergemaster [-scrvahipCP] [-m /path]'
> echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]'
> echo "Options:"
> ***
> *** 646,653
> --- 648,695
> ;;
> esac
>
> + # Begin part 1 of 2 support for RCS added by [EMAIL PROTECTED]
> + # Deals with RCS log files in the RCS subdirectory, first checking
> + # in previous changes (if any), checks in the changes made by
> + # mergemaster and leaves the file in the original checked in/out state.
> + #
> + # Assume we will not need to check this file in.
> + local MM_RCS
> + MM_RCS=0
> + if [ -d ${3}/RCS ]; then
> + # The RCS directory exists, check it for this logfile
> + if [ -e ${3}/RCS/${2##*/},v ]; then
> + # The RCS logfile exists, now we need to know it's existing state
> + if [ -z `rlog -L -R ${3}/${2##*/}` ]; then
> + # Target file is unlocked, check it out
> + co -l ${3}/${2##*/}
> + # Remember to leave file unlocked after install
> + MM_RCS=1
> + else
> + # File is already locked, check it in before we mess with it
> + ci -l -m"Mergemaster auto checkin of locked file." ${3}/${2##*/}
> + # Remember to leave file locked after install
> + MM_RCS=2
> + fi
> + fi
> + fi
> + # End part 1 of 2 support for RCS added by [EMAIL PROTECTED]
> +
> install -m "${1}" "${2}" "${3}" &&
> rm -f "${2}"
> +
> + # Begin part 2 of 2 support for RCS added by [EMAIL PROTECTED]
> + if [ $MM_RCS -eq 1 ]; then
> + # Checkin the file, leaving it unlocked
> + ci -u -m"Mergemaster auto checkin after updates" ${3}/${2##*/}
> + elif [ $MM_RCS -eq 2 ]; then
> + # Checkin the file, leaving it locked
> + ci -l -m"Mergemaster auto checkin after updates" ${3}/${2##*/}
> + else
> + # Do nothing, no RCS log file exists
> + fi
> + # End part 2 of 2 support for RCS added by [EMAIL PROTECTED]
> +
> }
>
> find_mode () {
> ___
> [EMAIL PROTECTED] mailing list
> ht
Re: Filesystem marker.
Look for ffsfind.c elsewhere on Internet. I used one when I incidentally relabeled a device from under a host on our SAN array. Had to modify it slightly to recognize superblocks UFS2 on FreeBSD side, but on a bright side, it worked pretty much unchanged on Solaris box. Just in any case, I saved my copy at http://people.freebsd.org/~kan/ffsfind.c On Wed, 14 Jan 2004 10:48:45 -0500 David Gilbert <[EMAIL PROTECTED]> wrote: > Is there a set of bytes at some offset in a block that is common to > any instance of a BSD ufs filesystem? I ask because recently my home > machine erased it's fdisk block _and_ the bsdlabel with it. It > certainly didn't have time to erase the whole disk, but I'm having > trouble guessing where the partitions are. > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but > it only knows to look for bsd disklabels ... not bsd filesystems. > Ideally, I'd like to make a bsd filesystem module for gpart with some > pointers from the group. > > Dave. > > -- > = > ===|David Gilbert, Independent Contractor. | Two things can > only be ||Mail: [EMAIL PROTECTED]| equal if > and only if they ||http://daveg.ca | > are precisely opposite. > |=GLO > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
p_[usi]ticks from userland without kvm and procfs?
Hello, -hackers! I'm poring over some code that uses the p_[usi]ticks counters inside of struct proc. This is fine under 4.x where kinfo_proc includes a copy of proc, but is broken under 5.x since a commit 3 years ago that reorganized kinfo_proc. So, outside of kvm and procfs, is there any user<->kernel interface for getting to struct proc or just those counters? (getrusage is kinda close except one can't lookup info about another process. :|. ) Any info is welcome. TIA! -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 pgp0.pgp Description: PGP signature
Re: p_[usi]ticks from userland without kvm and procfs?
On Wed, 14 Jan 2004, Ryan Beasley wrote: > I'm poring over some code that uses the p_[usi]ticks counters inside of > struct proc. This is fine under 4.x where kinfo_proc includes a copy of > proc, but is broken under 5.x since a commit 3 years ago that > reorganized kinfo_proc. > > So, outside of kvm and procfs, is there any user<->kernel interface for > getting to struct proc or just those counters? (getrusage is kinda > close except one can't lookup info about another process. :|. ) libkvm uses two back-ends to retrieve information from the kernel: it can either retrieve it using sysctl() on a live kernel, or using kvm access on /dev/kmem or a core file. Generally, using sysctl() is preferred for a live kernel, as it requires no special privilege, and also lets the kernel decide what data is revealed to the user application (i.e., hide processes owned by other users). The kernel function that generally exports process information userspace access is sysctl_out_proc() in src/sys/kern/kern_proc.c, which calls kill_info_proc() of fill_kinfo_thread(), depending on a flag passed to sysctl. Those fields are now part of the thread definition as opposed to the proc definition, and don't appear in the externalized structure in -current (that I can tell). A lot of process accounting and measurement changed with the introduction of M:N threads (KSE), and some of the details haven't yet been sorted out as part of the dust settling. It could well be that the fields are not currently maintained properly, and that the functionality in the kernel needs to be fixed to measure them again properly. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Filesystem marker.
On Wed, 14 Jan 2004, David Gilbert wrote: > Is there a set of bytes at some offset in a block that is common to any > instance of a BSD ufs filesystem? I ask because recently my home > machine erased it's fdisk block _and_ the bsdlabel with it. It > certainly didn't have time to erase the whole disk, but I'm having > trouble guessing where the partitions are. > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but it > only knows to look for bsd disklabels ... not bsd filesystems. Ideally, > I'd like to make a bsd filesystem module for gpart with some pointers > from the group. I ported the OpenBSD version of their scan_ffs to FreeBSD. However, it only speaks UFS1: http://www.watson.org/~robert/freebsd/scan_ffs_freebsd4/ It might also require tweaking to even build on -CURRENT, as I haven't lost any file systems recently enough to have needed to test. One of the nice things about this tool is that it can generate output that can then be fed into disklabel to write the disklabel you need back to disk. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Future of RAIDFrame
Pawel Jakub Dawidek <[EMAIL PROTECTED]> wrote: > >I'm working on one geom class (called for now geom_raid) which will support >transformations like: concatenation, stripe (raid0), mirror (raid1), raid4 >and raid5. Isn't is more GEOMish to have a separate GEOM class for each transformation? Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHANNON: NORTHWEST BACKING SOUTHWEST 6 TO GALE 8. SHOWERS. MODERATE OR GOOD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Filesystem marker.
On Wed, Jan 14, 2004 at 02:20:55PM -0500, Robert Watson wrote: > > On Wed, 14 Jan 2004, David Gilbert wrote: > > > Is there a set of bytes at some offset in a block that is common to any > > instance of a BSD ufs filesystem? I ask because recently my home > > machine erased it's fdisk block _and_ the bsdlabel with it. It > > certainly didn't have time to erase the whole disk, but I'm having > > trouble guessing where the partitions are. > > > > /usr/ports/sysutils/gpart will look for partitions on a disk ... but it > > only knows to look for bsd disklabels ... not bsd filesystems. Ideally, > > I'd like to make a bsd filesystem module for gpart with some pointers > > from the group. > > I ported the OpenBSD version of their scan_ffs to FreeBSD. However, it > only speaks UFS1: > > http://www.watson.org/~robert/freebsd/scan_ffs_freebsd4/ > > It might also require tweaking to even build on -CURRENT, as I haven't > lost any file systems recently enough to have needed to test. One of the > nice things about this tool is that it can generate output that can then > be fed into disklabel to write the disklabel you need back to disk. A port of scan_ffs that support UFS1 and UFS2 was committed yesterday as sysutils/scan_ffs: http://www.freshports.org/sysutils/scan_ffs -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
kernel environment between reboots, diskless
Greetings, I'm working on a dataless system that will be booting and rooting from flash for some environmental chamber (thermal) tests, and logging the results to an NFS server outside the chamber. The problem is that the driver for the card under test only supports one card at a time. That's relatively easy to hack around by passing in a kernel environment varible from loader that indicates which PCI slot is OK. Then the probe routine of the driver looks for that variable and won't accept the device unless it matches. I'm trying to see if there's a way to get that information into the loader (or the driver) in some way that doesn't require rewriting a file in the flash every reboot, to avoid flash write cycles. I know there's some amount of NVRAM in PCs, but didn't spot anything about how to get at it from the driver. It'd be nice, for this sort of application, if there was a way to stash somewhere between 2 and 8 bytes somewhere... Thanks for insights! Pls cc: me directly on replies. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing Networks
On Wed, Jan 14, 2004 at 08:43:37AM +0100, Isaac Gelado wrote: > Nicol?s de Bari Embr?z G. R. escribi?: > >Hi all, I need some help routing or making Nat on a LAN. > > > >I have something like this: > > > > > > I N T E R N E T > > - > >^ ^ > >| | > >fxp0 public IP public IP > >| | > > FreeBSD server LINUX server > >| | > >dc0 192.168.10.1| > >dc1 192.168.1.1 ^ 192.168.1.3 > >^ | ^ > >| | | > >| | | > > > > | Switch/Hub | > > > > | | > >-- - > > | LAN A | | LAN B | > > | 192.168.10.2-254 | | 192.168.1.4-100 | > >-- - > > > > > >What i want to do is that a computer on LAN A with an IP on the range of > >192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B > >"192.168.1.X". > > > >How can i solve this problem, is this is a route or Nat problem ? > > I think it is a route problem. You must add next static route: > > - On the linux machine route all incoming packets with dest addr > 192.168.10.x to 192.168.1.1 > > It shouldn't be necesary a static route on the freebsd machine since it > has a network device with an addr of LAN B. This is correct. Things can get from LAN A to LAN B just fine in this picture. The problem is that machines on LAN B won't be able to get back to LAN A (i.e. your pings go from A to B, but the pongs never get back from B to A). You'll have to touch that Linux box or touch the routes on everything on LAN B to route 192.168.10.0/24 through 192.168.1.1. > Of course you must run a > route daemon in both machines (I supouse it's running now since they are > working as gateways) and the previous route must be added to the route > daemon running on the linux machine. OK now here is the problem. Why does he need a routing daemon? I saw no mention of RIP, OSPF, or any other dynamic routing protocol. Looks like it's all static routes to me. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel environment between reboots, diskless
On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: > Greetings, > > I'm working on a dataless system that will be booting and rooting > from flash for some environmental chamber (thermal) tests, and > logging the results to an NFS server outside the chamber. I've got to ask, if you're in an NFS environment, why boot from flash at all? Why not PXE boot or use etherboot? -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: kernel environment between reboots, diskless
On Jan 14, 13:11, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } > I'm working on a dataless system that will be booting and rooting } > from flash for some environmental chamber (thermal) tests, and } > logging the results to an NFS server outside the chamber. } } I've got to ask, if you're in an NFS environment, why boot from flash at } all? Why not PXE boot or use etherboot? I'm attempting to minimize reboot cycle time, since part of the test suite involves 50 reboots per card, and with 5 cards in the system, a minute extra boot time is suddenly four hours. But I'll admit to not having gathered the data on that one, so I'll give it a closer look. If I PXE or etherboot, how would the kernel environment get populated then? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel environment between reboots, diskless
On Wed, Jan 14, 2004 at 01:16:01PM -0800, Steve Watt wrote: > On Jan 14, 13:11, Brooks Davis wrote: > } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: > } > I'm working on a dataless system that will be booting and rooting > } > from flash for some environmental chamber (thermal) tests, and > } > logging the results to an NFS server outside the chamber. > } > } I've got to ask, if you're in an NFS environment, why boot from flash at > } all? Why not PXE boot or use etherboot? > > I'm attempting to minimize reboot cycle time, since part of the test > suite involves 50 reboots per card, and with 5 cards in the system, > a minute extra boot time is suddenly four hours. Hmm, that might be an issue. If your network is reliable (and you configure your switches so you don't get screwed by spanning tree), PXE boots are quite fast, probably not more then a few seconds longer then booting from local media (possiably less since you could disabling BIOS probing of the media which takes forever.) > But I'll admit to not having gathered the data on that one, so I'll > give it a closer look. If I PXE or etherboot, how would the kernel > environment get populated then? From the server. The advantage of this is that it would be easy to script changes on the server as opposed to changes on the flash card. You also don't need to worry about wearing out the server's disks. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Filesystem marker.
In message: <[EMAIL PROTECTED]> David Gilbert <[EMAIL PROTECTED]> writes: : Is there a set of bytes at some offset in a block that is common to : any instance of a BSD ufs filesystem? I ask because recently my home : machine erased it's fdisk block _and_ the bsdlabel with it. It : certainly didn't have time to erase the whole disk, but I'm having : trouble guessing where the partitions are. You can look for the UFS magic number. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Mon, 12 Jan 2004, Robert Watson wrote: > I think the right strategy is to follow the minimalist approach now > (adopt the disk(9) API, rather than having Vinum generate character > devices) so that swap works on Vinum again, and so that when UFS moves > to speaking GEOM there's no loss of functionality. If we want to > completely reimplement Vinum, we should do that separately so as to > avoid loss of functionality during structural changes. As many ways lead to Rome, how about the following scenario. I don't know if it's a clever way to do things, and I don't know if it's even possible to with GEOM, so some input is appreciated. *) Have separate GEOM classes for each of the different vinum objects (drive, sd, plex, volume). *) Let the drive geom taste the slices configured for vinum, read the on-disk config and then spawn the necessary other geoms (I'm not sure if the latter can be done in GEOM). *) I think this is a clean implementation, since the GEOM framework offers all the "background" needed to transform the IO requests. *) It would also be a good way to clean up the vinum code. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
In message <[EMAIL PROTECTED]>, Lukas Ertl writes: >On Mon, 12 Jan 2004, Robert Watson wrote: > >> I think the right strategy is to follow the minimalist approach now >> (adopt the disk(9) API, rather than having Vinum generate character >> devices) so that swap works on Vinum again, and so that when UFS moves >> to speaking GEOM there's no loss of functionality. If we want to >> completely reimplement Vinum, we should do that separately so as to >> avoid loss of functionality during structural changes. > >As many ways lead to Rome, how about the following scenario. I don't know >if it's a clever way to do things, and I don't know if it's even possible >to with GEOM, so some input is appreciated. > >*) Have separate GEOM classes for each of the different vinum objects > (drive, sd, plex, volume). >*) Let the drive geom taste the slices configured for vinum, read the > on-disk config and then spawn the necessary other geoms (I'm not sure > if the latter can be done in GEOM). >*) I think this is a clean implementation, since the GEOM framework offers > all the "background" needed to transform the IO requests. >*) It would also be a good way to clean up the vinum code. It is possible in GEOM, but I am not convinced that fragmenting into this many GEOM classes can be classified as an easy path to go. I think for now the important thing is to get the people interested on this collected on a mail-alias, and for them to discuss how the can work together to make something happen. After that, try to define "something" closer. -- 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: Filesystem marker.
David Gilbert <[EMAIL PROTECTED]> writes: > Is there a set of bytes at some offset in a block that is common to > any instance of a BSD ufs filesystem? Yes, you should find copies of the superblock for each file system at regular intervals. On a little-endian machine, each superblock will contain, at offset 0x55c, the bytes 0x54 0x19 0x01 0x00 (for UFS1) 0x19 0x01 0x54 0x19 (for UFS2) obviously on a big-endian machine they will be in the reverse order (but at the same offset) Note that you may get false positives from files containing data that happens to match the UFS magic numbers (e.g. dumps). The offset of the first superblock backup relative to the start of the filesystem depends on the newfs parameters. I believe that with default values in 5.x the superblocks will be at sector offsets 160, 376512, 752864 and so on in increments of 376352 sectors. For UFS1, the sector offsets will be 32, 376224, 752416 and so on in increments of 376192 sectors. For older UFS1 filesystems created back when newfs defaulted to 8192-byte blocks and 1024-byte fragments, the offsets will be 32, 92448, 184864 and so on in 92416-sector increments. The layout of the superblock is described in /sys/ufs/ffs/fs.h (see the definition of struct fs) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing Networks
- Mensaje original - De: "Crist J. Clark" <[EMAIL PROTECTED]> Fecha: Miércoles, Enero 14, 2004 10:06 pm Asunto: Re: Routing Networks > On Wed, Jan 14, 2004 at 08:43:37AM +0100, Isaac Gelado wrote: > > Nicol?s de Bari Embr?z G. R. escribi?: > > >Hi all, I need some help routing or making Nat on a LAN. > > > > > >I have something like this: > > > > > > > > > I N T E R N E T > > > - > > >^ ^ > > >| | > > >fxp0 public IP public IP > > >| | > > > FreeBSD server LINUX server > > >| | > > >dc0 192.168.10.1| > > >dc1 192.168.1.1 ^ 192.168.1.3 > > >^ | ^ > > >| | | > > >| | | > > > > > > | Switch/Hub | > > > > > > | | > > >-- - > > > | LAN A | | LAN B | > > > | 192.168.10.2-254 | | 192.168.1.4-100 | > > >-- - > > > > > > > > >What i want to do is that a computer on LAN A with an IP on the > range of > > >192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on > LAN B > > >"192.168.1.X". > > > > > >How can i solve this problem, is this is a route or Nat problem ? > > > > I think it is a route problem. You must add next static route: > > > > - On the linux machine route all incoming packets with dest > addr > > 192.168.10.x to 192.168.1.1 > > > > It shouldn't be necesary a static route on the freebsd machine > since it > > has a network device with an addr of LAN B. > > This is correct. Things can get from LAN A to LAN B just fine in this > picture. The problem is that machines on LAN B won't be able to get > back to LAN A (i.e. your pings go from A to B, but the pongs never get > back from B to A). You'll have to touch that Linux box or touch the > routes on everything on LAN B to route 192.168.10.0/24 through > 192.168.1.1. > > > Of course you must run a > > route daemon in both machines (I supouse it's running now since > they are > > working as gateways) and the previous route must be added to the > route > > daemon running on the linux machine. > > OK now here is the problem. Why does he need a routing daemon? I saw > no mention of RIP, OSPF, or any other dynamic routing protocol. Looks > like it's all static routes to me. Sorry, I was mistaken. You only need that FreeBSD machines redirects packets from one network interface to the other as Crist says. Regards > -- > Crist J. Clark | [EMAIL PROTECTED] > | [EMAIL PROTECTED] > http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > [EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Lukas Ertl writes: >> On Mon, 12 Jan 2004, Robert Watson wrote: >> >>> I think the right strategy is to follow the minimalist approach now >>> (adopt the disk(9) API, rather than having Vinum generate character >>> devices) so that swap works on Vinum again, and so that when UFS moves >>> to speaking GEOM there's no loss of functionality. If we want to >>> completely reimplement Vinum, we should do that separately so as to >>> avoid loss of functionality during structural changes. >> >> As many ways lead to Rome, how about the following scenario. I don't know >> if it's a clever way to do things, and I don't know if it's even possible >> to with GEOM, so some input is appreciated. >> >> *) Have separate GEOM classes for each of the different vinum objects >> (drive, sd, plex, volume). >> *) Let the drive geom taste the slices configured for vinum, read the >> on-disk config and then spawn the necessary other geoms (I'm not sure >> if the latter can be done in GEOM). >> *) I think this is a clean implementation, since the GEOM framework offers >> all the "background" needed to transform the IO requests. >> *) It would also be a good way to clean up the vinum code. > > It is possible in GEOM, but I am not convinced that fragmenting into > this many GEOM classes can be classified as an easy path to go. I think it's probably a good ultimate aim, but I don't think it should be the first step. > I think for now the important thing is to get the people interested > on this collected on a mail-alias, and for them to discuss how the > can work together to make something happen. After that, try to > define "something" closer. A mailing lists exists. [EMAIL PROTECTED] If somebody wants to put in a FreeBSD version, that wouldn't be a disadvantage. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Gratituous ARP and the em driver
Yes, this is the case. I tested it again, and the arp packet in question doesn't get to the other machines. The sending machine does send gratituous arp, however the em NIC is down for 3 or 4 seconds, and the packet isn't sent on the wire. I find it odd that the em driver would need to reinitialize the NIC each time an alias is added. I haven't seen any other network drivers do this. And, yes, it occurs every time an alias is added or removed from the NIC. Not just the first time. Cheers, Nate Robert Watson wrote: On -1 xxx -1, Nielsen wrote: If you run tcpdump on the machine to sniff the interface in question looking for arp packets, does tcpdump see the gratuitous arp? I'm guessing that it does, and the lack of sending the arp is a result of delays in negotiating on the wire. Does this problem turn up only the first time you raise the interface, or every time you change the IP address on the interface? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel environment between reboots, diskless
On Jan 14, 13:24, Brooks Davis wrote: } On Wed, Jan 14, 2004 at 01:16:01PM -0800, Steve Watt wrote: } > On Jan 14, 13:11, Brooks Davis wrote: } > } On Wed, Jan 14, 2004 at 12:55:49PM -0800, Steve Watt wrote: } > } > I'm working on a dataless system that will be booting and rooting } > } > from flash for some environmental chamber (thermal) tests, and } > } > logging the results to an NFS server outside the chamber. } > } } > } I've got to ask, if you're in an NFS environment, why boot from flash at } > } all? Why not PXE boot or use etherboot? } > } > I'm attempting to minimize reboot cycle time, since part of the test } > suite involves 50 reboots per card, and with 5 cards in the system, } > a minute extra boot time is suddenly four hours. } } Hmm, that might be an issue. If your network is reliable (and you } configure your switches so you don't get screwed by spanning tree), PXE } boots are quite fast, probably not more then a few seconds longer then } booting from local media (possiably less since you could disabling BIOS } probing of the media which takes forever.) It's going to be an isolated net, so it shouldn't be a problem on this part. } > But I'll admit to not having gathered the data on that one, so I'll } > give it a closer look. If I PXE or etherboot, how would the kernel } > environment get populated then? } } From the server. The advantage of this is that it would be easy to } script changes on the server as opposed to changes on the flash card. } You also don't need to worry about wearing out the server's disks. Ah! I see how that works. Only catch is, I'm getting a strange result when trying diskless boots. I've got the DHCP server configured as suggested in pxeboot(8), and I see the loader get started. It grabs (over NFS) loader.rc, loader.4th, and support.4th. I see the start word get executed, but adding .( message ) cr in various places, it seems like it's getting to the end of start, but not coming back to the loader.rc code. And most of my Forth knowledge is from working with PostScript 15 years ago, which doesn't help a lot. :P Anyone want to hazard a guess? I feel like I'm falling deeper into that maze of twisty little passages. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Call for bi-monthly status reports
All, It's time for bi-monthly status reports. This one is a little late due to the excitement of releasing 5.2, so please submit reports for Oct-Dec 2003. As always, the template is at http://www.freebsd.org/news/status/report-sample.xml, and submissions go to [EMAIL PROTECTED] While this report is primarily for projects that are in-progress, we would also encourage submissions for projects that are still in their idea and planning phases. It is open to src, ports, and documentation projects that are related to FreeBSD Submissions are due to [EMAIL PROTECTED] by Jan 24. Thanks! Scott Long ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
