Re: svn - but smaller?

[Andrew Reilly]

On Thu, Jan 24, 2013 at 10:45:53AM +, Ben Morrow wrote:
> At  9AM + on 24/01/13 you (Ben Morrow) wrote:
> > Quoth 'Jeremy Chadwick' :
> > > 
> > > Regarding your "svn-lite" theory of having that added to src/contrib/,
> > > let me introduce you to Subversion's actual dependencies, and I'll
> > > explain why these would have to remain enabled (for a "base system"
> > > Subversion) as well:
> 
> > > * APR (used for HTTP fetching (not necessarily HTTPS))
> > >   -- License: http://www.apache.org/licenses/LICENSE-2.0.html
> > >   -- Not in the base system
> > > 
> > > * Expat 2.x (XML parsing/generation library
> > >   -- License: http://en.wikipedia.org/wiki/MIT_License
> > >   -- Not in the base system
> 
> Correction: expat is in base already, as libbsdxml (rather confusingly
> built under lib/libexpat).
> 
> So AFAICS the only remaining piece is APR (and svn itself), and I
> suspect that if only the bits required for a svn client were brought in
> (assuming the licence is deemed acceptable) that would be a lot smaller
> than a full APR build. (Again, this would need to be built as libbsdapr
> to avoid conflicts with real APR from ports.)

If APR is only used for HTTP fetching, I wonder how hard it
would be to replace those pieces with fetch(3), which is in
base, or wrap fetch(3) in an APR-compatability shim? (Some
work required, obviously.)  No, I'm not volunteering: svn from
ports works OK for me, and I'm in the process of investigating
freebsd-update+portsnap to keep the source trees up to date...

Took me a while to notice that freebsd-update can be told to
*not* update executables and what-not, but I haven't tried it
myself.  Call me a massochist, but I like that my FreeBSD system
is running code built from the source that's there...  Part of
FreeBSD's charm, in my opinion.

Cheers,

-- 
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFC: Suggesting ZFS "best practices" in FreeBSD

[Jeremy Chadwick]

On Fri, Jan 25, 2013 at 08:48:51PM -0700, Warren Block wrote:
> On Fri, 25 Jan 2013, Jeremy Chadwick wrote:
> 
> >On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote:
> >>On Thu, 24 Jan 2013, Jeremy Chadwick wrote:
> >>
> >#1.  Map the physical drive slots to how they show up in FBSD so if a
> >disk is removed and the machine is rebooted all the disks after that
> >removed one do not have an 'off by one error'.  i.e. if you have
> >ada0-ada14 and remove ada8 then reboot - normally FBSD skips that
> >missing ada8 drive and the next drive (that used to be ada9) is now
> >called ada8 and so on...
> 
> How do you do that?  If I'm in that situation, I think I could find the
> bad drive, or at least the good ones, with diskinfo and the drive serial
> number.  One suggestion I saw somewhere was to use disk serial numbers
> for label values.
> >>>
> >>>The term FreeBSD uses for this is called "wiring down" or "wired down",
> >>>and is documented in CAM(4).  It's come up repeatedly over the years but
> >>>for whatever reason people overlook it or can't find it.
> >>
> >>I was aware of it, it just seems like there ought to be a better way
> >>to identify drives than by messing with the hardware configuration.
> >
> >I understand what you mean, but it's actually messing with a software
> >configuration (specifically CAM).
> >
> >It's a one-time change that solves the dilemma; it only has to be
> >adjusted if you change controller brands or models, which is a lot less
> >often than changing disks.
> >
> >>Something more elegant, less tied to changing the hardware
> >>configuration of the host.  Assigning the drive serial number as a
> >>label, for example.
> >
> >Hmm...  all this does is change the nature of the problem, no?  You
> >still have the issue of "having to know some magical number" to
> >determine out what path name refers to what physical disk in your system.
> >Can you expand on how this would solve it?
> 
> It's not so much a solution as in the right domain.  The point, as I
> see it, is being able to identify individual disks uniquely.
> Forcing static devices names does that, sort of.  But plug a
> different disk into the same port as an existing one, and that disk
> is now identified as the old one.

Identifying individual disks is a separate subject, as I see it, from
that of what the original concern was.  Quoting that concern:

> >#1.  Map the physical drive slots to how they show up in FBSD so if a
> >disk is removed and the machine is rebooted all the disks after that
> >removed one do not have an 'off by one error'.  i.e. if you have
> >ada0-ada14 and remove ada8 then reboot - normally FBSD skips that
> >missing ada8 drive and the next drive (that used to be ada9) is now
> >called ada8 and so on...

How I interpret that: "when I have a drive bay that's not populated, or
a SATA port that has nothing on it, the /dev/adaX numbering changes or
shifts by N.  That's frustrating!"  He's trying to ensure 1:1 static
device numbering.  The way to do that in CAM is "wiring down".  There
are lots of methods to avoid using the adaX/daX/etc. nomenclature --
labels of course! -- but like I said those just exchange one problem for
another.

I do wish there was some intelligent way in software to accomplish the
"wiring down" method without having to do loader.conf modifications, I
just don't know how software would be able to make those kinds of
decisions.



> Using a unique identifier already built into those drives helps.
> Serial numbers are unique, built into the drive, and even printed on
> the paper label.  They can be queried through software and take no
> disk space.  If a drive fails electronically to the point it can't
> be queried, that serial number can be identified from a current list
> of all the drive serial numbers in the array--it's the one not
> there.

How does that serial number correlate with anything physical though?
CAM's "wired down" method allows you to correlate a number (device
number) with something physical?

If what you're saying is "we should have something *like* labels, but
instead not a label at all, instead use what's already there (WWN or
serial number or something generated off of serno+modelstring+etc.)"
then yeah, I'm hearing you on FM.  :-)

> There are problems, they aren't like LEDs on each drive that could
> flash to identify it.  Some enclosures don't make drive labels easy
> to see. Some of that can be addressed with labels.  Er, sticky
> labels, on the outside of the drive or enclosure.  And serial
> numbers are often inconveniently long.

On my Supermicro SC733T chassis, I ended up using a label maker to print
out labels that read "ada0", "ada1", etc. and placed them next to each
respective hot-swap bay.

Not a lot of people know about /dev/led/ (see ahci(4), search for
"LED").  SGPIO does what you want (see SFF-8485 per Seagate).  It's
wonderful except when someone doesn't play nice -- y

Re: RFC: Suggesting ZFS "best practices" in FreeBSD

[Garrett Wollman]

In article ,
wbl...@wonkity.com writes:

>As far as "best practices", situations vary so much that I don't know if 
>any drive ID method can be recommended.  For a FreeBSD ZFS document, a 
>useful sample configuration is going to be small enough that anything 
>would work.  A survey of the techniques in use at various data centers 
>would be interesting.

My best practice would be: write the label onto the drive itself.
Have it be something that is physically meaningful.  Then the only
issue is making sure to label a new drive properly when you install
it.

On our big file servers, we use a labeling convention of
s${shelf}d${drive}, where ${shelf} is the rack unit where the shelf is
mounted and ${drive} is the slot number marked on the front of the
drive.  I have some scripts to semiautomatically crawl the output of
camcontrol devlist and sas2ircu to determine which drive is located
where.  Of course, we have no choice but to label the drives; that's
how gmultipath works.

For bootable drives, we just use the built-in labeling feature of gpt:
the swap partition is named swap0 or swap1, and the ZFS partition is
named tank0 or tank1 (as appropriate for whether it's the primary or
secondary boot device).  That way, if one fails on boot, we know which
one it is (or rather, we know which one is still alive).

-GAWollman

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Andrew Reilly]

On Thu, Jan 24, 2013 at 03:20:42PM +0100, Gyrd Thane Lange wrote:
> On 23.01.2013 15:40, Oliver Brandmueller wrote:
> > However, I either overlook something important or we are now at the
> > point we had with cvsup in the early days: The software I need to
> > (source-)update the system doens't come with the base and installing svn
> > is a PITA. [...]
> 
> It is not a well publicized fact, but I understand that the base utility 
> freebsd-update(8) through it's freebsd-update.conf(5) is able to pull 
> the base sources (/usr/src/) only instead of also updating your binaries.
> 
> less /etc/freebsd-update.conf
> 
># Components of the base system which should be kept updated.
>Components src world kernel
> 
> The above setting is the default, but you may easily leave out 
> everything but "src". (Caveat: I have not tried it myself yet.)
> It also have some optional settings for preserving local changes to the 
> source instead of blowing them away (default).
> 
> This will allow you to use the sources for a custom build and install 
> yourself.

I've been using svn from ports for a while, but would like to switch to a
FreeBSD-self-contained update method, so I've just given that a shot.  I've
tweaked out world and kernel from the freebsd-update.conf (and also tweaked out
the updateIfChanged and MergeIfChanged lines, just in case it tried to do
something to my config.)

Anyway, it failed thusly:

$ sudo freebsd-update fetch
Password:
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update5.freebsd.org... failed.
Fetching public key from update4.freebsd.org... failed.
Fetching public key from update3.freebsd.org... failed.
No mirrors remaining, giving up.

Any thoughts on what is going wrong there?  I would imagine that if there was a
real problem, rather than pilot error, there would be considerable noise on the
lists.  Do I need to "prime" the system by grabbing some keys from somewhere?

I have a fully-up-to-date /usr/src world and kernel thanks to the
svn+UPDATING process, fwiw.

> Also for ports we have the portsnap(8) utility, also in base. So it is 
> perfectly possible to get sources for everything using just the tools in 
> base. No csup or svnup is required.

That manual page reads as though it downloads the whole tarball of the whole 
ports
tree every time: that doesn't sound terribly efficient.  Is there enough
redundancy in the ports structure to make compressing a tarball a win, compared 
to
uncompressed version differences at, say, weekly updates?

Cheers,

-- 
Andrew

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFC: Suggesting ZFS "best practices" in FreeBSD

[Warren Block]

On Fri, 25 Jan 2013, Jeremy Chadwick wrote:


On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote:

On Thu, 24 Jan 2013, Jeremy Chadwick wrote:


#1.  Map the physical drive slots to how they show up in FBSD so if a
disk is removed and the machine is rebooted all the disks after that
removed one do not have an 'off by one error'.  i.e. if you have
ada0-ada14 and remove ada8 then reboot - normally FBSD skips that
missing ada8 drive and the next drive (that used to be ada9) is now
called ada8 and so on...


How do you do that?  If I'm in that situation, I think I could find the
bad drive, or at least the good ones, with diskinfo and the drive serial
number.  One suggestion I saw somewhere was to use disk serial numbers
for label values.


The term FreeBSD uses for this is called "wiring down" or "wired down",
and is documented in CAM(4).  It's come up repeatedly over the years but
for whatever reason people overlook it or can't find it.


I was aware of it, it just seems like there ought to be a better way
to identify drives than by messing with the hardware configuration.


I understand what you mean, but it's actually messing with a software
configuration (specifically CAM).

It's a one-time change that solves the dilemma; it only has to be
adjusted if you change controller brands or models, which is a lot less
often than changing disks.


Something more elegant, less tied to changing the hardware
configuration of the host.  Assigning the drive serial number as a
label, for example.


Hmm...  all this does is change the nature of the problem, no?  You
still have the issue of "having to know some magical number" to
determine out what path name refers to what physical disk in your system.
Can you expand on how this would solve it?


It's not so much a solution as in the right domain.  The point, as I see 
it, is being able to identify individual disks uniquely.  Forcing static 
devices names does that, sort of.  But plug a different disk into the 
same port as an existing one, and that disk is now identified as the old 
one.


Using a unique identifier already built into those drives helps. 
Serial numbers are unique, built into the drive, and even printed on the 
paper label.  They can be queried through software and take no disk 
space.  If a drive fails electronically to the point it can't be 
queried, that serial number can be identified from a current list of all 
the drive serial numbers in the array--it's the one not there.


There are problems, they aren't like LEDs on each drive that could flash 
to identify it.  Some enclosures don't make drive labels easy to see. 
Some of that can be addressed with labels.  Er, sticky labels, on the 
outside of the drive or enclosure.  And serial numbers are often 
inconveniently long.



As for a unique number per disk, disks within the past ~5 years (SATA,
SAS, and some SCSI) all tend to have this: it's called a WWN:

http://en.wikipedia.org/wiki/World_Wide_Name

But older ATA disks (and by older I don't mean ancient, I mean even
semi-old) may not have this, which means you get to use something else.
UUIDs come to mind, but then the question becomes what do you base the
generation off of?  Model string + serial number + firmware?

There are also complexities depending on HBAs (disk controllers) as
well; I've seen references, at least on Solaris, of people having one
disk showing up twice across 2 separate controllers (i.e. only 1
physical disk in the machine, but showing up as both c8d0 and c9d0, both
with the same model string and serial number).  I imagine some RAID
controllers would do this (when a drive isn't part of an array; it might
show up as both /dev/adaX and /dev/somedriverX).  I know at some point I
saw this with FreeBSD too during an OS install, I just can't remember
what the names were that I saw.


Surely that ought to be considered a bug.  Any drive ID system is going 
to be vulnerable to certain



Linux has by-uuid and by-id (the latter is what you'd like), but there
are caveats to that too:

https://wiki.archlinux.org/index.php/Persistent_block_device_naming
http://www.terabyteunlimited.com/kb/article.php?id=389

So at the end of the day I prefer CAM's "wired down" method -- the
reason is that by modifying loader.conf I **know for sure** bay/cable X
maps to /dev/adaX, and it's a one-time deal until I decide to move from
my ICH9 controller to, say, an Areca.


That illustrates one problem with making the configuration specific to 
host hardware as compared to drive specific.


As far as "best practices", situations vary so much that I don't know if 
any drive ID method can be recommended.  For a FreeBSD ZFS document, a 
useful sample configuration is going to be small enough that anything 
would work.  A survey of the techniques in use at various data centers 
would be interesting.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubs

Re: RFC: Suggesting ZFS "best practices" in FreeBSD

[Jeremy Chadwick]

On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote:
> On Thu, 24 Jan 2013, Jeremy Chadwick wrote:
> 
> >>>#1.  Map the physical drive slots to how they show up in FBSD so if a
> >>>disk is removed and the machine is rebooted all the disks after that
> >>>removed one do not have an 'off by one error'.  i.e. if you have
> >>>ada0-ada14 and remove ada8 then reboot - normally FBSD skips that
> >>>missing ada8 drive and the next drive (that used to be ada9) is now
> >>>called ada8 and so on...
> >>
> >>How do you do that?  If I'm in that situation, I think I could find the
> >>bad drive, or at least the good ones, with diskinfo and the drive serial
> >>number.  One suggestion I saw somewhere was to use disk serial numbers
> >>for label values.
> >
> >The term FreeBSD uses for this is called "wiring down" or "wired down",
> >and is documented in CAM(4).  It's come up repeatedly over the years but
> >for whatever reason people overlook it or can't find it.
> 
> I was aware of it, it just seems like there ought to be a better way
> to identify drives than by messing with the hardware configuration.

I understand what you mean, but it's actually messing with a software
configuration (specifically CAM).

It's a one-time change that solves the dilemma; it only has to be
adjusted if you change controller brands or models, which is a lot less
often than changing disks.

> Something more elegant, less tied to changing the hardware
> configuration of the host.  Assigning the drive serial number as a
> label, for example.

Hmm...  all this does is change the nature of the problem, no?  You
still have the issue of "having to know some magical number" to
determine out what path name refers to what physical disk in your system.
Can you expand on how this would solve it?

As for a unique number per disk, disks within the past ~5 years (SATA,
SAS, and some SCSI) all tend to have this: it's called a WWN:

http://en.wikipedia.org/wiki/World_Wide_Name

But older ATA disks (and by older I don't mean ancient, I mean even
semi-old) may not have this, which means you get to use something else.
UUIDs come to mind, but then the question becomes what do you base the
generation off of?  Model string + serial number + firmware?

There are also complexities depending on HBAs (disk controllers) as
well; I've seen references, at least on Solaris, of people having one
disk showing up twice across 2 separate controllers (i.e. only 1
physical disk in the machine, but showing up as both c8d0 and c9d0, both
with the same model string and serial number).  I imagine some RAID
controllers would do this (when a drive isn't part of an array; it might
show up as both /dev/adaX and /dev/somedriverX).  I know at some point I
saw this with FreeBSD too during an OS install, I just can't remember
what the names were that I saw.

Linux has by-uuid and by-id (the latter is what you'd like), but there
are caveats to that too:

https://wiki.archlinux.org/index.php/Persistent_block_device_naming
http://www.terabyteunlimited.com/kb/article.php?id=389

So at the end of the day I prefer CAM's "wired down" method -- the
reason is that by modifying loader.conf I **know for sure** bay/cable X
maps to /dev/adaX, and it's a one-time deal until I decide to move from
my ICH9 controller to, say, an Areca.

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Svnsup architecture [was: Re: svn - but smaller?]

[John Mehr]

On Fri, 25 Jan 2013 13:42:19 +0100
 Arrigo Marchiori  wrote:
On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy 

1- svnsup-distill: takes a revision from svn and creates 
a text file
(called a delta) that represents it. It seems to be 
almost

complete.


To answer one of John Mehr's problems: MD5 sums are 
calculated by
svnsup-distill and included in the deltas. The client 
only needs to

check them against the local files.


Hello,

I've been looking for a way to get the details of a 
complete revision in one step, but I haven't had any luck 
yet.  This would solve the one aspect I'm most worried 
about: with 5+ files and 5500+ directories in my local 
copy of /usr/src, I'd hate to have my code end up 
inadvertently causing a denial of service on the 
repositories with a flood of tiny requests...




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[John Mehr]

On Fri, 25 Jan 2013 10:27:23 +0100
 Oliver Brandmueller  wrote:

Also I'd like to mention John Mehr, who's work on a 
"lightweight, 
dependency-free, BSD licensed program to pull source 
using the svn 
protocol" (couldn't say it better, so I use his words 
:-)). Hope this 
will make it into ports soon and in the long run even to 
base!


Thank you for the kind words.  If all goes well (I'm still 
wearing my "Crown of Naive Optimism") I should have 
something ready for show-and-tell in the next week or so 
and I'll be submitting it as a new port soon after that.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge numbering

[Gary Palmer]

On Fri, Jan 25, 2013 at 05:47:39PM +0200, Daniel Braniss wrote:
> > On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote:
> > > Hi,
> > > this server, a Dell R720 has 4 bge on board,
> > >  Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
> > >  bge0: APE FW version: NCSI v1.1.7.0
> > >  bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
> > >  miibus0:  on bge0
> > >  ...
> > > 
> > > I have connected the ethernet to port labeled 0, but it appears
> > > as bge2, how can this be corrected?
> > 
> > It can't really.  The order of PCI devices is determined by the layout of 
> > the 
> > PCI device hierarchy which is generally determined by the physical traces 
> > on 
> > your motherboard.
> 
> so you are saying that Dell screwed up yet again?
> the 4 bges have consecutive macs, bge1 = bge0 +1, bge2 = bge1 + 1, etc. It's
> only the # 'outside' that is wrong? I will try the usual trial and error
> to find the mapping, but will have to wait till Sunday.

bge0 = port 2
bge1 = port 3
bge2 = port 0
bge3 = port 1

would be my suspicion

The R720 Broadcom chips are dual port, so bge0 & 1 are paired and bge2 & 3
are paired.

You can force this to be corrected by renaming the devices I believe.

Dell "fixed" this in Linux by using DMI/SMBIOS type 41 data to reorder
the NICs.  The code is in RHEL 6 and later.  The Dell white paper is

http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf

>From an R720 I have access to:


Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 1
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: :01:00.0

Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 2
Type: Ethernet
Status: Enabled
Type Instance: 2
Bus Address: :01:00.1

Handle 0x2902, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 3
Type: Ethernet
Status: Enabled
Type Instance: 3
Bus Address: :02:00.0

Handle 0x2903, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 4
Type: Ethernet
Status: Enabled
Type Instance: 4
Bus Address: :02:00.1


You can theoretically work from the bus address back to the way Dell
wants the NICs ordered.  Why on earth they can't get the hardware to do
it instead I have *no* idea

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Svnsup architecture [was: Re: svn - but smaller?]

[Peter Jeremy]

On 2013-Jan-25 13:42:19 +0100, Arrigo Marchiori  wrote:
>The current svnsup design is composed of:
>
> 1- svnsup-distill: takes a revision from svn and creates a text file
>(called a delta) that represents it. It seems to be almost
>complete.
>
> 2- svnsup-apply: takes a delta generated by svnsup-distill and applies
>it to an existing source tree. It's currently a work in progress.
>
> 3- a server-side application that runs svnsup-distill and distributes
>the deltas (still to be developed).
>
> 4- a client-side application that fetches new deltas and runs
>svnsup-apply. New trees are "bootstrapped" from other sources,
>e.g.  weekly tarballs (still to be developed).

I think you've just re-invented CTM.  Before spending too much more
time on svnsup, I suggest you read ctm(1).

-- 
Peter Jeremy


pgpfk7Isksqu6.pgp
Description: PGP signature

Re: bge bad performance

[Adrian Chadd]

Disable the offload options (rx checksum, tx checksum, tcp segment
offload) and retry with each option disabled, one at a time.

Hopefully you'll find that one or a combination of options is causing
your issue.

Thanks,


adrian


On 25 January 2013 02:45, Daniel Braniss  wrote:
> Hi,
> It seems that I have more issues with the bge,
>  Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
>
> ifconfig says:
> bge2: flags=8843 metric 0 mtu 1500
>  
> options=c019b O,LINKSTATE>
>  ether xx...
>  inet6 xxx prefixlen 64 scopeid 0x3
>  inet xxx... netmask 0xf000 broadcast yyy
>  nd6 options=21
>  media: Ethernet autoselect (1000baseT )
>  status: active
>
> iperf reports
> [  3]  0.0-10.0 sec   230 MBytes   193 Mbits/sec
>
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Marin Atanasov Nikolov]

On Fri, Jan 25, 2013 at 9:50 PM, Daniel Kalchev  wrote:

>
>
> On 25.01.13 21:44, Marin Atanasov Nikolov wrote:
>
>> Btw, after removing all ZFS snapshots today (more than a 1k) the system
>> is still running (not something I can say for the past few days where I've
>> seen multiple reboots a day).. But it's still early to say that the
>> snapshots might be causing this :)
>>
>
> Might be. If you have something in your daily scripts that traverses each
> and every snapshot (filesystem). I believe this issue with ZFS was fixed
> some time ago. But you might have leftover config files that still trigger
> it.
>
> You could have tried disabling some of the daily scripts to see which one
> triggers the problem.
>
>
Hey Daniel,

I do have rolling ZFS snapshots using zfSnap - daily, weekly and monthly
snapshots are managed by zfSnap. Over the past few months I've accumulated
more than 1k of snapshots, but that was not a problem until very recently.
Maybe the high number of snapshots accumulated in the time caused the
behaviour I'm seeing now.

Anyway, I've cleaned up all snapshots now and will soon know if that was
the root cause or not.

Thanks for feedback :)

Regards,
Marin



> Daniel
>
> __**_
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable
> To unsubscribe, send any mail to 
> "freebsd-stable-unsubscribe@**freebsd.org
> "
>



-- 
Marin Atanasov Nikolov

dnaeon AT gmail DOT com
http://www.unix-heaven.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFC: Suggesting ZFS "best practices" in FreeBSD

[Warren Block]

On Thu, 24 Jan 2013, Jeremy Chadwick wrote:


#1.  Map the physical drive slots to how they show up in FBSD so if a
disk is removed and the machine is rebooted all the disks after that
removed one do not have an 'off by one error'.  i.e. if you have
ada0-ada14 and remove ada8 then reboot - normally FBSD skips that
missing ada8 drive and the next drive (that used to be ada9) is now
called ada8 and so on...


How do you do that?  If I'm in that situation, I think I could find the
bad drive, or at least the good ones, with diskinfo and the drive serial
number.  One suggestion I saw somewhere was to use disk serial numbers
for label values.


The term FreeBSD uses for this is called "wiring down" or "wired down",
and is documented in CAM(4).  It's come up repeatedly over the years but
for whatever reason people overlook it or can't find it.


I was aware of it, it just seems like there ought to be a better way to 
identify drives than by messing with the hardware configuration. 
Something more elegant, less tied to changing the hardware configuration 
of the host.  Assigning the drive serial number as a label, for example.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Daniel Kalchev]

On 25.01.13 21:44, Marin Atanasov Nikolov wrote:
Btw, after removing all ZFS snapshots today (more than a 1k) the 
system is still running (not something I can say for the past few days 
where I've seen multiple reboots a day).. But it's still early to say 
that the snapshots might be causing this :)


Might be. If you have something in your daily scripts that traverses 
each and every snapshot (filesystem). I believe this issue with ZFS was 
fixed some time ago. But you might have leftover config files that still 
trigger it.


You could have tried disabling some of the daily scripts to see which 
one triggers the problem.


Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Marin Atanasov Nikolov]

On Fri, Jan 25, 2013 at 6:49 PM, Chris Rees  wrote:

> I used to get daily(ish) lockups with my server.
>

Hey Chris,


> I guess the drives are mirrored?  Try yanking one for a bit (leave the
> computer on) and try it in another computer.
>

Yep, 2 disks each of 1Tb in a mirror.


> I tried that, and only one of them failed, proving a bad drive.  Seagate
> replaced it.
>

In the past days I have replaced the disks with brand new and excluded them
from the list of possible root causes :)

> This was 2TB, 16G RAM.
>

Have you done any ZFS tuning on the system? I find that the FreeBSD
ZFSTuningGuide page suggests tuning only for i386. Am I right to assume
that I don't need any tuning for amd64, which is my case?

Also is it normal that is I get 5.2Gb usage in ARC on a 8Gb system (not
really sure)?

Btw, after removing all ZFS snapshots today (more than a 1k) the system is
still running (not something I can say for the past few days where I've
seen multiple reboots a day).. But it's still early to say that the
snapshots might be causing this :)

Thanks again,
Marin


> Chris
>



-- 
Marin Atanasov Nikolov

dnaeon AT gmail DOT com
http://www.unix-heaven.org/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Greg Byshenk]

On Fri, Jan 25, 2013 at 03:12:03PM +0200, Daniel Kalchev wrote:
[...]
> It is absurd to require the installation of any port, if your only 
> intention is to update the base system sources.

I think others have already pointed this out, but
"if your only intention is to update the base system
sources", then 'freebsd-update' (from the base system)
will do the job.

Or am I missing/misunderstanding something?

 
-- 
greg byshenk  -  gbysh...@byshenk.net  -  Leiden, NL - Portland, OR USA
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Chris Rees]

On 25 Jan 2013 18:28, "Dimitry Andric"  wrote:
>
> On 2013-01-25 16:41, Chris Rees wrote:
> ...
>
>> I've just created devel/subversion-static that will be available by
pkg_add
>> once the package builds are back.
>
>
> Thanks, but the port does not link on head, due to a problem in apr:
>
> /usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter':
> /usr/ports/devel/apr1/work/apr-1.4.6/strings/apr_snprintf.c:1023:
undefined reference to `isnan'
>
> The issue is that apr-1-config --libs does not list -lm.  Any idea how
> to correct that?

That's a question for Lev really, since it applies equally to
devel/subversion.

I'll fix it tomorrow when I'm back at the keyboard unless Lev fixes it
first.

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Dimitry Andric]

On 2013-01-25 16:41, Chris Rees wrote:
...

I've just created devel/subversion-static that will be available by pkg_add
once the package builds are back.


Thanks, but the port does not link on head, due to a problem in apr:

/usr/local/lib/libapr-1.a(apr_snprintf.o): In function `apr_vformatter':
/usr/ports/devel/apr1/work/apr-1.4.6/strings/apr_snprintf.c:1023: undefined 
reference to `isnan'

The issue is that apr-1-config --libs does not list -lm.  Any idea how
to correct that?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Chris Rees]

On 25 Jan 2013 10:27, "Marin Atanasov Nikolov"  wrote:
>
> On Fri, Jan 25, 2013 at 12:12 PM, Bob Bishop  wrote:
>
> > Hi,
> >
> > On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote:
> >
> > > Hello again :)
> > >
> > > Here's my update on these spontaneous reboots after less than a week
> > since
> > > I've updated to stable/9.
> > >
> > > First two days the system was running fine with no reboots happening,
so
> > I
> > > though that this update actually fixed it, but I was wrong.
> > >
> > > The reboots are still happening and still no clear evidence of the
root
> > > cause. What I did so far:
> > >
> > > * Ran disks tests -- looking good
> > > * Ran memtest -- looking good
> > > * Replaced power cables
> > > * Ran UPS tests -- looking good
> > > * Checked for any bad capacitors -- none found
> > > * Removed all ZFS snapshots
> > >
> > > There is also one more machine connected to the same UPS, so if it
was a
> > > UPS issue I'd expect that the other one reboots too, but that's not
the
> > > case.
> > >
> > > Now that I've excluded the hardware part of this problem
> >
> > Have you done anything to rule out the machine's power supply?
> >
> >
>
> Hi,
>
> Yes, it's a brand new one.
>
> Regards,
> Marin
>
>
>
> > > I started looking
> > > again into the software side, and this time in particular -- ZFS.
> > >
> > > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of
> > memory.

I used to get daily(ish) lockups with my server.

I guess the drives are mirrored?  Try yanking one for a bit (leave the
computer on) and try it in another computer.

I tried that, and only one of them failed, proving a bad drive.  Seagate
replaced it.

This was 2TB, 16G RAM.

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge bad performance

[Fleuriot Damien]

On Jan 25, 2013, at 4:56 PM, Daniel Braniss  wrote:

>>> On 25 Jan 2013, at 11:45, Daniel Braniss  wrote:
>> 
>>> Hi,
>>> It seems that I have more issues with the bge,
>>>Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
>>> 
>>> ifconfig says:
>>> bge2: flags=8843 metric 0 mtu 15=00
>>> options=c019b>> O,LINKSTATE>
>>> ether xx...
>>> inet6 xxx prefixlen 64 scopeid 0x3
>>> inet xxx... netmask 0xf000 broadcast yyy
>>> nd6 options=21
>>> media: Ethernet autoselect (1000baseT )
>>> status: active
>>> 
>>> iperf reports
>>> [  3]  0.0-10.0 sec   230 MBytes   193 Mbits/sec
>>> 
>> 
>> Post your iperf command line and explain the test environment, as in direct 
>> connection vs switched network link ?
>> 
> 
> I run iperf -s on the same host for a long time, so not to
> influence the results.
> the network is switched, and I try out several other host to be able to
> a- compare
> b- detect if the network is too busy.
> c- to somehow 'normalize'
> 
> what promped me to check iperf in this case was that tar via NFS started to 
> give
> read timeouts.
> 
> so I run perf -c:
> with 
> dev.bge.2.forced_collapse: 0 or 1
> dev.bge.2.msi: 1
> pe-04> iperf -c minbari
> 
> Client connecting to minbari, TCP port 5001
> TCP window size:  257 KByte (default)
> 
> [  3] local 132.65.16.35 port 12835 connected with 132.65.16.212 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec   238 MBytes   200 Mbits/sec
> 
> setting:
> dev.bge.2.forced_collapse:1
> dev.bge.2.msi:1
> pe-04> iperf -c minbari
> 
> Client connecting to minbari, TCP port 5001
> TCP window size:  257 KByte (default)
> 
> [  3] local 132.65.16.35 port 23207 connected with 132.65.16.212 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec   506 MBytes   425 Mbits/sec
> 
> the same command from a similar host, but with bce:
> Client connecting to minbari, TCP port 5001
> TCP window size:  257 KByte (default)
> 
> [  3] local 132.65.80.2 port 30664 connected with 132.65.16.212 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec   976 MBytes   818 Mbits/sec
> 
> In case it's not obvious, all hosts are server class, the network shows no 
> errors,
> neither the hosts.
> 
> cheers
>   danny


Just did a quick roundup of our boxes and all I've got is bce, re and em 
interfaces, I won't be able to help you much :(

Try playing with iperf's args, like the buffers and number of // connections ?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge bad performance

[Daniel Braniss]

> > On 25 Jan 2013, at 11:45, Daniel Braniss  wrote:
> 
> > Hi,
> > It seems that I have more issues with the bge,
> > Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
> > 
> > ifconfig says:
> > bge2: flags=8843 metric 0 mtu 15=00
> > options=c019b > O,LINKSTATE>
> > ether xx...
> > inet6 xxx prefixlen 64 scopeid 0x3
> > inet xxx... netmask 0xf000 broadcast yyy
> > nd6 options=21
> > media: Ethernet autoselect (1000baseT )
> > status: active
> >
> > iperf reports
> > [  3]  0.0-10.0 sec   230 MBytes   193 Mbits/sec
> > 
> 
> Post your iperf command line and explain the test environment, as in direct 
> connection vs switched network link ?
> 

I run iperf -s on the same host for a long time, so not to
influence the results.
the network is switched, and I try out several other host to be able to
a- compare
b- detect if the network is too busy.
c- to somehow 'normalize'

what promped me to check iperf in this case was that tar via NFS started to 
give
read timeouts.

so I run perf -c:
with 
dev.bge.2.forced_collapse: 0 or 1
dev.bge.2.msi: 1
pe-04> iperf -c minbari

Client connecting to minbari, TCP port 5001
TCP window size:  257 KByte (default)

[  3] local 132.65.16.35 port 12835 connected with 132.65.16.212 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   238 MBytes   200 Mbits/sec

setting:
dev.bge.2.forced_collapse:1
dev.bge.2.msi:1
pe-04> iperf -c minbari

Client connecting to minbari, TCP port 5001
TCP window size:  257 KByte (default)

[  3] local 132.65.16.35 port 23207 connected with 132.65.16.212 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   506 MBytes   425 Mbits/sec

the same command from a similar host, but with bce:
Client connecting to minbari, TCP port 5001
TCP window size:  257 KByte (default)

[  3] local 132.65.80.2 port 30664 connected with 132.65.16.212 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   976 MBytes   818 Mbits/sec

In case it's not obvious, all hosts are server class, the network shows no 
errors,
neither the hosts.

cheers
danny




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Warren Block]

On Fri, 25 Jan 2013, Andriy Gapon wrote:


on 25/01/2013 12:26 Marin Atanasov Nikolov said the following:

Yes, it's a brand new one.


Then no: http://en.wikipedia.org/wiki/Bathtub_curve


But if a new (as in "replacement") power supply does not change the 
symptoms, it's likely not the problem.


The last post of that forum thread says there was corruption in the ZFS 
filesystem.

http://forums.freebsd.org/showthread.php?t=9143

That is also a very old thread, so details might not apply any more. 
But a successful scrub would show both that the filesystem is okay and 
that ZFS can complete a scrub.  (If that's been mentioned already, never 
mind.)

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Ian Smith]

On Fri, 25 Jan 2013 15:38:33 +, Matthew Seaman wrote:
 > On 25/01/2013 13:38, Ian Smith wrote:
 > > I'm trying to work out exactly when support for checking out 9-STABLE 
 > > CVS sources - and I'm only talking about system sources here - will end?
 > 
 > The date that CVS for src will cease to be kept in sync with SVN and
 > when cvsup etc. are officially withdrawn for src -- that date has not
 > been announced yet[*]  All we know with any certainly is that CVS is
 > deprecated and will be withdrawn sooner rather than later.
 > 
 > There will be an announcement closer to the end-date once that has
 > firmed up.  I assume that there will be a reasonable grace period for
 > die-hard CVS/cvsup users to finish getting themselves sorted out,
 > although given the quantity of advance warnings sensible people will
 > already be well advanced (if not complete) in their projects for
 > migrating away.
 > 
 >  Cheers,
 > 
 >  Matthew

Thankyou for that Matthew.  Hopefully by then we might have something 
lighter than full-blown SVN for die-hard (cough) and newbie users alike.

 > [*] Unlike ports CVS which is closing down on 28th February

Sure.  Deadlines are fine, especially whilever still in the future :)

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge numbering

[Daniel Braniss]

> On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote:
> > Hi,
> > this server, a Dell R720 has 4 bge on board,
> >  Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
> >  bge0: APE FW version: NCSI v1.1.7.0
> >  bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
> >  miibus0:  on bge0
> >  ...
> > 
> > I have connected the ethernet to port labeled 0, but it appears
> > as bge2, how can this be corrected?
> 
> It can't really.  The order of PCI devices is determined by the layout of the 
> PCI device hierarchy which is generally determined by the physical traces on 
> your motherboard.

so you are saying that Dell screwed up yet again?
the 4 bges have consecutive macs, bge1 = bge0 +1, bge2 = bge1 + 1, etc. It's
only the # 'outside' that is wrong? I will try the usual trial and error
to find the mapping, but will have to wait till Sunday.

thanks,
danny


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Chris Rees]

On 25 Jan 2013 13:39, "Ian Smith"  wrote:
>
> On Thu, 24 Jan 2013 00:57:17 -0800, 'Jeremy Chadwick' wrote:
>
>  > On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote:
>  > > The objective is to return to a base build of FreeBSD that performs
>  > > the expected task of being able to pull source, without having to
>  > > acquire a port.  Regardless of our individual solutions/workarounds,
>  > > the task is to pull and maintain source.
>  > >
>  > > Is the discussion going to result in something like svn-lite that
>  > > enters into the /usr/src/contrib along with the responsibilities
>  > > associated with maintaining it?  And then we need to take into
>  > > consideration of being overwriting the "base svn" with a full svn
>  > > package, if required by the user/admin.
> [..]
>  > > I build svn from ports with all options off except for:
>  > > ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn
>  > > program. Suites me but doesn't address the underlying problem - and I
>  > > don't think that the plan is to make FreeBSD dependent upon the ports
>  > > system (for subversion)
>
> [..]
>  > As for your last line:
>  >
>  > FreeBSD is already dependent upon Subversion.  This has been the case
>  > for quite some time, but has only recently (as an indirect result of
the
>  > security incident) become forced upon users/administrators of FreeBSD.
>  > The entire project is presently managed/maintained under Subversion.
>  > The Handbook now documents that if you want to pull down src/ you need
>  > to install Subversion.  If you want to pull down ports/ you can use
>  > portsnap and waste lots of /var space, hoping that the portsnap mirrors
>  > are up to date, and a bunch of other hullabaloo... or you could just
use
>  > Subversion and be done with it.
>  >
>  > There is no more cvsup.  There is no more csup.  There is no more cvs.
>
> I'm trying to work out exactly when support for checking out 9-STABLE
> CVS sources - and I'm only talking about system sources here - will end?
>
> Peter Wemm (cc'd) writes in https://wiki.freebsd.org/CvsIsDeprecated,
> last edited 2013-01-22:
>
>   "3. For FreeBSD 9-stable, 8-stable and 7-stable, we will be attempting
> to continue updates through the exporter the official "support"
> end-of-life for last release on the branch at the time of writing
> (November 16th, 2012).
>   * This means, updates will be maintained on a best effort
> basis until 9.0-RELEASE, 8.3-RELEASE, 7.4-RELEASE are no longer
> supported.
>   * This notice pre-dates 9.1-RELEASE, and the release of 9.1
> will not extend the lifetime of RELENG_9 branch exporter.
>   * This is not a commitment to operate the services, it will
> only be done on a best effort basis. If serious problems develop or
> usage dies down significantly we may accelerate its end-of-life."
>
> But after kerfuffle about 9.1-RELEASE branch sources not (then) being
> available via c{v,}sup, Bjoern Zeeb wrote on Sept 18th 2012 in
>
http://lists.freebsd.org/pipermail/freebsd-stable/2012-September/069600.html
> "RELENG_9_1 is now exported the CVS as well and will be for as long as
> things will be exported to CVS."  Other posts around that time clearly
> said that CVS source access would remain for the lifetime of 9-STABLE.
>
> Could someone please clarify this situation?
>
> As others have suggested, an SVN package that could be installed with a
> static build and run dependency-free binary would help ease the pain for
> those looking specifically at updating 9.x or 8.x sources to -STABLE as
> a directly usable csup replacement, preferably on install media but at
> least easily fetchable as a package?  I find portsnap fine for ports.

I've just created devel/subversion-static that will be available by pkg_add
once the package builds are back.

Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Matthew Seaman]

On 25/01/2013 13:38, Ian Smith wrote:
> I'm trying to work out exactly when support for checking out 9-STABLE 
> CVS sources - and I'm only talking about system sources here - will end?

The date that CVS for src will cease to be kept in sync with SVN and
when cvsup etc. are officially withdrawn for src -- that date has not
been announced yet[*]  All we know with any certainly is that CVS is
deprecated and will be withdrawn sooner rather than later.

There will be an announcement closer to the end-date once that has
firmed up.  I assume that there will be a reasonable grace period for
die-hard CVS/cvsup users to finish getting themselves sorted out,
although given the quantity of advance warnings sensible people will
already be well advanced (if not complete) in their projects for
migrating away.

Cheers,

Matthew


[*] Unlike ports CVS which is closing down on 28th February
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge numbering

[John Baldwin]

On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote:
> Hi,
> this server, a Dell R720 has 4 bge on board,
>  Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
>  bge0: APE FW version: NCSI v1.1.7.0
>  bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
>  miibus0:  on bge0
>  ...
> 
> I have connected the ethernet to port labeled 0, but it appears
> as bge2, how can this be corrected?

It can't really.  The order of PCI devices is determined by the layout of the 
PCI device hierarchy which is generally determined by the physical traces on 
your motherboard.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Fleuriot Damien]

On Jan 25, 2013, at 2:38 PM, Ian Smith  wrote:
> 
> As others have suggested, an SVN package that could be installed with a 
> static build and run dependency-free binary would help ease the pain for 
> those looking specifically at updating 9.x or 8.x sources to -STABLE as 
> a directly usable csup replacement, preferably on install media but at 
> least easily fetchable as a package?  I find portsnap fine for ports.
> 
> cheers, Ian


Actually, for anyone running 8.x amd64 and too lazy to build SVN (or who can't 
be bothered with its dependencies), you can get my static build here:
http://my.gd/svn

Checksum should match this, after download:
MD5 (/usr/local/bin/svn) = 204df5cd31b94c49611890893c7c2aba



% uname -a
FreeBSD pf1.backbone.dev 8.3-STABLE FreeBSD 8.3-STABLE #0 r245223: Wed Jan  9 
14:03:15 UTC 2013 r...@pf1.backbone.dev:/usr/obj/usr/src/sys/UNIVERSAL  
amd64

% ldd /usr/local/bin/svn
ldd: /usr/local/bin/svn: not a dynamic ELF executable

% ls -l /usr/local/bin/svn
-rwxr-xr-x  1 root  wheel  4205656 Jan 22 16:51 /usr/local/bin/svn

% cd /usr/ports/devel/subversion
% make showconfig
===> The following configuration options are available for subversion-1.7.8:
 BDB=off: Berkeley Database
 BOOK=off: Install the Subversion Book
 ENHANCED_KEYWORD=off: Enhanced svn:keyword support
 FREEBSD_TEMPLATE=off: FreeBSD Project log template
 GNOME_KEYRING=off: Build with GNOME Keyring auth support
 KDE_KWALLET=off: Build with KDE KWallet auth support
 MAINTAINER_DEBUG=off: Build debug version
 MOD_DAV_SVN=off: mod_dav_svn module for Apache 2.X
 MOD_DONTDOTHAT=off: mod_dontdothat for Apache 2.X
 NEON=off: WebDAV/Delta-V repo access module (neon)
 P4_STYLE_MARKERS=off: Perforce-style conflict markers
 SASL=off: SASL support
 SERF=off: WebDAV/Delta-V repo access module (serf)
 STATIC=on: Build static version (no shared libs)
 SVNAUTHZ_VALIDATE=off: install svnauthz-validate
 SVNMUCC=off: Install Multiple URL Command Client
 SVNSERVE_WRAPPER=off: Enable svnserve wrapper
 TEST=off: Run subversion test suite



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Oliver Brandmueller]

On Fri, Jan 25, 2013 at 10:27:23AM +0100, Oliver Brandmueller wrote:
...

an Ian Smith and des for working on a svnsup solution, which also might 
in the future be something that solves the problem!

- Oliver

-- 
| Oliver Brandmueller  http://sysadm.in/ o...@sysadm.in |
|Ich bin das Internet. Sowahr ich Gott helfe. |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge bad performance

[Damien Fleuriot]

On 25 Jan 2013, at 11:45, Daniel Braniss  wrote:

> Hi,
> It seems that I have more issues with the bge,
> Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
> 
> ifconfig says:
> bge2: flags=8843 metric 0 mtu 1500
> options=c019b O,LINKSTATE>
> ether xx...
> inet6 xxx prefixlen 64 scopeid 0x3 
> inet xxx... netmask 0xf000 broadcast yyy
> nd6 options=21
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> iperf reports
> [  3]  0.0-10.0 sec   230 MBytes   193 Mbits/sec
> 

Post your iperf command line and explain the test environment, as in direct 
connection vs switched network link ?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Ian Smith]

On Thu, 24 Jan 2013 00:57:17 -0800, 'Jeremy Chadwick' wrote:

 > On Thu, Jan 24, 2013 at 06:34:33PM +1100, Dewayne wrote:
 > > The objective is to return to a base build of FreeBSD that performs
 > > the expected task of being able to pull source, without having to
 > > acquire a port.  Regardless of our individual solutions/workarounds,
 > > the task is to pull and maintain source.
 > > 
 > > Is the discussion going to result in something like svn-lite that
 > > enters into the /usr/src/contrib along with the responsibilities
 > > associated with maintaining it?  And then we need to take into
 > > consideration of being overwriting the "base svn" with a full svn
 > > package, if required by the user/admin.
[..]
 > > I build svn from ports with all options off except for:
 > > ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC which results in a 4.2MB svn
 > > program. Suites me but doesn't address the underlying problem - and I
 > > don't think that the plan is to make FreeBSD dependent upon the ports
 > > system (for subversion)

[..]
 > As for your last line:
 > 
 > FreeBSD is already dependent upon Subversion.  This has been the case
 > for quite some time, but has only recently (as an indirect result of the
 > security incident) become forced upon users/administrators of FreeBSD.
 > The entire project is presently managed/maintained under Subversion.
 > The Handbook now documents that if you want to pull down src/ you need
 > to install Subversion.  If you want to pull down ports/ you can use
 > portsnap and waste lots of /var space, hoping that the portsnap mirrors
 > are up to date, and a bunch of other hullabaloo... or you could just use
 > Subversion and be done with it.
 > 
 > There is no more cvsup.  There is no more csup.  There is no more cvs.

I'm trying to work out exactly when support for checking out 9-STABLE 
CVS sources - and I'm only talking about system sources here - will end?

Peter Wemm (cc'd) writes in https://wiki.freebsd.org/CvsIsDeprecated, 
last edited 2013-01-22:

  "3. For FreeBSD 9-stable, 8-stable and 7-stable, we will be attempting 
to continue updates through the exporter the official "support" 
end-of-life for last release on the branch at the time of writing 
(November 16th, 2012).
  * This means, updates will be maintained on a best effort 
basis until 9.0-RELEASE, 8.3-RELEASE, 7.4-RELEASE are no longer 
supported.
  * This notice pre-dates 9.1-RELEASE, and the release of 9.1 
will not extend the lifetime of RELENG_9 branch exporter.
  * This is not a commitment to operate the services, it will 
only be done on a best effort basis. If serious problems develop or 
usage dies down significantly we may accelerate its end-of-life."

But after kerfuffle about 9.1-RELEASE branch sources not (then) being 
available via c{v,}sup, Bjoern Zeeb wrote on Sept 18th 2012 in 
http://lists.freebsd.org/pipermail/freebsd-stable/2012-September/069600.html 
"RELENG_9_1 is now exported the CVS as well and will be for as long as 
things will be exported to CVS."  Other posts around that time clearly 
said that CVS source access would remain for the lifetime of 9-STABLE.

Could someone please clarify this situation?

As others have suggested, an SVN package that could be installed with a 
static build and run dependency-free binary would help ease the pain for 
those looking specifically at updating 9.x or 8.x sources to -STABLE as 
a directly usable csup replacement, preferably on install media but at 
least easily fetchable as a package?  I find portsnap fine for ports.

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Daniel Kalchev]

On 23.01.13 21:09, Peter Wemm wrote:

On Wed, Jan 23, 2013 at 9:05 AM, Isaac (.ike) Levy
  wrote:


1) License.  Many of SVN's dependencies will never be available in the FreeBSD 
source.
While this is totally OK for development, SVN is 3rd party software, this is 
unacceptable to force as 'the' respected path for OS source builds.

Don't confuse the excessive ports default settings as dependencies.
You can make a quite mean and lean svn client.  I did a 100%
BSD-license-compatible src/contrib/svn style proof-of-concept back
when we were planning what to do.  Things like gdbm and bdb are not
required and are license contamination that we don't need.  But that's
the fault of the port, not a fundamental property of using svn.



The logical question is then: Why is this slimmed down, fully BSD 
license compatible svn not in the base system by now?


It is absurd to require the installation of any port, if your only 
intention is to update the base system sources.


Portsnap is an entirely different mess.

Daniel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Svnsup architecture [was: Re: svn - but smaller?]

[Arrigo Marchiori]

On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy Chadwick' wrote:

[...]
> Also, just as a footnote point to readers: please do not bring up
> svnsup.  Until it's stated by some official FreeBSD person that
> "{committers} are actively working on this and bringing it into the base
> system so people can get src/ports without installing
> ports/devel/subversion", it's not pragmatic to mention it as a
> *solution*.

I take the chance of this thread to tell my understanding of the
svnsup project and how and why it should answer our concerns.

I am not a "FreeBSD official person", but I hope I still can bring a
bit of useful information.

Disclaimer: I only had a small e-mail exchange with des, who is the
author of svnsup. 90% of this message are my opinions; the other 10%
is copy'n paste from des' emails. I am currently trying to contribute
to the software; my opinions are made after studying parts of the
current source code.

The current svnsup design is composed of:

 1- svnsup-distill: takes a revision from svn and creates a text file
(called a delta) that represents it. It seems to be almost
complete.

 2- svnsup-apply: takes a delta generated by svnsup-distill and applies
it to an existing source tree. It's currently a work in progress.

 3- a server-side application that runs svnsup-distill and distributes
the deltas (still to be developed).

 4- a client-side application that fetches new deltas and runs
svnsup-apply. New trees are "bootstrapped" from other sources,
e.g.  weekly tarballs (still to be developed).

The FreeBSD base system could only contain applications 2 and
4. Neither of them depends on any SVN-related library: deltas are
simple text files.

Efficiency, if I understood correctly, was one of the key features of
cvsup. This is why svnsup only transfers "deltas".

To answer one of John Mehr's problems: MD5 sums are calculated by
svnsup-distill and included in the deltas. The client only needs to
check them against the local files.

I think that svnsup still needs a lot of work before becoming
usable. But some of the fundamental parts are there, and the projects
can count on at least two developers. :-)
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bge bad performance

[Daniel Braniss]

Hi,
It seems that I have more issues with the bge,
 Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572

ifconfig says:
bge2: flags=8843 metric 0 mtu 1500
 options=c019b
 ether xx...
 inet6 xxx prefixlen 64 scopeid 0x3 
 inet xxx... netmask 0xf000 broadcast yyy
 nd6 options=21
 media: Ethernet autoselect (1000baseT )
 status: active

iperf reports
[  3]  0.0-10.0 sec   230 MBytes   193 Mbits/sec


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Andriy Gapon]

on 25/01/2013 12:26 Marin Atanasov Nikolov said the following:
> Yes, it's a brand new one.

Then no: http://en.wikipedia.org/wiki/Bathtub_curve

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Marin Atanasov Nikolov]

On Fri, Jan 25, 2013 at 12:12 PM, Bob Bishop  wrote:

> Hi,
>
> On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote:
>
> > Hello again :)
> >
> > Here's my update on these spontaneous reboots after less than a week
> since
> > I've updated to stable/9.
> >
> > First two days the system was running fine with no reboots happening, so
> I
> > though that this update actually fixed it, but I was wrong.
> >
> > The reboots are still happening and still no clear evidence of the root
> > cause. What I did so far:
> >
> > * Ran disks tests -- looking good
> > * Ran memtest -- looking good
> > * Replaced power cables
> > * Ran UPS tests -- looking good
> > * Checked for any bad capacitors -- none found
> > * Removed all ZFS snapshots
> >
> > There is also one more machine connected to the same UPS, so if it was a
> > UPS issue I'd expect that the other one reboots too, but that's not the
> > case.
> >
> > Now that I've excluded the hardware part of this problem
>
> Have you done anything to rule out the machine's power supply?
>
>

Hi,

Yes, it's a brand new one.

Regards,
Marin



> > I started looking
> > again into the software side, and this time in particular -- ZFS.
> >
> > I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of
> memory.
> >
> > A quick look at top(1) showed lots of memory usage by ARC and my
> available
> > free memory dropping fast. I've made a screenshot, which you can see on
> the
> > link below:
> >
> > * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg
> >
> > So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide
> [1],
> > but honestly at the end I was not sure which parameters I need to
> > increase/decrease and to what values.
> >
> > Here's some info about my current parameters.
> >
> >% sysctl vm.kmem_size_max
> >vm.kmem_size_max: 329853485875
> >
> >% sysctl vm.kmem_size
> >vm.kmem_size: 8279539712
> >
> >% sysctl vfs.zfs.arc_max
> >vfs.zfs.arc_max: 7205797888
> >
> >% sysctl kern.maxvnodes
> >kern.maxvnodes: 206227
> >
> > There's one script at the ZFSTuningGuide which calculates kernel memory
> > utilization, and for me these values are listed below:
> >
> >TEXT=22402749, 21.3649 MB
> >DATA=4896264192, 4669.44 MB
> >TOTAL=4918666941, 4690.81 MB
> >
> > While looking for ZFS tuning I've also stumbled upon this thread in the
> > FreeBSD Forums [2], where the OP describes a similar behaviour to what I
> am
> > already experiencing, so I'm quite worried now that the reason for these
> > crashes is ZFS.
> >
> > Before jumping into any change to the kernel parameters (vm.kmem_size,
> > vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any
> > feedback from people that have already done such optimizations on their
> ZFS
> > systems.
> >
> > Could you please share what are the optimal values for these parameters
> on
> > a system with 8Gb of memory? Is there a way to calculate these values or
> is
> > it just a "test-and-see-which-fits-better" way of doing this?
> >
> > Thanks and regards,
> > Marin
> >
> > [1]: https://wiki.freebsd.org/ZFSTuningGuide
> > [2]: http://forums.freebsd.org/showthread.php?t=9143
> >
> >
> > On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov <
> dna...@gmail.com>wrote:
> >
> >>
> >>
> >>
> >> On Sat, Jan 19, 2013 at 10:19 PM, John  wrote:
> >>
>  At 03:00am I can see that periodic(8) runs, but I don't see what could
> >>> have
>  taken so much of the free memory. I'm also running this system on ZFS
> and
>  have daily rotating ZFS snapshots created - currently the number of
> ZFS
>  snapshots are > 1000, and not sure if that could be causing this.
> Here's
> >>> a
>  list of the periodic(8) daily scripts that run at 03:00am time.
> 
>  % ls -1 /etc/periodic/daily
>  800.scrub-zfs
> 
>  % ls -1 /usr/local/etc/periodic/daily
>  402.zfSnap
>  403.zfSnap_delete
> >>>
> >>> On a couple of my zfs machines, I've found running a scrub along with
> >>> other
> >>> high file system users to be a problem.  I therefore run scrub from
> cron
> >>> and
> >>> schedule it so it doesn't overlap with periodic.
> >>>
> >>> I also found on a machine with an i3 and 4G ram that overlapping scrubs
> >>> and
> >>> snapshot destroy would cause the machine to grind to the point of being
> >>> non-responsive. This was not a problem when the machine was new, but
> >>> became one
> >>> as the pool got larger (dedup is off and the pool is at 45% capacity).
> >>>
> >>> I use my own zfs management script and it prevents snapshot destroys
> from
> >>> overlapping scrubs, and with a lockfile it prevents a new destroy from
> >>> being
> >>> initiated when an old one is still running.
> >>>
> >>> zfSnap has its -S switch to prevent actions during a scrub which you
> >>> should
> >>> use if you haven't already.
> >>>
> >>>
> >> Hi John,
> >>
> >> Thanks for the hints. It was a long time since I've setup zfSnap and
> I've
> >> just checked the con

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Bob Bishop]

Hi,

On 25 Jan 2013, at 09:29, Marin Atanasov Nikolov wrote:

> Hello again :)
> 
> Here's my update on these spontaneous reboots after less than a week since
> I've updated to stable/9.
> 
> First two days the system was running fine with no reboots happening, so I
> though that this update actually fixed it, but I was wrong.
> 
> The reboots are still happening and still no clear evidence of the root
> cause. What I did so far:
> 
> * Ran disks tests -- looking good
> * Ran memtest -- looking good
> * Replaced power cables
> * Ran UPS tests -- looking good
> * Checked for any bad capacitors -- none found
> * Removed all ZFS snapshots
> 
> There is also one more machine connected to the same UPS, so if it was a
> UPS issue I'd expect that the other one reboots too, but that's not the
> case.
> 
> Now that I've excluded the hardware part of this problem

Have you done anything to rule out the machine's power supply?

> I started looking
> again into the software side, and this time in particular -- ZFS.
> 
> I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of memory.
> 
> A quick look at top(1) showed lots of memory usage by ARC and my available
> free memory dropping fast. I've made a screenshot, which you can see on the
> link below:
> 
> * http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg
> 
> So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide [1],
> but honestly at the end I was not sure which parameters I need to
> increase/decrease and to what values.
> 
> Here's some info about my current parameters.
> 
>% sysctl vm.kmem_size_max
>vm.kmem_size_max: 329853485875
> 
>% sysctl vm.kmem_size
>vm.kmem_size: 8279539712
> 
>% sysctl vfs.zfs.arc_max
>vfs.zfs.arc_max: 7205797888
> 
>% sysctl kern.maxvnodes
>kern.maxvnodes: 206227
> 
> There's one script at the ZFSTuningGuide which calculates kernel memory
> utilization, and for me these values are listed below:
> 
>TEXT=22402749, 21.3649 MB
>DATA=4896264192, 4669.44 MB
>TOTAL=4918666941, 4690.81 MB
> 
> While looking for ZFS tuning I've also stumbled upon this thread in the
> FreeBSD Forums [2], where the OP describes a similar behaviour to what I am
> already experiencing, so I'm quite worried now that the reason for these
> crashes is ZFS.
> 
> Before jumping into any change to the kernel parameters (vm.kmem_size,
> vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any
> feedback from people that have already done such optimizations on their ZFS
> systems.
> 
> Could you please share what are the optimal values for these parameters on
> a system with 8Gb of memory? Is there a way to calculate these values or is
> it just a "test-and-see-which-fits-better" way of doing this?
> 
> Thanks and regards,
> Marin
> 
> [1]: https://wiki.freebsd.org/ZFSTuningGuide
> [2]: http://forums.freebsd.org/showthread.php?t=9143
> 
> 
> On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov 
> wrote:
> 
>> 
>> 
>> 
>> On Sat, Jan 19, 2013 at 10:19 PM, John  wrote:
>> 
 At 03:00am I can see that periodic(8) runs, but I don't see what could
>>> have
 taken so much of the free memory. I'm also running this system on ZFS and
 have daily rotating ZFS snapshots created - currently the number of ZFS
 snapshots are > 1000, and not sure if that could be causing this. Here's
>>> a
 list of the periodic(8) daily scripts that run at 03:00am time.
 
 % ls -1 /etc/periodic/daily
 800.scrub-zfs
 
 % ls -1 /usr/local/etc/periodic/daily
 402.zfSnap
 403.zfSnap_delete
>>> 
>>> On a couple of my zfs machines, I've found running a scrub along with
>>> other
>>> high file system users to be a problem.  I therefore run scrub from cron
>>> and
>>> schedule it so it doesn't overlap with periodic.
>>> 
>>> I also found on a machine with an i3 and 4G ram that overlapping scrubs
>>> and
>>> snapshot destroy would cause the machine to grind to the point of being
>>> non-responsive. This was not a problem when the machine was new, but
>>> became one
>>> as the pool got larger (dedup is off and the pool is at 45% capacity).
>>> 
>>> I use my own zfs management script and it prevents snapshot destroys from
>>> overlapping scrubs, and with a lockfile it prevents a new destroy from
>>> being
>>> initiated when an old one is still running.
>>> 
>>> zfSnap has its -S switch to prevent actions during a scrub which you
>>> should
>>> use if you haven't already.
>>> 
>>> 
>> Hi John,
>> 
>> Thanks for the hints. It was a long time since I've setup zfSnap and I've
>> just checked the configuration and I am using the "-s -S" flags, so there
>> should be no overlapping.
>> 
>> Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying
>> to reboot the system (which appears to be discussed a lot in a separate
>> thread).
>> 
>> Then I've updated to stable/9, so at the least the reboot issue is now
>> solved. Since I've to stable/9 I'm monitoring the syste

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Bas Smeelen]

On 01/25/2013 10:29 AM, Marin Atanasov Nikolov wrote:

Hello again :)

Here's my update on these spontaneous reboots after less than a week since
I've updated to stable/9.

First two days the system was running fine with no reboots happening, so I
though that this update actually fixed it, but I was wrong.


Not really a solution but you can take a look at sysutils/zfs-stats



The reboots are still happening and still no clear evidence of the root
cause. What I did so far:

* Ran disks tests -- looking good
* Ran memtest -- looking good
* Replaced power cables
* Ran UPS tests -- looking good
* Checked for any bad capacitors -- none found
* Removed all ZFS snapshots

There is also one more machine connected to the same UPS, so if it was a
UPS issue I'd expect that the other one reboots too, but that's not the
case.

Now that I've excluded the hardware part of this problem I started looking
again into the software side, and this time in particular -- ZFS.

I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of memory.

A quick look at top(1) showed lots of memory usage by ARC and my available
free memory dropping fast. I've made a screenshot, which you can see on the
link below:

* http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg

So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide [1],
but honestly at the end I was not sure which parameters I need to
increase/decrease and to what values.

Here's some info about my current parameters.

 % sysctl vm.kmem_size_max
 vm.kmem_size_max: 329853485875

 % sysctl vm.kmem_size
 vm.kmem_size: 8279539712

 % sysctl vfs.zfs.arc_max
 vfs.zfs.arc_max: 7205797888

 % sysctl kern.maxvnodes
 kern.maxvnodes: 206227

There's one script at the ZFSTuningGuide which calculates kernel memory
utilization, and for me these values are listed below:

 TEXT=22402749, 21.3649 MB
 DATA=4896264192, 4669.44 MB
 TOTAL=4918666941, 4690.81 MB

While looking for ZFS tuning I've also stumbled upon this thread in the
FreeBSD Forums [2], where the OP describes a similar behaviour to what I am
already experiencing, so I'm quite worried now that the reason for these
crashes is ZFS.

Before jumping into any change to the kernel parameters (vm.kmem_size,
vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any
feedback from people that have already done such optimizations on their ZFS
systems.

Could you please share what are the optimal values for these parameters on
a system with 8Gb of memory? Is there a way to calculate these values or is
it just a "test-and-see-which-fits-better" way of doing this?

Thanks and regards,
Marin

[1]: https://wiki.freebsd.org/ZFSTuningGuide
[2]: http://forums.freebsd.org/showthread.php?t=9143


On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov wrote:




On Sat, Jan 19, 2013 at 10:19 PM, John  wrote:


At 03:00am I can see that periodic(8) runs, but I don't see what could

have

taken so much of the free memory. I'm also running this system on ZFS and
have daily rotating ZFS snapshots created - currently the number of ZFS
snapshots are > 1000, and not sure if that could be causing this. Here's

a

list of the periodic(8) daily scripts that run at 03:00am time.

% ls -1 /etc/periodic/daily
800.scrub-zfs

% ls -1 /usr/local/etc/periodic/daily
402.zfSnap
403.zfSnap_delete

On a couple of my zfs machines, I've found running a scrub along with
other
high file system users to be a problem.  I therefore run scrub from cron
and
schedule it so it doesn't overlap with periodic.

I also found on a machine with an i3 and 4G ram that overlapping scrubs
and
snapshot destroy would cause the machine to grind to the point of being
non-responsive. This was not a problem when the machine was new, but
became one
as the pool got larger (dedup is off and the pool is at 45% capacity).

I use my own zfs management script and it prevents snapshot destroys from
overlapping scrubs, and with a lockfile it prevents a new destroy from
being
initiated when an old one is still running.

zfSnap has its -S switch to prevent actions during a scrub which you
should
use if you haven't already.



Hi John,

Thanks for the hints. It was a long time since I've setup zfSnap and I've
just checked the configuration and I am using the "-s -S" flags, so there
should be no overlapping.

Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying
to reboot the system (which appears to be discussed a lot in a separate
thread).

Then I've updated to stable/9, so at the least the reboot issue is now
solved. Since I've to stable/9 I'm monitoring the system's memory usage and
so far it's been pretty stable, so I'll keep an eye of an update to
stable/9 has actually fixed this strange issue.

Thanks again,
Marin



Since making these changes, a machine that would have to be rebooted
several
times a week has now been up 61 days.

John Theus
TheUs Group




--
Marin Atanasov Nikolov

dnaeon AT gmail DOT co

Re: Spontaneous reboots on Intel i5 and FreeBSD 9.0

[Marin Atanasov Nikolov]

Hello again :)

Here's my update on these spontaneous reboots after less than a week since
I've updated to stable/9.

First two days the system was running fine with no reboots happening, so I
though that this update actually fixed it, but I was wrong.

The reboots are still happening and still no clear evidence of the root
cause. What I did so far:

* Ran disks tests -- looking good
* Ran memtest -- looking good
* Replaced power cables
* Ran UPS tests -- looking good
* Checked for any bad capacitors -- none found
* Removed all ZFS snapshots

There is also one more machine connected to the same UPS, so if it was a
UPS issue I'd expect that the other one reboots too, but that's not the
case.

Now that I've excluded the hardware part of this problem I started looking
again into the software side, and this time in particular -- ZFS.

I'm running FreeBSD 9.1-STABLE #1 r245686 on a Intel i5 with 8Gb of memory.

A quick look at top(1) showed lots of memory usage by ARC and my available
free memory dropping fast. I've made a screenshot, which you can see on the
link below:

* http://users.unix-heaven.org/~dnaeon/top-zfs-arc.jpg

So I went to the FreeBSD Wiki and started reading the ZFS Tuning Guide [1],
but honestly at the end I was not sure which parameters I need to
increase/decrease and to what values.

Here's some info about my current parameters.

% sysctl vm.kmem_size_max
vm.kmem_size_max: 329853485875

% sysctl vm.kmem_size
vm.kmem_size: 8279539712

% sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 7205797888

% sysctl kern.maxvnodes
kern.maxvnodes: 206227

There's one script at the ZFSTuningGuide which calculates kernel memory
utilization, and for me these values are listed below:

TEXT=22402749, 21.3649 MB
DATA=4896264192, 4669.44 MB
TOTAL=4918666941, 4690.81 MB

While looking for ZFS tuning I've also stumbled upon this thread in the
FreeBSD Forums [2], where the OP describes a similar behaviour to what I am
already experiencing, so I'm quite worried now that the reason for these
crashes is ZFS.

Before jumping into any change to the kernel parameters (vm.kmem_size,
vm.kmem_max_size, kern.maxvnodes, vfs.zfs.arc_max) I'd like to hear any
feedback from people that have already done such optimizations on their ZFS
systems.

Could you please share what are the optimal values for these parameters on
a system with 8Gb of memory? Is there a way to calculate these values or is
it just a "test-and-see-which-fits-better" way of doing this?

Thanks and regards,
Marin

[1]: https://wiki.freebsd.org/ZFSTuningGuide
[2]: http://forums.freebsd.org/showthread.php?t=9143


On Sun, Jan 20, 2013 at 3:44 PM, Marin Atanasov Nikolov wrote:

>
>
>
> On Sat, Jan 19, 2013 at 10:19 PM, John  wrote:
>
>> >At 03:00am I can see that periodic(8) runs, but I don't see what could
>> have
>> >taken so much of the free memory. I'm also running this system on ZFS and
>> >have daily rotating ZFS snapshots created - currently the number of ZFS
>> >snapshots are > 1000, and not sure if that could be causing this. Here's
>> a
>> >list of the periodic(8) daily scripts that run at 03:00am time.
>> >
>> >% ls -1 /etc/periodic/daily
>> >800.scrub-zfs
>> >
>> >% ls -1 /usr/local/etc/periodic/daily
>> >402.zfSnap
>> >403.zfSnap_delete
>>
>> On a couple of my zfs machines, I've found running a scrub along with
>> other
>> high file system users to be a problem.  I therefore run scrub from cron
>> and
>> schedule it so it doesn't overlap with periodic.
>>
>> I also found on a machine with an i3 and 4G ram that overlapping scrubs
>> and
>> snapshot destroy would cause the machine to grind to the point of being
>> non-responsive. This was not a problem when the machine was new, but
>> became one
>> as the pool got larger (dedup is off and the pool is at 45% capacity).
>>
>> I use my own zfs management script and it prevents snapshot destroys from
>> overlapping scrubs, and with a lockfile it prevents a new destroy from
>> being
>> initiated when an old one is still running.
>>
>> zfSnap has its -S switch to prevent actions during a scrub which you
>> should
>> use if you haven't already.
>>
>>
> Hi John,
>
> Thanks for the hints. It was a long time since I've setup zfSnap and I've
> just checked the configuration and I am using the "-s -S" flags, so there
> should be no overlapping.
>
> Meanwhile I've updated to 9.1-RELEASE, but then I hit an issue when trying
> to reboot the system (which appears to be discussed a lot in a separate
> thread).
>
> Then I've updated to stable/9, so at the least the reboot issue is now
> solved. Since I've to stable/9 I'm monitoring the system's memory usage and
> so far it's been pretty stable, so I'll keep an eye of an update to
> stable/9 has actually fixed this strange issue.
>
> Thanks again,
> Marin
>
>
>> Since making these changes, a machine that would have to be rebooted
>> several
>> times a week has now been up 61 days.
>>
>> John Theus
>> TheUs Group
>>
>
>
>
> --
> Marin At

Re: svn - but smaller?

[Oliver Brandmueller]

Hi folks,

thank you for all the answers and fruitful discussion.

Special thanks goes to Chris Rees for coming up with the 
subversion-static ports quite fast, so now we're hoping for package 
building to kick in here - but that is a quick and very useful way after 
setting up a fresh machine (specifically if it's not within the bounds 
of your own infrastructure)!

Also I'd like to mention John Mehr, who's work on a "lightweight, 
dependency-free, BSD licensed program to pull source using the svn 
protocol" (couldn't say it better, so I use his words :-)). Hope this 
will make it into ports soon and in the long run even to base!


Thanx again,

Oliver

-- 
| Oliver Brandmueller  http://sysadm.in/ o...@sysadm.in |
|Ich bin das Internet. Sowahr ich Gott helfe. |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bge numbering

[Daniel Braniss]

Hi,
this server, a Dell R720 has 4 bge on board,
 Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
 bge0: APE FW version: NCSI v1.1.7.0
 bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
 miibus0:  on bge0
 ...

I have connected the ethernet to port labeled 0, but it appears
as bge2, how can this be corrected?

thanks,
danny


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

acpi resume related patch

[Andriy Gapon]

If you have ACPI suspend/resume working, if it used to work but stopped working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?

http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Derek Kulinski]

Hello Sergey,

Thursday, January 24, 2013, 10:09:58 PM, you wrote:

>> I think you don't understand the reason why people are asking for
>> this. I personally experienced the need not long ago. I had stable/9
>> branch and wanted to downgrade to 9.0. The entire process went well
>> until I rebooted the system, to see tons of errors in pretty much
>> everything that was compiled from ports. Instead recompiling them
>> from scratch I just decided to go ahead and upgrade to 9.1 which was
>> not officially released yet. 
> how in this case you would have helped availability lite-svn-client on
> base ? 

The base worked fine, the ports were completely broken. And even if it
was somehow broken (perhaps buildworld did not correctly built it)
if it was part of the base it would not depend on any external ports.

>> And of course I could not perform svn sw because svn was broken too.
> r232944 | lev | 2009-04-29 15:11:17 +0300 
> ...
> (3) Add STATIC option to build only static binaries [2]
> ...

While that would not apply to my case (switch within major version),
what about ABI incompatibilities?

>> And since svn has tons of dependencies it took me nearly an hour to
>> recompile them (portupgrade and Ruby were broken too). 
> that's why I don't use portupgrade for a long time;-)
> use portmaster WTF

Other than that it works very well, but I will give portmaster a try.


-- 
Best regards,
 Derekmailto:tak...@takeda.tk

Cole's Law: Thinly sliced cabbage.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"