Re: Install of 13.0-RELEASE i386 with ZFS root hangs up

[Freddie Cash]

On Fri, May 7, 2021 at 5:49 AM Yasuhiro Kimura  wrote:

> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>
> I tried this with VirtualBox and VMware Player on Windows with
> following VM condition.
>
> * 4 CPUs
> * 8GB memory
> * 100GB disk
> * Bridge mode NIC
>
> But in both cases, VM gets high CPU load and hangs up after I moved
> to 'YES' at 'ZFS Configuration' menu and type return key.
>
> If I select UFS root installation completes successfully. So the
> problem is specific to ZFS root.
>

Running ZFS on 32-bit OSes is doable (although not recommended) but
requires a lot of manual configuration and tweaking, especially around
kernel memory and ARC usage.

You're limited to 4 GB of memory space, so you need to tune the ARC to use
less than that.  The auto-tuning has improved a lot over the years, but you
still need to limit the ARC size to around 2 GB (or less) to keep the
system stable.  KVA memory space tuning shouldn't be needed anymore, but
you can do research into that, just in case.

You can compile a custom kernel to enable PAE support, that will sometimes
help with memory issues on i386 (and will allow you to use more than 4 GB
of system RAM, although individual processes are still limited to 4 GB).

If you really need to, you can make ZFS work on i386.  If at all possible,
though, you really should run it on amd64 instead.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

geli - is it better to partition then encrypt, or vice versa ?

[Freddie Cash]

On Sat., Apr. 17, 2021, 1:04 p.m. Clayton Milos,  wrote:

> I encrypt the whole disk and then add it to the pool. No need to partition
> it. If I remember correctly zfs prefers unpartitioned disks


>
ZFS on Solaris used to require the use of entire, raw disks as the cache
was disabled if the disk was partitioned, tanking performance

ZFS on FreeBSD has never had this issue, and has fully supported the use of
partitioned disks from the very first import of ZFS into 7-Stable.

No other OS that supports ZFS has this issue; it's strictly a Solaris (and
derivatives) issue.

Cheers,
Freddie

Typos due to smartphone keyboard.


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Deprecating base system ftpd?

[Freddie Cash]

On Sun., Apr. 4, 2021, 5:04 p.m. Rick Macklem,  wrote:

>
> I wonder what others find convenient when moving files to/from
> Windows?
>

SCP works beautifully for transferring files to/from Windows stations.
Haven't needed FTP support for about a decade now at $WORK and at home. SSH
has quickly become the ubiquitous replacement for FTP.

Windows 10 even comes with a native OpenSSH client these days (along with
the version that comes with WSL).

As for ftpd being in base, as a user of FreeBSD (not a developer) I'm ok
with it moving to ports or disappearing completely. So long as fetch(8)
supports FTP for connecting to remote FTP servers.


Cheers,
Freddie

Typos due to smartphone keyboard.

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

Re: freebsd-update not removing old libraries

[Freddie Cash]

On Tue., Mar. 16, 2021, 10:48 p.m. Lucas Nali de Magalhães, <
rollingb...@gmail.com> wrote:

> On Mar 16, 2021, at 3:57 PM, Freddie Cash  wrote:
>
> There seems to be a bug in freebsd-update on 11.x and 12.x systems where
> it's not removing old library files in the final "freebsd-update install"
> run.
>
> System 1:
> 10.2 upgrade to 11.2.  /lib/libreadline.so.8 is left behind, which breaks
> bash pkg.
>
> (…)
>
> No source tree is installed on any of the broken systems (1 and 3).  They
> are strictly binary upgrades/pkg installs.
>
>
> Do you tried an extra round of "freebsd-update install" ?
>

Yeah, many times. Just comes back with the "no updates to install, run
fetch first" message.

Cheers,
Freddie

Typos due to smartphone keyboard.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

freebsd-update not removing old libraries

[Freddie Cash]

There seems to be a bug in freebsd-update on 11.x and 12.x systems where
it's not removing old library files in the final "freebsd-update install"
run.

System 1:
10.2 upgrade to 11.2.  /lib/libreadline.so.8 is left behind, which breaks
bash pkg.
11.2 upgrade to 11.4. /lib/libreadline.so.8 is left behind, which breaks
bash pkg.
11.4 upgrade to 12.2. /lib/libreadline.so.8 is left behind, which breaks
bash pkg.

System 2:
11.2 upgrade to 12.2.  /lib/libreadline.so.8 doesn't exist, no issues with
any packages.  This one has the source tree installed as I needed it to
compile the openzfs port, and I manually ran "make delete-old" and "make
delete-old-libs" on this one.

System 3:
11.x upgrade to 12.2. /lib/libreadline.so.8 left behind, which breaks bash
pkg.

I don't remember which specific minor version of 11 was installed on system
3, but it was most likely 11.2.

No source tree is installed on any of the broken systems (1 and 3).  They
are strictly binary upgrades/pkg installs.

How would one go about running the equivalent of "make delete-old" and
"make delete-old-libs" on these systems, when "freebsd-update install"
after a "pkg upgrade -f" doesn't do anything?  I'd prefer to keep the
source tree off these, but if I have to install it temporarily to run
delete-old/delete-old-libs, then so be it.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Second pool not mounted automaticly on 13.0-RC2

[Freddie Cash]

On Sat., Mar. 13, 2021, 8:44 a.m. Johan Hendriks, 
wrote:

> On 13/03/2021 17:09, Johan Hendriks wrote:
> > Hello all, i just upgrade my test server from 12.1 to 13.0-RC2. This
> > is a baremetal server.
> > It has two ssd's on ada0 and ada1 using zfs. Also there is a 6 disk
> > pool named storage.
> >
> > After the update the storage pool is not imported any more. I have
> > updated the pool, thinking it was necessary, but the result is the
> > same, after a reboot the storage pool is not imported.
> >
> > root@test-server:~ # zpool list
> > NAMESIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAGCAP DEDUP
> > HEALTH  ALTROOT
> > zroot   107G  1.60G   105G- - 0% 1% 1.00x
> > ONLINE  -
> > root@test-server:~ # zpool import
> >pool: storage
> >  id: 17039452293665227158
> >   state: ONLINE
> >  action: The pool can be imported using its name or numeric identifier.
> >  config:
> >
> > storage ONLINE
> >   mirror-0  ONLINE
> > gpt/disk00  ONLINE
> > gpt/disk01  ONLINE
> >   mirror-1  ONLINE
> > gpt/disk02  ONLINE
> > gpt/disk03  ONLINE
> >   mirror-2  ONLINE
> > gpt/disk04  ONLINE
> > gpt/disk05  ONLINE
> > root@test-server:~ #
> >
> > After importing the pool all is fine but after a reboot it needs to be
> > imported again.
> >
> > Did something change?
> > I observed this earlier on a HEAD which was 13 at that time (around
> > januari) but did not have the time to look at it. That was a baremetal
> > server also.
> >
> For the completeness, i have the following related settings in
> /boot/loader.conf.
>
> # ZFS
> zfs_load="YES"
>
> And in my /etc/rc.conf the following.
> # ZFS
> zfs_enable="YES"
>

I have a 12.2 system where I installed the OpenZFS port and switched over
to using that for my pools (boot pool has not been upgraded, storage pool
is using draid).

Boot pool is imported at boot time as per normal.

Storage pool doesn't get imported until it login and do it manually.

Played around with cache file settings to no avail.

Have a system I've upgraded to 13.0-RC1 that we're testing different pool
arrangements for the storage pool. Haven't rebooted it yet with the second
pool created so not sure if it's going to be imported automatically or not.

Cheers,
Freddie

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

OpenZFS dRAID questions

[Freddie Cash]

[Not sure which list is more applicable for this question, so sending to
-fs and -stable.  If it should be only one or the other, let me know.]

Trying to get an understanding of how the dRAID vdev support works in ZFS,
and what a good setup would be for a storage server using multiple JBODs
full of SATA drives.

Right now, my storage pools are made up of 6-disk raidz2 vdevs.  So my
24-bay systems have 4x raidz2 vdevs, my 45-bay systems have 7x raidz2 vdevs
with 3 (cold) spares, and my 90-bay systems have 15x raidz2 vdevs (1 vdev
uses the 3 extra drives from each 45-drive JBOD).

If I'm reading the dRAID docs correctly, instead of having multiple raidz2
vdevs in the pool, I'd have a single draid vdev, configured with children
that are configured with similar data/parity devices to "mimic" raidz2?

If that's correct, would it make sense to have a single draid vdev per pool
(splitting the draid vdev across JBODs)?  Or a single draid vdev per JBOD
chassis (so 2x draid vdevs)?

What's the practical limit for the number of drives in a single draid vdev?

I have a brand new storage server sitting in a box with a 44-bay JBOD that
will be going into the server room next week, and I'm tempted to try draid
on it instead of the multiple-raidz2 setup.  This would use 4+2
(data+parity) children with 2 spares, I believe.

This server will be replacing a 90-bay system (2x JBODs), which will then
be used as another storage server once all the dying drives are replaced.
Will be interesting to see how draid works on that one as well, but not
sure how to configure it.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Wrong architecture: FreeBSD:12.0:amd64 instead of FreeBSD:12:amd64

[Freddie Cash]

On Mon, Mar 2, 2020 at 3:49 PM Antoine Michard 
wrote:

> Hi all,
>
> I just connect to my server this evening for pkg update task and I've got
> this:
> # pkg update
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100% 916 B 0.9kB/s 00:01
> Fetching packagesite.txz: 100% 6 MiB 6.5MB/s 00:01
> Processing entries: 63%
> pkg: wrong architecture: FreeBSD:12.0:amd64 instead of FreeBSD:12:amd64
> pkg: repository FreeBSD contains packages with wrong ABI:
> FreeBSD:12.0:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD
> Error updating repositories!
>

It's not your system.  There's an issue with the package building cluster
that's putting the wrong version number (12.0 instead of 12) into the
architecture string.

It's a known issue, they're working on it, we just need to be patient while
they fix it.  :)

(Although, all previous mentions of this were regarding 13.0; this is the
first time I've seen the issue with 12.0 come across the mailing lists.)

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Boot fails with USB 3.0 external harddrive plugged in

[Freddie Cash]

[fcash@rogue /home/fcash]$ freebsd-version -ku
12.0-RELEASE-p8
12.0-RELEASE-p8

This system was previously running FreeBSD 11.2 and didn't have any issues
booting with the external USB drive plugged into the USB 3.0 ports on the
motherboard.

Ever since upgrading to 12.0, and through all the updates to -p8, booting
with the external drive plugged in fails.  It will eventually get through
the loader, start to load the kernel, then drop to a black screen, and
(after a few minutes) power off the system completely.

The boot process is *extremely* slow with the USB drive plugged in.  As in,
you can watch the loader cursor twirl at about 1 frame every few seconds.

However, if I am sitting at the computer, I can press any key on the
keyboard (even shift, ctrl, alt, or spacebar), and it will make the cursor
spin at a normal speed for a second or two.  So, if I hit a key on the
keyboard every other second, it will go through a normal boot process.

I seem to recall there was a similar issue on the mailing list a couple
months back, but my google-fu is failing me.  :(  I thought there was a
loader.conf setting that resolved that issue, but I can't seem to find it.

If I unplug the external drive, it boots normally without any user
intervention.  Connecting the drive after the login prompt appears,
everything works normally. It's only the boot process that is an issue.

This is an olded system, using an AMD Phenom-II quad-core CPU, but has 16
GB of RAM, and 6 harddrives in a ZFS pool.  Has been working great, up
until the 12.0 upgrade.

I have plans to upgrade this system to 12.1 later this month.  Just
wondering if this is a known issue that's fixed in that release, or
something new.

xhci0:  mem 0xfe80-0xfe807fff irq
46 at device 0.0 on pci2
xhci0: 32 bytes context size, 32-bit DMA
xhci0: Unable to map MSI-X table
usbus0 on xhci0
xhci1:  mem 0xfe60-0xfe607fff irq
50 at device 0.0 on pci4
xhci1: 32 bytes context size, 32-bit DMA
xhci1: Unable to map MSI-X table
usbus1 on xhci1
ohci0:  mem 0xfe90a000-0xfe90afff irq
18 at device 18.0 on pci0
usbus2 on ohci0
ehci0:  mem 0xfe909000-0xfe9090ff
irq 17 at device 18.2 on pci0
usbus3 on ehci0
ohci1:  mem 0xfe908000-0xfe908fff irq
20 at device 19.0 on pci0
usbus4 on ohci1
ehci1:  mem 0xfe907000-0xfe9070ff
irq 21 at device 19.2 on pci0
usbus5 on ehci1
ohci2:  mem 0xfe906000-0xfe906fff irq
18 at device 20.5 on pci0
usbus6 on ohci2
ohci3:  mem 0xfe905000-0xfe905fff irq
22 at device 22.0 on pci0
usbus7 on ohci3
ehci2:  mem 0xfe904000-0xfe9040ff
irq 23 at device 22.2 on pci0
usbus8 on ehci2
da0 at umass-sim0 bus 0 scbus12 target 0 lun 0
da0:  Fixed Direct Access SPC-3 SCSI device
da0: Serial Number Z297HW2Q
da0: 400.000MB/s transfers
da0: 2861588MB (5860533168 512 byte sectors)
da0: quirks=0x2

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Freddie Cash]

On Tue, Nov 5, 2019 at 12:20 PM Chris Ross  wrote:

> On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote:
> > Chris Ross wrote on 11/05/2019 19:34:
> > > Hello.  I have a Cisco UCS C220-M5 with a RAID controller.  It calls
> itself
> > > "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5.
> > > Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014,
> which
> > > looks to be an LSI MegaRAID Tri-Mode SAS3516.  It looks like this
> should
> > > be supported by the mpr(4) driver, but it doesn't seem to recognize it
> > > at boot time.
> >
> > Do you have mpr_load="YES" in loader.conf?
> > Or for ISO booting you can manually load kernel modules at boot prompt.
>
> I dropped to boot prompt in ISO boot, and entered 'mpr_load="YES"'.
>
> I tried "load", but wasn't able to devine how to load the mpr module with
> that.  Is that needed, or should 'mpr_load="YES"' have accomplished the
> desired result?
>

modulename_load="YES" is the syntax used in the loader.conf file.
"load modulename" (without the quotes) is the syntax used at the loader
prompt.

So at the loader prompt, try the following:  load mpr
Or possibly:  load mpr.ko
Or, to get right finicky:  load /boot/kernel/mpr.ko

You should be able to use "ls" to see what .ko files are available, and in
which directory, in order to load them.


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: efi and serial console

[Freddie Cash]

On Fri, Jul 19, 2019, 12:59 PM mike tancsa,  wrote:

> I installed a RELENG12 snapshot from July 11th and having a hard time
> getting serial console to work. In the past, I would have something
> simple like
>
>
> ttyu0   "/usr/libexec/getty std.115200  vt100   on secure
>

Use 3wire.115200 instead and see if that works. We had to switch to that
with 11.0+ in order to get a working serial console on our Supermicro
motherboards (AMD Opteron and Epyc).

Cheers,
Freddie

Typos courtesy of my phone's keyboard.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: trying to expand a zvol-backed bhyve guest which is UFS

[Freddie Cash]

On Sun, May 19, 2019, 6:59 PM Paul Mather,  wrote:

> On May 19, 2019, at 9:46 PM, tech-lists  wrote:
>
> > Hi,
> >
> > context is 12-stable, zfs, bhyve
> >
> > I have a zvol-backed bhyve guest. Its zvol size was initially 512GB
> > It needed to be expanded to 4TB. That worked fine.
> >
> > The problem is the freebsd guest is UFS and I can't seem to make it see
> > the new size. But zfs list -o size on the host shows that as far as zfs
> is
> > concerned, it's 4TB
> >
> > On the guest, I've tried running growfs / but it says requested size is
> > the same as the size it already is (508GB)
> >
> > gpart show on the guest has the following
> >
> > # gpart show
> > =>63  4294967232  vtbd0  MBR  (4.0T)
> >  63   1 - free -  (512B)
> >  64  4294967216  1  freebsd  [active]  (2.0T)
> > 4294967280  15 - free -  (7.5K)
> >
> > => 0  4294967216  vtbd0s1  BSD  (2.0T)
> >   0  10653532161  freebsd-ufs (508G)
> >  1065353216 83885442  freebsd-swap  (4.0G)
> >  1073741760  3221225456   - free -  (1.5T)
> >
> > I'm not understanding the double output, or why growfs hasn't worked on
> > the guest ufs. Can anyone help please?
>
>
> Given the above, the freebsd-ufs partition can't grow because there is a
> freebsd-swap partition between it and the free space you've added at the
> end of the volume.
>
> You'd need to delete the swap partition (or otherwise move it to the end
> of
> the partition on the volume) before you could successfully growfs the
> freebsd-ufs partition.
>

Even if you do all that, you won't be able to use more than 2 TB anyway, as
that's all MBR supports.

If you need more than 2 TB, you'll need to backup, repartition with GPT,
and restore from backups.


Cheers,
Freddie

Typos due to smartphone keyboard.

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

Re: ZFS...

[Freddie Cash]

On Wed, May 8, 2019 at 9:31 AM Karl Denninger  wrote:

> I have a system here with about the same amount of net storage on it as
> you did.  It runs scrubs regularly; none of them take more than 8 hours
> on *any* of the pools.  The SSD-based pool is of course *much* faster
> but even the many-way RaidZ2 on spinning rust is an ~8 hour deal; it
> kicks off automatically at 2:00 AM when the time comes but is complete
> before noon.  I run them on 14 day intervals.
>

Damn, I wish our scrubs took 8 hours.  :)

Storage pool 1:  90 drives in 6-disk raidz2 vdevs (mix of 2 TB and 4 TB
SATA).  45 hours to scrub.

Storage pool 2:  90 drives in 6-disk raidz2 vdevs (mix of 2 TB and 4 TB
SATA).  33 hours to scrub.

Storage pool 3:  24 drives in 6-disk raidz2 vdevs (mix of 2 TB and 4 TB
SATA).  134 hours to scrub.

Storage pool 4:  24 drives in 6-disk raidz2 vdevs (mix of 1 TB, 2 TB, 4 TB
SATA).  Dedupe enabled.  256 hours to scrub.

Storage pool 5:  90 drives in 6-disk raidz2 vdevs (mix of 2 TB and 4 TB
SATA).  Dedupe enabled.  Takes about 6 weeks to resilver a drive, and it's
constantly resilvering drives these days as it's the oldest pool, and all
the drives are dying.

:D

Pools 1, 3, and 4 are in DC1.  Pools 2 and 5 are in DC2 across town.

Pool 1 sends snapshots to pool 2.  Pools 3 and 4 send snapshots to pool 5.

These pools are highly fragmented.  :)


> If you have pool(s) that are taking *two weeks* to run a scrub IMHO
> either something is badly wrong or you need to rethink organization of
> the pool structure -- that is, IMHO you likely either have a severe
> performance problem with one or more members or an architectural problem
> you *really* need to determine and fix.  If a scrub takes two weeks
> *then a resilver could conceivably take that long as well* and that's
> *extremely* bad as the window for getting screwed is at its worst when a
> resilver is being run.
>

Thankfully, ours are strictly storage for backups of other systems, so as
long as the nightly backups complete successfully before 6 am, we're not
worried about performance.  :)  And we do have plans to replace pools 2 and
5 to remove dedupe from the equation.  There's not a lot we can do about
the fragmentation issue, as these servers all run rsync backups from
200-odd other servers, and remove the oldest snapshot every night.

So, while a 2-week scrub may be horrible, it all depends on the use-case.
If these were direct storage systems for in-production servers, then I'd be
worried.  But as redundant backup systems (3 copies of everything, in 3
separate locations around the city), I'm not too worried.  Yet.  :D

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Binary update to -STABLE? And if so, what do I get?

[Freddie Cash]

On Thu, Feb 14, 2019 at 10:13 AM Kevin Oberman  wrote:

> On Thu, Feb 14, 2019 at 3:10 AM Pete French 
> wrote:
> > On 14/02/2019 01:43, Jason Tubnor wrote:
> > > I also have hit this IPv6 issue (I thought I was going crazy until I
> > worked
> > > it out) and other iflib issues in 12.0, which have been fixed in
> -STABLE
> > > that really should be patched in 12.0 or bring forward an early 12.1
> > > release. For our use case, 12.0 is just too buggy for production at
> this
> > > rate and we won't touch it, which is a shame because there is a lot of
> > good
> > > work in there that we would like to use but it is trumped by the
> > breakages.
> >
> > Any reason behind not running STBLE out of interest ? Yes, 12 has been
> > buggy with regards to networking, but these things get fixed very fast
> > and I now have all my machines on the lattest STABLE in production, as
> > of yesterday.
> >
> > -pete.
> >
>
> Generally, not many.
>
> Far and away the biggest is the requirement to build from sources. It's not
> a big deal for me, but if I still had many systems to deal with, that would
> be a pain.
>

Just as one can setup a poudriere/synth system for building custom binary
package repositories (so one builds packages on one system for easy
installation on multiple systems using binary packages), one can also setup
a custom freebsd-update server (so one builds the OS on one system, for
easy installation on multiple servers using binary updates).  And that can
be done to track -STABLE or -CURRENT, I believe.

Granted, I have never done it, nor looked too deeply into the documentation
around it, but I do know it's possible. :)  At least in theory.  :D

IOW, the days of needing to compile everything on each individual machine
are behind us.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs boot size

[Freddie Cash]

On Thu, Aug 16, 2018, 4:22 PM Steven Hartland, 
wrote:

> The recommended size for a boot partition has been 512K for a while.
>
> We always put swap directly after it so if a resize is needed its easy
> without and resilvering .
>
> If your pool is made up of partitions which are only 34 block smaller
> than your zfs partition you're likely going to need to dump and restore
> the entire pool as it won't accept vdevs smaller than the original.
>

Adding "-a 1M" to your gpart command when partitioning disks, regardless of
their use, is very handy for this. It starts the first partition at 1MB,
which gives you enough slack to increase the size of the freebsd-boot
partition as needed. :)

You can even add a freebsd-boot partition to make a data pool bootable as
root with that amount of slack. :D Went through that at home.

And ZFS has reserved a few MB from the end of the device you give it to
allow for replacement drives that aren't the exact same size (in sectors or
bytes) for awhile now (maybe since the 9.x days?).

Cheers,
Freddie

Typos courtesy of my phone's keyboard.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Booting off ZFS pool with failed ZIL/cache device

[Freddie Cash]

On Sun, Jul 29, 2018, 3:46 AM Stefan Bethke,  wrote:

> Folks,
>
> my ZIL/cache SSD apparently just died. Rebooting the system with the SATA
> M.2 SSD hung, so I removed the card from the system.
>
> On powerup, loader acts normally, all four SATA disks (main Raid-Z1
> devices) are all probed successfully, but mount root fails:
>
> ZFS filesystem version: 5
> ZFS storage pool version: features support (5000)
> Timecounters tick every 1.000 msec
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0:  ATA8-ACS SATA 3.x device
> ada0: Serial Number Z5Q7K0RIFFRC
> ada0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 4769307MB (9767541168 512 byte sectors)
> ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
> ada1:  ATA8-ACS SATA 3.x device
> ada1: Serial Number Y5PIK0A2FFRC
> ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada1: Command Queueing enabled
> ada1: 4769307MB (9767541168 512 byte sectors)
> ada2 at ahcich3 bus 0 scbus3 target 0 lun 0
> ada2:  ATA8-ACS SATA 3.x device
> ada2: Serial Number 36D2K0VZFFRC
> ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada2: Command Queueing enabled
> ada2: 4769307MB (9767541168 512 byte sectors)
> ada3 at ahcich4 bus 0 scbus4 target 0 lun 0
> ada3:  ATA8-ACS SATA 3.x device
> ada3: Serial Number Z5SDK0J3FFRC
> ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
> ada3: Command Queueing enabled
> ada3: 4769307MB (9767541168 512 byte sectors)
> pass4 at ahciem0 bus 0 scbus6 target 0 lun 0
> pass4:  SEMB S-E-S 2.00 device
> Trying to mount root from zfs:p2/be/11 []...
> GEOM_MIRROR: Device mirror/p2swap launched (4/4).
> random: unblocking device.
> Mounting from zfs:p2/be/11 failed with error 6; retrying for 3 more seconds
> Mounting from zfs:p2/be/11 failed with error 6.
>
> Loader variables:
>  vfs.root.mountfrom=zfs:p2/be/11
>
> Manual root filesystem specification:
>  : [options]
>  Mount  using filesystem 
>  and with the specified (optional) option list.
>
>eg. ufs:/dev/da0s1a
>zfs:tank
>cd9660:/dev/cd0 ro
>  (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>
>  ?   List valid disk boot devices
>  .   Yield 1 second (for background tasks)
>  Abort manual input
>
> mountroot>
>
> Is there an easy way to boot into single user mode and remove the
> ZIL/cache devices that are not there anymore? Or do I need a USB key to
> boot off of and zfs import the pool first?
>
>
> Thanks,
> Stefan
>

Boot off USB or CD, then try to manually import the pool.

There's an option to "zpool import" to ignore missing log devices. Once
it's imported, you can remove/detach the missing device. Then you should be
able to boot again.

Cheers,
Freddie

Typos courtesy of my phone's keyboard.

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

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Freddie Cash]

On Tue, Jun 26, 2018, 5:33 AM Pete French, 
wrote:

>
> > Also, please show the 100 first lines of the verbose boot dmesg on this
> > machine.
>
> the dmesg wraps around if I boot verbosely, but heres the contnets of
> /var/log/messages from the time it starts to where it stops
> talking about CPU specific stuff... if you need something else then
> let me know - this is an easy machine to reboot and play about with.
>

/var/run/dmesg.boot is there for this various reason (dmesg buffer rolling
over). :) It's the dmesg output for the current boot.

Cheers,
Freddie

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

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Freddie Cash]

On Tue, Apr 17, 2018 at 8:49 AM, Kevin Oberman <rkober...@gmail.com> wrote:

> On Mon, Apr 16, 2018 at 11:56 PM, Eivind Nicolay Evensen <
> eivi...@terraplane.org> wrote:
>
> > On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell wrote:
> > > On 04/04/18 06:39, Alban Hertroys wrote:
> > > > [...]
> > > > That said, SCHED_ULE (the default scheduler for quite a while now)
> was
> > designed with multi-CPU configurations in mind and there are claims that
> > SCHED_4BSD works better for single-CPU configurations. You may give that
> a
> > try, if you're not already on SCHED_4BSD.
> > > > [...]
> > >
> > > A small, disgruntled community of FreeBSD users who have never seen
> > > proof that SCHED_ULE is better than SCHED_4BSD in any environment
> > > continue to regularly recompile with SCHED_4BSD.  I dread the day when
> > > that becomes impossible, but at least it isn't here yet.  -- George
> >
> > Indeed 4bsd is better in my case aswell. While for some unknown to me
> > reason ule performed a bit better in the 10.x series than before, in 11.x
> > it again is in my case not usable.
> >
> > Mouse freezes for around half a second with even frequency by just moving
> > it around in x11. Using 4bsd instead makes the problem go away.
> > I'm actually very happy that ule became worse again because going
> > back to 4bsd yet again also gave improved performance from other
> > dreadfully slow but (to me) still useful programs, like darktable.
> >
> > With 4bsd, when adjusting shadows and highlights it is possible to see
> > what I do when moving sliders. With ule it has never been better than
> waiting
> > 10-20-30 seconds to see where it was able to read a slider position
> > and update display, when working on images around 10500x10500 greyscale.
> >
> > It's not single cpu/single core either:
> > CPU: AMD FX(tm)-6300 Six-Core Processor  (3817.45-MHz
> K8-class
> > CPU)
>
> My experience has long been that 4BSD works far better for interactive, X
> based systems than ULE. Even on 10 I saw long, annoying pauses with ULE and
> I don't se those with 4BSD. I'd really like to see it better known that
> this is often the case. BTW, my system is 2 core/4 thread Sandybridge.
> ​
>

​The following has been suggested multiple times over the years on various
mailing lists as the "solution" to making ULE work well for interactive
tasks like running X-based desktops (in /etc/sysctl.conf):​

# Tune for desktop usage
kern.sched.preempt_thresh=224

​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
(3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Stability of 11.1S

[Freddie Cash]

On Wed, Mar 21, 2018 at 7:59 AM, Warner Losh <i...@bsdimp.com> wrote:

> On Wed, Mar 21, 2018 at 7:32 AM, George Mitchell <george+free...@m5p.com>
> wrote:
>
> > On 03/21/18 04:51, Eitan Adler wrote:
> > > On 19 March 2018 at 22:59, Dewayne Geraghty
> > > <dewayne.gerag...@heuristicsystems.com.au> wrote:
> > >> [...]
> > >> PS Normally I would bisect, but we're converting 2 large PROLOG
> > applications
> > >> to erlang... (prayers welcome)
> > > [...]
> >
> > What next, converting a FORTH application to LISP?  (Sorry, couldn't
> > resist ...)
>
>
> Back in college we had a gentleman who was working on his FORTH LISP
> interpreter But I can't recall if it was a FORTH interpreter written in
> LISP or a LISP interpreter written in FORTH.
>

​What happened to his first three LISP interpreters?  ;)  If at first you
don't succeed, try try try try again?

Sorry, that one was just too easy, could not resist.​ :D
​
I'll see myself out now.  :)​



-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs problems after rebuilding system

[Freddie Cash]

You said it's an external USB drive, correct? Could it be a race condition
during the boot process where the USB mass storage driver hasn't detected
the drive yet when /etc/rc.d/zfs is run?

As a test, add a "sleep 30" in that script before the "zfs mount -a" call
and reboot.

Cheers,
Freddie

Typos courtesy of my phone.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: recent 11.1-stable oddness

[Freddie Cash]

On Fri, Mar 2, 2018 at 10:15 AM, tech-lists <tech-li...@zyxst.net> wrote:

> Hello stable@
>
> Over the last few weeks, I've noticed the following new behaviours from
> 11.1 stable [only took note of the revision from the last update which
> was r330243 unfortunately as I thought it was my config/fault initially]:
>
> shutdown -r now no longer works as it did (ie: shutdown and reboot).
> What happens now is that it gets to:
>
> "syncing disks, vnodes remaining...5 5 5 4 0 0 0 done
> All buffers synced
> Swap device [file] removed. <<<<<-- there is no swapfile installed!
> Uptime: (whatever the uptime was)
> ukbd0: detached
> ums0: detached
> uhid0: detached
> uhub6: detached
> ukbd1: detached
> uhub3: detached
> umass0: detached
> uhub0: detached
>
> ...and there it sits until a hard reset via the power button is applied.
>

​If you set hw.usb.no_shutdown_wait to 1 via sysctl, does it
shutdown/reboot normally?


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ancient FreeBSD update path

[Freddie Cash]

On Fri, Jan 19, 2018 at 4:28 AM, Andrea Brancatelli <
abrancate...@schema31.it> wrote:

> Hello guys.
>
> I have a couple of ancient FreeBSD install that I have to bring into
> this century (read either 10.4 or 11.1) :-)
>
> I'm talking about a FreeBSD 8.0-RELEASE-p4 and a couple of FreeBSD
> 9.3-RELEASE-p53.
>
> What upgrade strategy would you suggest?
>
> Direct jump into the future (8 -> 11)? Progressive steps (8 -> 9 -> 10
> -> 11)? Boiling water on the HDs? :-)
>

​I like to do it in steps.  It takes longer, but the results tend to be
better.

8.0 --> last 8.x release --> 9.0 --> last 9.x release --> 10.0 --> last
10.x release --> 11.0 --> last 11.x release

Backup /usr/local/etc and any other configuration files that are strewn
about.  Then format/delete /usr/ports/* and /usr/local/* and install the
ports/packages you need.

Of course, for something that ancient, it would probably be faster/better
to just backup the config files, format the drives, and install 11.1 from
scratch.  :)


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: console-only freebsd

[Freddie Cash]

On Oct 7, 2017 7:21 AM, "tech-lists"  wrote:

Hi,

I have a freebsd 11-stable installation on a (gutless) netbook. What I'd
like is full functionality via the console[1]. One of the things it needs
is some graphics capability but without xorg. So I'm thinking, svga or
libSDL. For example, let's say to view a jpg file. If this is possible from
the console, what program or port would one use to view a gif or jpg file?

[1] by console, I mean the consoles accessed via alt-f1 to alt-f7 [2]
[2] can the number of consoles be increased?


Tmux or screen will give you an unlimited number of virtual terminals using
only a single TTY. And give you the ability to split the console into
multiple windows.

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

Re: a strange and terrible saga of the cursed iSCSI ZFS SAN

[Freddie Cash]

On Aug 5, 2017 10:09 AM, "Eugene M. Zheganin"  wrote:


And I want to also ask - what happens when the system's memory isn't enough
for deduplication - does it crash, or does the problem of mounting the pool
appear, like some articles mention ?


Can't really help with the other issues, but can speak to this one.

"Insufficient" RAM for dedupe won't be an issue during normal operation,
reading and writing to the pool. Performance will slow down over time as
the DDT increases in size taking up ARC/L2ARC space, possibly even spilling
over into raw disk reads.

Where the issues crop up is during snapshot deletion and filesystem
destruction. Those operations can run the system out of usable kmem and
lock things up. (Deletions cause a lot of churn in the DDT.) On reboot, the
pool import process will continue the deletion process, which will run the
system out of kmen locking it up. Rinse and repeat for a week until the
deletion process completes. L2ARC helps, but not nearly as much as adding
more RAM!

Device replacement will also be an issue as the resilver process will be
extremely slow (at least, it is for us with a very full, very fragmented
pool; equally full pools without d we dedupe resilver very quickly). And
don't try to replace two drives in separate vdevs unless you want to
increase the resilver time by a huge factor.

This is from experience with a 24-drive system with only 48 GB of RAM, and
a 90-disk system with 128 GB of RAM. Both with dedupe enabled. Both running
at about 90% full, very fragmented as they create and delete snapshots of
all filesystems on a daily basis. They've been running file about 5 years
now, possibly longer.

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

Re: Opteron 6100-series "Magny-Cours"

[Freddie Cash]

On Mar 25, 2017 11:03 AM, "Andriy Gapon"  wrote:


Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with
FreeBSD?


I'll need to double check when I get home. We have lots of Opterons in use
at work, from 100 through 6320. I think there's a couple of 6100s in there.

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

Re: Freebsd 11 - /usr/bin missing [xl]zgrep/zegrep/zfgrep

[Freddie Cash]

On Wed, Mar 22, 2017 at 5:41 AM, Jamie Landeg-Jones <ja...@dyslexicfish.net>
wrote:

> Kyle Evans <kevan...@ksu.edu> wrote:
>
> > Ah, I see what you mean. I've no idea on the history here, but I
> > believe the idea is that if I invoke one of these other links (zgrep,
> > egrep, ...) I'm expecting it to be actually be grep(1) based purely on
> > the name, and I don't consider bsdgrep(1) to be installed for anything
> > but a courtesy.
> >
> > For grep(1) to be GNU grep while xzgrep to secretly be a link to BSD
> > grep would be quite surprising to me as a user/admin, especially since
> > there are very real output and argument differences between the two.
> > This argument can be furthered by imagining the awkwardness that would
> > come from a system where the fairly standard *grep links are a mix
> > between BSD grep and GNU grep.
>
> Ahhh. Yes, that does make good sense, now you mention it.
>
> Maybe they should be installed as bsdxzgrep ... :-)
>
> The thing is, though, it *did* used to do this, and now it doesn't,
> which isn't very POLA, and the revision log makes no mention of it
> (it's an update to do with META mode) and I can't find any information
> about it. I'd have least expected /usr/src/UPDATING to mention when
> 6 utilities are effectively removed from /usr/bin!
>
> Hence why I was wondering if this change was actually intentional - at
> least now I know a good reason to do this (what you mentioned above) so
> cheers for that, and the fast responses..
>
> Your first response came in so quickly, I first thought it was a bounce
> message!
>
> Cheers, Jamie
>
> P.S. Nice to see someone on this list still remembers mail quoting
> etiquette ;-)
>

​Huh, never even noticed (not that I use many of the grep variants).  But,
on a 10.3 install (from binaries, not source), half the variants are
hard-links to bsdgrep, while the other half are hard-links to grep:

​[fcash@romulus  ~]$ ls -li /usr/bin/*grep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/bsdgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/bzegrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/bzfgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/bzgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/egrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/fgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/grep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/lzegrep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/lzfgrep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/lzgrep
5704673 lrwxr-xr-x  1 root  wheel 10 Mar 24  2016 /usr/bin/pgrep ->
/bin/pgrep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/xzegrep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/xzfgrep
5704478 -r-xr-xr-x  7 root  wheel  49224 Mar 24  2016 /usr/bin/xzgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/zegrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/zfgrep
5704508 -r-xr-xr-x  9 root  wheel  93400 Mar 24  2016 /usr/bin/zgrep

​Does this mean an upgrade via freebsd-update to 11.x would remove all the
lz* and xz* hard-links from my system?​  Not that I would notice, just
curious.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CARP forcing failover

[Freddie Cash]

Doesn't "ifconfig vhid XX state master" do what you want? It forces that
vhid over to master, which should preempt the other interfaces to switch as
well.

One command.

On Feb 28, 2017 5:10 PM, "Aristedes Maniatis" <a...@ish.com.au> wrote:

> Yes, the automatic failover is great and works perfectly to bring all
> interfaces over at once. But to manually force a failover I need to change
> the advskew one interface at a time with ifconfig.
>
> Ari
>
>
> On 1/3/17 12:04pm, Freddie Cash wrote:
> > Do you have the preemption sysctl enabled? That will fail-over all carp
> interfaces when any one fails.
> >
> > "sysctl -a | grep carp"
> >
> > I'm pretty sure there's also an ifconfig command to force the state as
> either master or backup. Check the man page.
> >
> >
> > On Feb 28, 2017 5:01 PM, "Aristedes Maniatis" <a...@ish.com.au  a...@ish.com.au>> wrote:
> >
> > I have a pair network gateway boxes running FreeBSD 11 and pf.
> Upstream runs VRRP to provide redundant links, one to each gateway.
> Internally I'm using CARP for failover.
> >
> > All works well, but I find that manually failing over the link is a
> bit complicated. In short I have this:
> >
> > em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
> > media: Ethernet autoselect (100baseTX )
> > status: active
> > carp: BACKUP vhid 1 advbase 1 advskew 50
> > igb0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
> > media: Ethernet autoselect (1000baseT )
> > status: active
> > carp: BACKUP vhid 2 advbase 1 advskew 50
> > igb0.2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
> > status: active
> > vlan: 2 vlanpcp: 0 parent interface: igb0
> > carp: BACKUP vhid 3 advbase 1 advskew 50
> > groups: vlan
> >
> > That's two internal vlans and one external network. Each interface
> has its own vhid since that's the advice I had in the past.
> >
> > Now, what command can I type that I could run remotely (SSH over the
> em0 link) to force all the CARP addresses simultaneously to decrease the
> advskew and become MASTER. Alternatively I could run something on the
> MASTER to make it BACKUP. Everything I've done so far is one command per
> interface which has got me in trouble before as I manage to accidentally
> remove my own access to the box before I'm done.
> >
> > Cheers
> > Ari
> >
> > please cc me.
> >
> > --
> > -->
> > Aristedes Maniatis
> > CEO, ish
> > https://www.ish.com.au
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> >
>
> --
> -->
> Aristedes Maniatis
> CEO, ish
> https://www.ish.com.au
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CARP forcing failover

[Freddie Cash]

Do you have the preemption sysctl enabled? That will fail-over all carp
interfaces when any one fails.

"sysctl -a | grep carp"

I'm pretty sure there's also an ifconfig command to force the state as
either master or backup. Check the man page.


On Feb 28, 2017 5:01 PM, "Aristedes Maniatis"  wrote:

> I have a pair network gateway boxes running FreeBSD 11 and pf. Upstream
> runs VRRP to provide redundant links, one to each gateway. Internally I'm
> using CARP for failover.
>
> All works well, but I find that manually failing over the link is a bit
> complicated. In short I have this:
>
> em0: flags=8943 metric 0
> mtu 1500
> media: Ethernet autoselect (100baseTX )
> status: active
> carp: BACKUP vhid 1 advbase 1 advskew 50
> igb0: flags=8943 metric 0
> mtu 1500
> media: Ethernet autoselect (1000baseT )
> status: active
> carp: BACKUP vhid 2 advbase 1 advskew 50
> igb0.2: flags=8943 metric
> 0 mtu 1500
> status: active
> vlan: 2 vlanpcp: 0 parent interface: igb0
> carp: BACKUP vhid 3 advbase 1 advskew 50
> groups: vlan
>
> That's two internal vlans and one external network. Each interface has its
> own vhid since that's the advice I had in the past.
>
> Now, what command can I type that I could run remotely (SSH over the em0
> link) to force all the CARP addresses simultaneously to decrease the
> advskew and become MASTER. Alternatively I could run something on the
> MASTER to make it BACKUP. Everything I've done so far is one command per
> interface which has got me in trouble before as I manage to accidentally
> remove my own access to the box before I'm done.
>
> Cheers
> Ari
>
> please cc me.
>
> --
> -->
> Aristedes Maniatis
> CEO, ish
> https://www.ish.com.au
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Boot partition size

[Freddie Cash]

On Jan 29, 2017 6:13 AM, "Gary Palmer"  wrote:

On Sun, Jan 29, 2017 at 03:15:19PM +1100, Aristedes Maniatis wrote:
> As recently as last October, the best official advice was to make a 64kB
boot partition.
>
> https://wiki.freebsd.org/action/diff/RootOnZFS/
GPTZFSBoot/Mirror?action=diff=16=17
>
>
> Now that turns out to be absolutely terrible advice and some people (like
me) have dozens of machines that will never be upgradable to FreeBSD 11 or
higher. It looks like there is no reasonable method of upgrade that doesn't
involve replacing every hard disk on every machine (that's hundred of
disks) with larger models. I use a zvol for swap, so I can't make swap
smaller to solve the problem.
>
> I started with FreeBSD 4.1 and in 16 years... sigh...
>
> The ashift pain some years ago was also caused by FreeBSD default
recommendations and settings not anticipating future needs quickly enough.
But this mess now is completely self-inflicted foot shooting.
>
>
> 1. Why is the recommendation now 128kB and not much much higher? When
that limit is broken in a couple of years, will there be another round of
annoyed users? Is someone concerned that ZFS users are running hard disks
over under 500Mb and need to save space? Surely the recommendation should
be 512kB?
>
> 2. Is there any possible short term future where ZFS volumes can be
shrunk, or will I be replacing every hard disk (or rebuilding the machine
from scratch)?


It is highly unlikely that ZFS volumes will be able to be reduced in size
even in the long term.  I believe that requires a piece of work that has
been rated as very difficult to do without violating layering policies
inside the ZFS code.

The alternative is, assuming you have a pool with redundancy (e.g. mirror)
is to do a backup, drop one half of the mirror, create a new pool on the
now unused disk, zfs send | zfs receive, boot from the new pool and then
drop the old pool and add the disk to the mirror


You can also format a larger drive with the correct partition sizes, and do
a "zpool replace" (for raidz vdevs) or "zpool detach/attach" (for mirror
vdevs). No send/recv required.

And, you may be able to do that on the existing disks, as ZFS now leaves a
MB or two of "slack space" at the end of the device used in the vdev. This
allows for using drives/partitions that are the same size in MB but have
different numbers of sectors. This was an issue on the early ZFS days.

So, you may be able to resize the freebsd-zfs partition by a handful of KB
without actually changing the size of the vdev.

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

Re: HAST, zfs and local mirroring

[Freddie Cash]

On Fri, Jun 3, 2016 at 1:40 AM, Eugene M. Zheganin <e...@norma.perm.ru>
wrote:

> Hi.
>
> On 02.06.16 19:50, Slawa Olhovchenkov wrote:
> > I am suggesting next setup:
> >
> > node0:
> >   own pool zroot0: mirror-0: local_disk0
> >remote-iscsi_disk1/1
> >   local_disk1: exported by iscsi as remote-iscsi_disk0/1 to node1
> >
> > node1:
> >   own pool zroot1: mirror-0: local_disk0
> >remote-iscsi_disk0/1
> >   local_disk1: exported by iscsi as remote-iscsi_disk1/1 to node0
> >
> >
> > No HAST.
> > Disks synced by ZFS over iSCSI.
> But this way I will get two independent zfs pools (or I still didn't get
> it), one half of each will be stored on another machine. And I need
> something different - a continuously replicated disk resource, that
> would be available on both machines in case either will crash. Cluster
> filesystem would be fine, but as far as I know there's no such thing on
> FreeBSD, so I accept it will be unavailable on slave while mounted as
> read-write on the master. HAST looks like a thing thats fits my
> requirement, only that I wank it to be redundant inside each host too,
> and all the documentation shows examples without local redundancy.
>

​Which is exactly the setup that I showed you.

Host1:  diskA  diskB

Host2:  diskC  diskD

You create two HAST resources:
  hast1:  using diskA and diskC
  hast2:  using diskB and diskD

Then create a ZFS pool using hast1 and hast2 as a mirror vdev.

That way, if you lose diskA, then diskC takes over, and ZFS never even
notices.

If you lose both diskA and diskC, you still have half the ZFS mirror vdev
running, so the pool is intact.

If you lose all of Host1, Host2 takes over, imports the pool, and carries
on.

HAST + CARP (to manage the fail-over and pool export/import) + ZFS gives
you everything (well, mostly) that you want.  There will be a smidgeon of
downtime during the host-to-host fail-over that may or may not be workable
in your setup.

The other option is to investigate the Ceph clustered filesystem.  I
believe there's been work ongoing this year to get it working on top of ZFS
on FreeBSD.

There's also GlusterFS, which has seen a bunch of work to get it working on
top of ZFS on FreeBSD.

No idea how well those last two work.


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: HAST, zfs and local mirroring

[Freddie Cash]

On Tue, May 31, 2016 at 11:18 AM, Eugene M. Zheganin <e...@norma.perm.ru>
wrote:

> I wat to start using HAST, I have two nodes and a pair of disk on each
> node. So I want to use HASt in an environment where each HAST resource
> would be mirrored. What is the preferred approach if I want to use ZFS on
> an end-device to avoid exsessive fscking, and, in the same time, I want to
> have some redundancy on a block level ? I see two possibility: HAST on a
> zvol of a mirrored pool, and a ZFS on a hast. But recently I heard that
> nested zfs (like zfs on zvol) is clamed unsupported. Futhermore, I have zfs
> on a geli on a zvol, and this solution proved itself to be very affected to
> livelocking - when disk i/o on a such fs is above some treshold, system is
> locking, and the only way out is to reset it. Should I chose geom_mirror to
> provide a device for HAST and the build ZFS on it ?
>

​The generally recommend way to do this is to create a HAST resource out of
1 disk from each system, and then build the ZFS pool using the HAST
resources as the "disks".

That way, your ZFS pool is made up of 2 HAST devices in a mirror vdev.

And each of the two HAST devices uses one disk from each server (total of
four disks).
​


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why must X open TCP by default?

[Freddie Cash]

On Wed, Mar 2, 2016 at 12:40 PM, Chris H <bsd-li...@bsdforge.com> wrote:

> Hello,
>  This is regarding 9-STABLE. All of the 9-STABLE boxes
> that have Xorg installed, and running on them, insist on
> opening TCP port 6000; as reported by sockstat(1)
>
> Xorg   1295  1  tcp6   *:6000*:*
> Xorg   1295  3  tcp4   *:6000*:*
>
> I see that the (current(ish)) documentation indicates
> that this option is off, by default, and can be enabled
> by passing -listen_tcp to startx(1). This seems to hold
> true, as all of my -CURRENT boxes do not show port 6000
> as being open while X is running. So my question is;
> how can I prevent X from opening tcp ports?
> I attempted;
> startx -nolisten tcp
>

​Does the following work (note the extra -- in the command)?​

​startx -- -nolisten tcp​



-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Periodic jobs triggering panics in 10.1 and 10.2

[Freddie Cash]

On Dec 9, 2015 7:24 PM, "Karl Denninger"  wrote:
>
> On 12/9/2015 17:29, Michael B. Eichorn wrote:
> > I sorry, but I really don't get your point, PCBSD has shown a great
> > reason why zfs on root and on laptops/desktops is a good idea... boot
> > environments. They have pretty much figured out how to use snapshots
> > to go from A-B ping-pong installations to A-B-C-D-E installations.
> > I am even aware of people using it to run Release and Current on the
> > same machine. Unfortunately at the moment the system requires GRUB,
> > but there is ongoing work to add the ability to the FreeBSD
> > bootloader. Further IIRC zfs send-receive has a history involving a
> > developer who wanted a better rsync for transfering his work to a
> > laptop. In addition we have pretty much Moore's Lawed our way to the
> > point where a new laptop today can out spec a typical server from when
> > ZFS was first implemented. Hiding features because you 'can' shoot
> > your foot off is hardly a typical UNIXy way of thinking anyway.
>
> Boot environments work fine on FreeBSD.  Look at "beadm" :-)
>
> What are you trying to do that you need GRUB?

GRUB supports listing and selecting boot environments as part of the boot
process.

FreeBSD 8.x and 9.x boot loaders don't support listing or selecting BEs.
Neither does 10.0; not sure about 10.1.

Devin Teske and company did a lot of work on this area, and I believe 10.2,
certainly -CURRENT, supports this.

Because of BEs, PC-BSD flip-flopped between the FreeBSD loader and GRUB in
the 9.x and 10.x releases. I think they support both now.

Typos courtesy of my phone's autocorrect.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS - poor performance with "large" directories

[Freddie Cash]

On Thu, Nov 26, 2015 at 2:19 AM, krad <kra...@gmail.com> wrote:

> true, but in my experience usb pen drives are variable in terms of
> performance across different sticks and different areas of the same stick.
> This can complicate things a little, and is often not worth the effort. You
> obviously run the ssd over usb though, and I still do on one server I run
> as I haven't been able to sort the down time yet.
>

​Nowadays, USB 3.x-based sticks in USB 3.x ports should be fast enough that
they'll be helpful.  You won't get the full 5 Gbps from one (unless you
spend as much or more than an SSD), but it will be much better than the
measly 0.5 Gbps of a USB 2.x stick/port.

Don't bother trying with a USB 2.x stick, or with anything plugged into a
USB 2.x port.  Invariably, it will just slow things down.

I used to use 8 GB USB2 sticks in USB2 ports for L2ARC (with a separate one
for the root filesystem).  When I had 4x IDE disks in a raidz1 vdev​, they
helped.  When I migrated to 4x SATA1 disks in a raidz1 vdev, they helped.
When I migrated to 4x SATA3 disks in dual-mirror vdevs (with root-on-ZFS),
suddenly the USB stick became the bottleneck.  Removing it actually made
the whole system faster (better throughput, more IOps, lower latency,
smoother system overall).

​As always, YMMV, and test it with your own setup.  :)​

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI SAS2008 mps driver preferred firmware version

[Freddie Cash]

On Wed, Nov 18, 2015 at 2:25 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:

> On Mon, Nov 16, 2015 at 01:19:55PM -0800, Freddie Cash wrote:
>
> > On Mon, Nov 16, 2015 at 12:57 PM, Slawa Olhovchenkov <s...@zxy.spb.ru>
> wrote:
> > ​Did the original disk get labelled automatically?  No, you had to do
> that
> > when you first started using it.  So, why would you expect a
> > replaced disk
>
> Initial labeling is problem too.
> For new chassis with 36 identical disk (already installed) -- what is
> simple way to labeling disks?
>

​That's the easy part.  Boot with all the drives pulled out a bit, so they
aren't connected/detected.

Insert first disk, wait for it to be detected and get a /dev node, then
partition/label it.  Repeat for each disk.  Takes about 5 minutes to label
a 45-bay JBOD chassis.

No different than how you would get the serial number off each disk before
inserting them into the chassis, so you'd know for sure which slot they're
in.

"Replace disk in bay with blinked led"
>
> Author: bapt
> Date: Sat Sep  5 00:06:01 2015
>

​And, how did you manage to do that before Sep 5, 2015?​

Usaly serial number can be read w/o pull disk (for SuperMicro cases
> this is true, remote hand replaced disk by S/N for me w/o pull every disk).
>

​How?  We have all SuperMicro storage chassis (SC2xx, SC8xx, and JBODs) and
server chassis in our data centre here.  None of them allow you to read the
serial number off the physical disk without pulling the disk out
completely.​  You'd have to manually label each bay with the serial number
before inserting the disk into the chassis ... which is no different from
labelling the device in the OS.  Except it's much faster to find a 3D
co-ordinate (enc0a6) than to scan every bay looking for a specific serial
number.

But, to each their own.  :)  Everyone has their "perfect" system that works
for them.  :D

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS on labelled partitions (was: Re: LSI SAS2008 mps driver preferred firmware version)

[Freddie Cash]

On Tue, Nov 17, 2015 at 12:08 AM, Patrick M. Hausen <hau...@punkt.de> wrote:

> Hi, all,
>
> > Am 16.11.2015 um 22:19 schrieb Freddie Cash <fjwc...@gmail.com>:
> >
> > ​You label the disks as they are added to the system the first time.
> That
> > way, you always know where each disk is located, and you only deal with
> the
> > labels.
>
> we do the same for obvious reasons. But I always wonder about the possible
> downsides, because ZFS documentation explicitly states:
>
> ZFS operates on raw devices, so it is possible to create a storage
> pool comprised of logical
> volumes, either software or hardware. This configuration is not
> recommended, as ZFS works
> best when it uses raw physical devices. Using logical volumes
> might sacrifice performance,
> reliability, or both, and should be avoided.
>
> (from http://docs.oracle.com/cd/E19253-01/819-5461/gbcik/index.html)
>
> Can anyone shed some lght on why not using raw devices might sacrifice
> performance or reliability? Or is this just outdated folklore?
>

​On Solaris, using raw devices allows ZFS to enable the caches on the disks
themselves, while using any kind of partitioning on the disk forces the
caches to be disabled.

This is not an issue on FreeBSD due to the way GEOM works.  Caches on disks
are enabled regardless of how the disk is accessed (raw, dd-partitioned,
MBR-partitioned, GPT-partitioned, gnop, geli, whatever).

This is a common misconception and FAQ with ZFS on FreeBSD and one reason
to not take any Sun/Oracle documentation at face value, as it doesn't
always apply to FreeBSD.

There were several posts from pjd@ about this back in the 7.x days when ZFS
was first imported to FreeBSD.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI SAS2008 mps driver preferred firmware version

[Freddie Cash]

On Mon, Nov 16, 2015 at 12:57 PM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:

> On Mon, Nov 16, 2015 at 11:40:12AM -0800, Freddie Cash wrote:
>
> > On Mon, Nov 16, 2015 at 11:36 AM, Kevin Oberman <rkober...@gmail.com>
> wrote:
> > > As already mentioned, unless you are using zfs, use gpart to label you
> file
> > > systems/disks. Then use the /dev/gpt/LABEL as the mount device in
> fstab.
> > >
> >
> > ​Even if you are using ZFS, labelling the drives with the location of the
> > disk in the system (enclosure, column, row, whatever) makes things so
> much
> > easier to work with when there are disk-related issues.
> >
> > Just create a single partition that covers the whole disk, label it, and
> > use the label to create the vdevs in the pool.​
>
> Bad idea.
> Re-placed disk in different bay don't relabel automaticly.
>

​Did the original disk get labelled automatically?  No, you had to do that
when you first started using it.  So, why would you expect a replaced disk
to get labelled automatically?

Offline the dead/dying disk.
Physically remove the disk.
Insert the new disk.
Partition / label the new disk.
"zfs replace" using the new label to get it into the pool.​


> Other issuse where disk placed in bay some remotely hands in data
> center -- I am relay don't know how disk distributed by bays.
>

​You label the disks as they are added to the system the first time.  That
way, you always know where each disk is located, and you only deal with the
labels.

Then, when you need to replace a disk (or ask someone in a remote location
to replace it) it's a simple matter:  the label on the disk itself tells
you where the disk is physically located.  And it doesn't change if the
controller decides to change the direction it enumerates devices.

Which is easier to tell someone in a remote location:
  Replace disk enc0a6 (meaning enclosure 0, column A, row 6)?
or
  Replace the disk called da36?​
​or
  Find the disk with serial number ?
or
  Replace the disk where the light is (hopefully) flashing (but I can't
tell you which enclosure, front or back, or anything else like that)?

The first one lets you know exactly where the disk is located physically.

The second one just tells you the name of the device as determined by the
OS, but doesn't tell you anything about where it is located.  And it can
change with a kernel update, driver update, or firmware update!

The third requires you to pull every disk in turn to read the serial number
off the drive itself.

In order for the second or third option to work, you'd have to write down
the device names and/or serial numbers and stick that onto the drive bay
itself.​


> Best way for identify disk -- uses enclouse services.
>

​Only if your enclosure services are actually working (or even enabled).
I've yet to work on a box where that actually works (we custom-build our
storage boxes using OTS hardware).

Best way, IMO, is to use the physical location of the device as the actual
device name itself.  That way, there's never any ambiguity at the physical
layer, the driver layer, the OS layer, or the ZFS pool layer.​


> I have many sites with ZFS on whole disk and some sites with ZFS on
> GPT partition. ZFS on GPT more heavy for administration.
>

​It's 1 extra step:  partition the drive, supplying the location of the
drive as the label for the partition.

Everything else works exactly the same.

I used to do everything with whole drives and no labels.  Did that for
about a month, until 2 separate drives on separate controllers died (in a
24-bay setup) and I couldn't figure out where they were located as a BIOS
upgrade changed which controller loaded first.  And then I had to work on a
server that someone else configured with direct-attach bays (24 cables)
that were connected almost at random.

Then I used glabel(8) to label the entire disk, and things were much
better.  But that didn't always play well with 4K drives, and replacing
drives that were the same size didn't always work as the number of sectors
in each disk was different (ZFS plays better with this now).

Then I started to GPT partition things, and life has been so much simpler.
All the partitions are aligned to 1 MB, and I can manually set the size of
the partition to work around different physical sector counts.  All the
partitions are labelled using the physical location of the disk (originally
just row/column naming like a spreadsheet, but now I'm adding enclosure
name as well as we expand to multiple enclosures per system).  It's so much
simpler now, ESPECIALLY when I have to get someone to do something
remotely.  :)

​Everyone has their own way to manage things.  I just haven't seen any
better setup than labelling the drives themselves using their physical
location.​

-- 
Freddie Cash
fjwc...@gmail.com
___

Re: LSI SAS2008 mps driver preferred firmware version

[Freddie Cash]

On Mon, Nov 16, 2015 at 11:36 AM, Kevin Oberman <rkober...@gmail.com> wrote:

> On Mon, Nov 16, 2015 at 1:00 AM, Borja Marcos <bor...@sarenet.es> wrote:
>
> >
> > On Nov 14, 2015, at 3:31 PM, Gary Palmer wrote:
> >
> > > You can do thinks in /boot/loader.conf to hard code bus and drive
> > > assignments.
> > >
> > > e.g.
> > >
> > > hint.da.0.at="scbus0"
> > > hint.da.0.target="19"
> > > hint.da.0.unit="0"
> > > hint.da.1.at="scbus0"
> > > hint.da.1.target="18"
> > > hint.da.1.unit="0"
> >
> > Beware, the target number assignment is not predictable. There's no
> > guarantee especially if you replace
> > a disk.
> >
> >
> >
> >
> >
> > Borja.
> >
>
> As already mentioned, unless you are using zfs, use gpart to label you file
> systems/disks. Then use the /dev/gpt/LABEL as the mount device in fstab.
>

​Even if you are using ZFS, labelling the drives with the location of the
disk in the system (enclosure, column, row, whatever) makes things so much
easier to work with when there are disk-related issues.

Just create a single partition that covers the whole disk, label it, and
use the label to create the vdevs in the pool.​

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot

[Freddie Cash]

On Aug 17, 2015 9:22 AM, Damien Fleuriot m...@my.gd wrote:

 Hello list,



 I'm seeing this very peculiar behaviour between 2 10-STABLE boxes.

 Host A is CARP Master with advskew 20 and runs 10.2-BETA1 from 10/07
 Host B is CARP Backup with advskew 150 and runs 10.2-PRERELEASE from 12/08


 When I configure CARP in rc.conf on host B, it becomes Master on boot, and
 host A remains Master as well.
 When I force a state change on host B (ifconfig vlanx vhid y state
backup),
 it transitions to Backup then again to Master.

 When I comment out the CARP configuration in rc.conf , and configure CARP
 manually on host B's interfaces after it boots, it correctly becomes and
 remains Backup.



 Below is the excerpt from rc.conf pertaining to CARP configuration, the
 only difference between the 2 hosts being their advskew.

 Host A
 == BEGIN

 ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 20 alias
 10.104.10.251/32

 == END

 Host B
 == BEGIN

 ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 150 alias
 10.104.10.251/32

 == END

Put the IP first, and the vhid stuff last in rc.conf for things to work the
most reliably. And drop the extra alias.

ifconfig_vlan410_alias0=inet 10.104.10.251/32 vhid 110 pass passhere
advskew 150

CARP requires that all IPs on an interface that are part of the same vhid
to be listed (added) in the exact same order for the vhid to be considered
the same. That one trips me up all the time when manually adding an IP to
a CARP pair, and then later rebooting one box as they both think they're
master for that interface, while being a mix of master/backup for the other
interfaces.

Cheers,
Freddie
(running CARP on 2 10-CURRENT boxes and 2 10.1-p13 boxes)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Freddie Cash]

On Aug 3, 2015 8:36 AM, Paul Mather freebsd-li...@gromit.dlib.vt.edu
wrote:

 On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com wrote:

  On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu
wrote:
  On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu
wrote:
 
  On 08/02/2015 21:22, Paul Mather wrote:
  I have a 4TB external USB drive (Western Digital My Book 1230) that
I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052:
Wed Jul 29 20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX)
motherboard.
 
  The drive probes unreliably when plugged in to a USB 3 port.  It
reliably probes when plugged into a USB 2 port.  However, it works in
neither cases.  Attempting to dd from the drive results in a dd: /dev/da0:
Invalid argument.
 
  FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X
  (Mavericks). The drive was being used for Time Machine backups, but it
  would at irregular intervals it would just 'disconnect' itself. My
  guess is that there's a firmware problem in the USB3 chip in those
  drives.
 
  After trying to get the issue fixed for almost half a year I returned
  it and replaced it by a Seagate, which has been working flawlessly
  ever since.
 
  I'm just saying, perhaps the problem isn't with FreeBSD but with the
drive.


 I'd love just to get to the randomly disconnects stage under FreeBSD at
this point. :-)

 Up to now, I have been unable to read ANY data off the drive under
FreeBSD, either via USB 2 or USB 3. :-(

 However, you have given me something to think about: does anyone know of
a 4 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE
right now?

2 TB Toshiba drive in a NexStar 6G enclosure, and a 3 TB WD Black drives in
a NexStar 3 enclosures are working great on FreeBSD 9.3 (home), 8.1 (work)
and 10.0 (work). USB 2.x and 3.0. I use them as ZFS backups drives.

I've never liked the all-in-one external drives. I prefer separate
enclosures and drives. That way, the drives can be replaced or upgraded as
needed.
___
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: Is there a linux_base available for RELENG_9?

[Freddie Cash]

Re-read the error message you pasted into the email. Pay particular
attention to the part after 2.6, the last two digits. :)

2.6.16 != 2.6.18

The latter is what needs to be in sysctl.conf, or (as you discovered)
entered via sysctl(8). You will need to put the correct values into
sysctl.conf, though, for it to be set correctly at boot.

Cheers,
Freddie
On Mar 9, 2015 6:07 PM, Chris H bsd-li...@bsdforge.com wrote:

 On Tue, 10 Mar 2015 00:51:06 + Gary Palmer gpal...@freebsd.org wrote

  On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
   I performed av svn update for both src (r279796),
   and ports (r380829) last night. building/installing
   world/kernel, went as one would hope. Upgrading ports
   was a different story. Given this box has an nVidia card.
   I usually start by upgrading emulators/linux_base; which
   according to UPDATING; meant linux_base-f10 -- linux_base-c6.
   I deinstalled x11/nvidia-driver, followed by
   emulators/linux_base-f10. I then attempted to make install
   emulators/linux_base-c6, which resulted in a message
   that it wasn't supported. So I simply cd'd to
   emulators/linux_base-f10, followed by make install. Which
   resulted in a CVE message; indicating it was vulnerable
   to glib issues. I'm now stuck w/o hardware support for
   my video card, and unable to effectively follow
   a safe port upgrade path, that enables me to keep the
   options I have chosen for my currently installed ports.
   Is there a *safe* linux_base available?
  
   Thank you for all your time, and consideration.
 
  If you set
 
  sysctl compat.linux.osrelease=2.6.18
 
  you can install linux_base-c6 on RELENG_9
 
  It works well enough at least for nvidia-driver, as my main desktop
  is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3
  installed
 
  Remember to put
 
  compat.linux.osrelease=2.6.18
 
  into /etc/sysctl.conf so it's preserved on startup
 
  I believe if you read the message from linux_base-c6 that's basically
  what it told you to do.
 Thanks for the reply, Gary.
 Right you are. That's exactly what I did to stage for the upgrade;
 entered 'compat.linux.osrelease=2.6.18' into etc/sysctl.conf
 rebooted, deinstalled x11/nvidia-driver, emulators/linux_base-f10,
 cd emulators/linux_base-c6; make install
 which led to:
 ===  linux_base-c6-6.6_3 compat.linux.osrelease: 2.6.16 is not supported,
 please use 2.6.18, BEWARE this is highly experimental.
 *** [all] Error code 1

 Stop in /usr/ports/emulators/linux_base-c6.

 Thanks! and sorry for not being more detailed in the first place.

 --Chris
 
  Regards,
 
  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
 


 ___
 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: 9.2-PRE: switch off that stupid Nakatomi Socrates

[Freddie Cash]

On Wed, Oct 2, 2013 at 8:22 AM, Ollivier Robert
robe...@keltia.freenix.frwrote:

 According to Ullrich Franke on Tue, Oct 01, 2013 at 05:01:00PM +0200:
  We really should have a /bin/bikeshed. :-)

 /usr/bin/bikesched


Would schedulers get their own binary?  Wouldn't it just be compiled into
the kernel?  Or are you proposing a modular scheduler using the bike
algorithm?

;)


-- 
Freddie Cash
fjwc...@gmail.com
___
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: 9.2-PRE: switch off that stupid Nakatomi Socrates

[Freddie Cash]

On Sep 27, 2013 5:05 PM, grenville armitage garmit...@swin.edu.au wrote:



 On 09/28/2013 08:06, David Demelier wrote:
 [..]

 Also in the future you can just forgot that crappy ideas as you can see,
 nobody liked it.


 I beg to differ.

I know it's not a poll, but myself and the 5 people in my office all
thought it was awesome, and will be leaving it enabled for as long as 9.2
is installed on our servers.

That definitely puts it above nobody liked it.

Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is
too short for this. :)
___
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: Package database

[Freddie Cash]

On Wed, Sep 4, 2013 at 10:41 AM, Jim Ballantine j.ballant...@gmail.comwrote:

 My /var/db/pkg has become corrupt, and I can't find an archive of it to
 install in it's place.  Does one exist and if so where?  If not any ideas
 on
 how to rebuild the db?


Are you using PKGng or the old pkg_* tools?

Meaning, is your data stored as individual files under
/var/db/pkg/PORTNAME/*, or as a single sqlite database under /var/db/pkg?

If using PKGng, there's a backup copy under /var/db/backup*

If using the older pkg_* tools, you're screwed.  :)


-- 
Freddie Cash
fjwc...@gmail.com
___
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: Bind in FreeBSD, security advisories

[Freddie Cash]

On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com wrote:

 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the future.

Hasn't this discussion occurred several times already on the -current
mailing list over the past year? And hadn't unbound and/or ldns been
imported into - current already?

This just seems very familiar somehow...
___
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: Bind in FreeBSD, security advisories

[Freddie Cash]

On 2013-07-30 7:55 AM, Ronald Klop ronald-freeb...@klop.yi.org wrote:

 On Tue, 30 Jul 2013 16:14:57 +0200, Freddie Cash fjwc...@gmail.com
wrote:

 On 2013-07-30 12:55 AM, David Demelier demelier.da...@gmail.com
wrote:


 Hi,

 For years, a lot of security advisories have been present for bind.
 I'm just guessing if it's not a good idea to remove bind from base?

 This will probably free by half the number of FreeBSD SA's in the
future.


 Hasn't this discussion occurred several times already on the -current
 mailing list over the past year?


 http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039830.html


 And hadn't unbound and/or ldns been
 imported into - current already?


 http://lists.freebsd.org/pipermail/svn-src-all/2012-July/056004.html
 And next messages.

Thanks for the references. I'm mostly mailing my phone these days and
searching for references and copy/paste aren't the easiest things to do. :)
___
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: OpenSSH in -STABLE

[Freddie Cash]

Well, you showed an interest in testing a specific feature of 6.2, so a
recommendation to use the version in ports is perfectly valid. :)
 On 2013-05-21 8:03 PM, usa...@hushmail.com wrote:

 On Tue, 21 May 2013 22:20:08 -0400 David Wolfskill
 da...@catwhisker.org wrote:
 On Tue, May 21, 2013 at 09:42:39PM -0400, usa...@hushmail.com
 wrote:
  Hi. Are there any plans to get OpenSSH 6.2 in 9-STABLE? I'd like
 to
  check out the new AES-GCM stuff without going to -CURRENT on
 this
  system. If there are no plans, is there a possibility? Thanks
  
 
 Please refer to ports/security/openssh-portable; its Makefile says
 it's
 6.2p2,1, last updated about 5 days ago.
 

 Thanks, but that wasn't what I asked about. I'm aware of the
 version in ports.

 ___
 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: recommended memory for zfs

[Freddie Cash]

And the rule of thumb for dedupe was approx 1 GB of ARC per unique TB of
data in the pool (above and beyond your normal ARC requirements). Not 1 GB
of RAM per TB of disk in the pool.

Very big difference between the two. :)
 On 2013-05-09 7:14 PM, Adam Vande More amvandem...@gmail.com wrote:

 On Thu, May 9, 2013 at 9:06 PM, Jeremy Chadwick j...@koitsu.org wrote:

  The advice of 1GB of RAM per 1TB of disk space is absolute nonsense on
  numerous levels -- whoever gave this advice to Shane either has no
  understanding of how filesystems/ZFS works, or does but chose to
  simplify to the point where they're providing half-ass information.

 IIRC, that used to be the guideline for memory requirements for dedup.



 --
 Adam Vande More
 ___
 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: Any objections/comments on axing out old ATA stack?

[Freddie Cash]

On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl 
s...@troutmask.apl.washington.edu wrote:

 On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
  Hi.
 
  Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
  stack, using only some controller drivers of old ata(4) by having
  `options ATA_CAM` enabled in all kernels by default. I have a wish to
  drop non-ATA_CAM ata(4) code, unused since that time from the head
  branch to allow further ATA code cleanup.
 
  Does any one here still uses legacy ATA stack (kernel explicitly built
  without `options ATA_CAM`) for some reason, for example as workaround
  for some regression?

 Yes, I use the legacy ATA stack.

 You're missing the reason for why you're running the old ATA stack.

Do you have hardware that doesn't work with ATA_CAM?  Have you not tried
ATA_CAM on that box?  Some other reason?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: netisr issues

[Freddie Cash]

Works if you set them in /etc/sysctl.conf.  Haven't looked into it, but I
think there's something in the startup that sets them to 0 after the kernel
is loaded, so the loader.conf settings are overwritten.


On Mon, Mar 11, 2013 at 7:42 AM, Mark Saad nones...@longcount.org wrote:

 All
  I am looking for some guidance on how to turn netisr back on, on a
 9.1-RELEASE and 9.1-STABLE box. It looks it stopped working as it did in
 prior versions of FreeBSD .
 I tested this on 9.1-RELEASE and  9.1-STABLE #0 r247804 built last monday.

 My question is this. If I enable the direct option in boot/loader.conf via
 this

 net.isr.direct=1
 net.isr.direct_force=1

 I do not get any expected result.

 root@chambers:~ # sysctl net.isr.direct
 net.isr.direct: 0
 root@chambers:~ # sysctl net.isr.direct_force
 net.isr.direct_force: 0

 root@chambers:~ # netstat -Q
 Configuration:
 SettingCurrentLimit
 Thread count 11
 Default queue limit25610240
 Dispatch policy direct  n/a
 Threads bound to CPUs disabled  n/a

 


 Am I missing something ?


 --
 mark saad | nones...@longcount.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




-- 
Freddie Cash
fjwc...@gmail.com
___
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: netisr issues

[Freddie Cash]

You're right.  I was looking at different net.isr oids, not the _direct
ones.  My bad.


On Mon, Mar 11, 2013 at 9:17 AM, Mark Saad nones...@longcount.org wrote:

 On Mon, Mar 11, 2013 at 12:11 PM, Freddie Cash fjwc...@gmail.com wrote:
  Works if you set them in /etc/sysctl.conf.  Haven't looked into it, but I
  think there's something in the startup that sets them to 0 after the
 kernel
  is loaded, so the loader.conf settings are overwritten.
 
 
  On Mon, Mar 11, 2013 at 7:42 AM, Mark Saad nones...@longcount.org
 wrote:
 
  All
   I am looking for some guidance on how to turn netisr back on, on a
  9.1-RELEASE and 9.1-STABLE box. It looks it stopped working as it did in
  prior versions of FreeBSD .
  I tested this on 9.1-RELEASE and  9.1-STABLE #0 r247804 built last
 monday.
 
  My question is this. If I enable the direct option in boot/loader.conf
 via
  this
 
  net.isr.direct=1
  net.isr.direct_force=1
 
  I do not get any expected result.
 
  root@chambers:~ # sysctl net.isr.direct
  net.isr.direct: 0
  root@chambers:~ # sysctl net.isr.direct_force
  net.isr.direct_force: 0
 
  root@chambers:~ # netstat -Q
  Configuration:
  SettingCurrentLimit
  Thread count 11
  Default queue limit25610240
  Dispatch policy direct  n/a
  Threads bound to CPUs disabled  n/a
 
  
 
 
  Am I missing something ?
 
 
  --
  mark saad | nones...@longcount.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
 
 
 
 
  --
  Freddie Cash
  fjwc...@gmail.com

 Freddie
   When I tried to set them in /etc/sysctl.conf , sysctl stated they
 were read-only .

 [root@mkr2 /etc]# sysctl -w net.isr.direct=1
 sysctl: oid 'net.isr.direct' is read only


 [root@mkr2 /etc]# sysctl -w net.isr.direct_force=1
 sysctl: oid 'net.isr.direct_force' is read only

 --
 mark saad | nones...@longcount.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




-- 
Freddie Cash
fjwc...@gmail.com
___
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: netisr issues

[Freddie Cash]

I seem to recall that the method for setting direct changed so that it's
not a binary option (net.isr.direct), but instead is a policy setting now
(net.isr.dispatch).  Try:

net.isr.dispatch=direct

That's what's set on our 9.1-STABLE systems:
# sysctl net.isr
net.isr.numthreads: 8
net.isr.maxprot: 16
net.isr.defaultqlimit: 256
net.isr.maxqlimit: 10240
net.isr.bindthreads: 1
net.isr.maxthreads: 8
net.isr.direct: 0
net.isr.direct_force: 0
net.isr.dispatch: direct

# netstat -Q | head
Configuration:
SettingCurrentLimit
Thread count 88
Default queue limit25610240
Dispatch policy direct  n/a
Threads bound to CPUs  enabled  n/a



On Mon, Mar 11, 2013 at 9:22 AM, Freddie Cash fjwc...@gmail.com wrote:

 You're right.  I was looking at different net.isr oids, not the _direct
 ones.  My bad.


 On Mon, Mar 11, 2013 at 9:17 AM, Mark Saad nones...@longcount.org wrote:

 On Mon, Mar 11, 2013 at 12:11 PM, Freddie Cash fjwc...@gmail.com wrote:
  Works if you set them in /etc/sysctl.conf.  Haven't looked into it, but
 I
  think there's something in the startup that sets them to 0 after the
 kernel
  is loaded, so the loader.conf settings are overwritten.
 
 
  On Mon, Mar 11, 2013 at 7:42 AM, Mark Saad nones...@longcount.org
 wrote:
 
  All
   I am looking for some guidance on how to turn netisr back on, on a
  9.1-RELEASE and 9.1-STABLE box. It looks it stopped working as it did
 in
  prior versions of FreeBSD .
  I tested this on 9.1-RELEASE and  9.1-STABLE #0 r247804 built last
 monday.
 
  My question is this. If I enable the direct option in boot/loader.conf
 via
  this
 
  net.isr.direct=1
  net.isr.direct_force=1
 
  I do not get any expected result.
 
  root@chambers:~ # sysctl net.isr.direct
  net.isr.direct: 0
  root@chambers:~ # sysctl net.isr.direct_force
  net.isr.direct_force: 0
 
  root@chambers:~ # netstat -Q
  Configuration:
  SettingCurrentLimit
  Thread count 11
  Default queue limit25610240
  Dispatch policy direct  n/a
  Threads bound to CPUs disabled  n/a
 
  
 
 
  Am I missing something ?
 
 
  --
  mark saad | nones...@longcount.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
 
 
 
 
  --
  Freddie Cash
  fjwc...@gmail.com

 Freddie
   When I tried to set them in /etc/sysctl.conf , sysctl stated they
 were read-only .

 [root@mkr2 /etc]# sysctl -w net.isr.direct=1
 sysctl: oid 'net.isr.direct' is read only


 [root@mkr2 /etc]# sysctl -w net.isr.direct_force=1
 sysctl: oid 'net.isr.direct_force' is read only

 --
 mark saad | nones...@longcount.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




 --
 Freddie Cash
 fjwc...@gmail.com




-- 
Freddie Cash
fjwc...@gmail.com
___
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: netisr issues

[Freddie Cash]

On Mon, Mar 11, 2013 at 9:40 AM, Mark Saad nones...@longcount.org wrote:

 Freddie
So should I be adjusting the numbers of threads or is this
 determined somewhere ?

 I think it's supposed to be automatic, 1 thread per CPU, but I manually
set it  via /boot/loader.conf:
net.isr.bindthreads=1 # Bind netisr threads to
CPU cores
net.isr.maxthreads=8  # Set number of threads to
number of CPU cores
net.isr.numthreads=8  #

The net.isr.dispatch is automatically set to direct on our systems.  Not
sure if that's the default or not.  We used to set that via
/boot/loader.conf as well, but it was removed in the upgrade to 9-STABLE
something as it no longer did anything.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: ZFS stalls -- and maybe we should be talking about defaults?

[Freddie Cash]

On Tue, Mar 5, 2013 at 7:22 AM, Gary Palmer gpal...@freebsd.org wrote:

 Just as a note that there was a page I read in the past few months
 that pointed out that having a huge ARC may not always be in the best
 interests of the system.  Some operation on the filesystem (I forget
 what, apologies) caused the system to churn through the ARC and discard
 most of it, while regular I/O was blocked


Huh.  What timing.  I've been fighting with our largest ZFS box (128 GB of
RAM, 16 CPU cores, 2x SSD for SLOG, 2x SSD for L2ARC, 45x 2 TB HD for pool
in 6-driive raidz2 vdevs) for the past week trying to figure out why ZFS
send/recv just hangs after awhile.  Everything is stuck in D in ps ax
output, and top show the l2arc_feed_ thread using 100% of one CPU.  Even
removing the L2ARC devices from the pool doesn't help, just slows the
amount of time until the hang.

ARC was configured for 120 GB, with arc_meta_limit set to 90 GB.  Yes,
dedup and compression are enabled (it's a backups storage box, and we get
over 5x combined dedup/compress ratio).  After several hours of running,
the ARC and wired would get up to 100+ GB, and the box would spend most of
its time spinning, with almost 0 I/O to the pool (only a few KB/s of
reads in zpool iostat 1 or gstat).

ZFS send/recv would eventually complete, but what used to take 15-20
minutes would take 6-8 hours to complete.

I've reduced the ARC to only 32 GB, with arc_meta set to 28 GB, and things
are running much smoother now (50-200 MB/s writes for 3-5 seconds every
10s), and send/recv is back down to 10-15 minutes.

Who would have thought too much RAM would be an issue?

Will play with this over the next couple of days with different ARC max
settings to see where the problems start.  All of our ZFS boxes until this
one had under 64 GB of RAM.  (And we had issues with dedupe enabled on
boxes with too little RAM, as in under 32 GB.)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: ZFS stalls -- and maybe we should be talking about defaults?

[Freddie Cash]

On Tue, Mar 5, 2013 at 2:09 PM, Jeremy Chadwick j...@koitsu.org wrote:

 On Tue, Mar 05, 2013 at 01:09:41PM +0200, Andriy Gapon wrote:

   - Disks are GPT and are *partitioned, and ZFS refers to the partitions
 not the raw disk -- this matters (honest, it really does; the ZFS
 code handles things differently with raw disks)
 
  Not on FreeBSD as far I can see.

 My statement comes from here (first line in particular):


 http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/248697.html

 If this is wrong/false, then this furthers my point about kernel folks
 who are in-the-know needing to chime in and help stop the
 misinformation.  The rest of us are just end-users, often misinformed.


This has been false from the very first import of ZFS into FreeBSD
7-STABLE.  Pawel even mentions that GEOM allows the use of the cache on
partitions with ZFS somewhere around that time frame.  Considering he did
the initial import of ZFS into FreeBSD, I don't think you can find a more
canonical answer.  :)

This is one of the biggest differences between the Solaris-based ZFS and
the FreeBSD-based ZFS.

It's too bad this mis-information has basically become a meme.  :(

-- 
Freddie Cash
fjwc...@gmail.com
___
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: zfs v28 solaris compatibility

[Freddie Cash]

If the pool is created as v28 in FreeBSD, then you will be able to import
the pool into Solaris 10 or 11 without any issues.

Just be sure to ignore all the your pool is outdated messages, and do
*NOT* upgrade your pool to ZFSv32 in Solaris.  If you do that, you will not
be able to import the pool in FreeBSD again.


On Thu, Feb 7, 2013 at 4:16 AM, Eugene M. Zheganin e...@norma.perm.ruwrote:

 Hi.

 Is the FreeBSD v28 zfs fully compatible with solaris zfs ? I need to
 switch disks between servers, these disks are SAN disks, and it's about
 20T of data. I don't want to lose them. I am aware that our zfs is
 compatible with Solaris, but I just want to be sure, like really really
 sure. Of course I can switch back at any moment, but only if the data
 won't become corrupted.

 Thanks.
 Eugene.
 ___
 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




-- 
Freddie Cash
fjwc...@gmail.com
___
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: ZFS memory management

[Freddie Cash]

Read any ZFS tuning manual on the web, including the ones direct from
SUN/Oracle, and they all list:
  - if you are running processes that need a lot of memory, then limit the
ARC to allow the apps to have access to that memory

:)


On Tue, Nov 27, 2012 at 12:10 PM, Nikolay Denev nde...@gmail.com wrote:

 Hello list,

 I have the following question : I have several machines with 196G of RAM
 that are using
 RELENG_9 with ZFS, and are running a very memory intensive java
 applications - ElasticSearch
 The machines are without swap configured and have vm.swap_enabled=0 in
 /etc/sysctl.conf.
 The ElasticSearch processes are using mlockall(2) to pin down their memory
 (configured at 40G).
 And at this point I thought that there would be no problems, but from time
 to time, when the machine grows it's
 ARC memory and there are some other running processes like nginx with
 passenger and uwsgi the ElasticSearch
 process would get killed by the kernel OOM killer with reason no swap
 space available

 Of course, I've now tuned down arc_max in /boot/loader.conf, but isn't
 this supposed to work automatically? Like
 ZFS releasing some memory when there is a pressure, instead of the OOM
 killer going postal? (at the moment when
 the process was killed the ZFS ARC was 132G).

 I understand that this might be problematic as AFAIK ZFS releases memory
 asynchronously when the arc_reclaim_thread() is run,
 which might take some time to be scheduled and complete.

 Cheers,
 Nikolay


 ___
 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




-- 
Freddie Cash
fjwc...@gmail.com
___
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: how to update ports while using pkgng?

[Freddie Cash]

Read the pkgng faq online. There's a link to a patch for portmaster, and
info on what to add to make.conf.
On Sep 14, 2012 9:42 PM, Mike Manilone crtm...@gmx.us wrote:

 Hi,

 I'm using ports with pkgng enabled. But I found that portmaster won't
 work. Is there any way to update ports? Thanks!

 Sincerely,
 Mike Manilone
 __**_
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/**mailman/listinfo/freebsd-**stablehttp://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to 
 freebsd-stable-unsubscribe@**freebsd.orgfreebsd-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: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Freddie Cash]

On Wed, Sep 12, 2012 at 12:22 PM, Giulio Ferro au...@zirakzigil.org wrote:
 On 09/11/2012 11:34 PM, Freddie Cash wrote:

 On Sep 11, 2012 2:12 PM, Giulio Ferro au...@zirakzigil.org
 mailto:au...@zirakzigil.org wrote:
  
   Well, there definitely seems to be a problem with igb and lagg.
  
   igb alone works as it should, but doesn't seem to work properly in
 lagg.
  
   To be sure I started from scratch from a 9.0 release with nothing but:
  
   /etc/rc.conf
   ---
   ifconfig_igb0=inet ...
  
   ifconfig_igb1=up
   ifconfig_igb2=up
   ifconfig_igb3=up
  
   cloned_interfaces=lagg0
   ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport
 igb3 192.168.x.x/24
  
   sshd_enable=YES
   ---
  
   This doesn't even manage to start sshd, it just hangs there at boot.
  
   Disabling lagg configuration everything works correctly.
  

 Just curious: does it work if you split the lagg configuration from the
 IP config:

 ifconfig_lagg0=laggproto ...
 ifconfig_lagg0_alias0=inet 192...

 I've had problems in the past with cloned interfaces not working right
 if you do everything in one ifconfig line. Never spent much time
 debugging it, though, as the split config always worked.


 Nope, doesn't work. It always hangs at boot and cannot be killed (freebsd 9
 RELEASE)

 I still think the problem is with lagg and / or igb.
 Someone should look into it.

Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.

You're right, it seems to be pointing to the igb(4) driver in 9.x
compared to  9.0.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Freddie Cash]

On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel jfvo...@gmail.com wrote:
 On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash fjwc...@gmail.com wrote:
 Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.

 You're right, it seems to be pointing to the igb(4) driver in 9.x
 compared to  9.0.

 How do you determine that since it doesn't happen without lagg?  I've no
 reports of igb hanging otherwise and its being used extensively.

Well, I did say seems to.  :)

igb+lagg worked for us on 8.3.  Haven't tried it since moving to 9.0
and 9-STABLE on those three boxes.

igb+lagg doesn't work for him on 9.0.  Although, I don't recall if
non-LACP options were tried earlier in this thread, or if it's just
the LACP mode that's failing.  If one mode works (say failover) and
LACP mode doesn't, that seems to point to lagg.

I'll see if I can free up an igb port on my 9.0 and 9-STABLE boxes to
test this with as well.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Freddie Cash]

On Sep 11, 2012 2:12 PM, Giulio Ferro au...@zirakzigil.org wrote:

 Well, there definitely seems to be a problem with igb and lagg.

 igb alone works as it should, but doesn't seem to work properly in lagg.

 To be sure I started from scratch from a 9.0 release with nothing but:

 /etc/rc.conf
 ---
 ifconfig_igb0=inet ...

 ifconfig_igb1=up
 ifconfig_igb2=up
 ifconfig_igb3=up

 cloned_interfaces=lagg0
 ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport igb3
192.168.x.x/24

 sshd_enable=YES
 ---

 This doesn't even manage to start sshd, it just hangs there at boot.

 Disabling lagg configuration everything works correctly.


Just curious: does it work if you split the lagg configuration from the IP
config:

ifconfig_lagg0=laggproto ...
ifconfig_lagg0_alias0=inet 192...

I've had problems in the past with cloned interfaces not working right if
you do everything in one ifconfig line. Never spent much time debugging it,
though, as the split config always worked.
___
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: Question About Tracking the Stable Branch

[Freddie Cash]

On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin ja...@kode5.net wrote:
 I am following 9 Stable. I have read the handbook information and I am now 
 subscribed to this list and the svn-src-stable-9@ list.

 Even after reading the handbook, what i'm not clear about is this:

 I see individual commits being submitted to the source tree; do I:
 - patch and update each individual commit, or;
 - rebuild world say once every couple of days or even each day to 
 incorporate the changes, and;
 - does the kernel need to be rebuilt and reinstalled each time if 
 using the first option. Obviously I would have to if rebuilding world (the 
 second option).

Personally, I don't update -STABLE boxes unless a specific change
that's useful for my setups comes through.  And then I'll usually wait
1-2 days after the specific commit hits the tree in case there's a
last-minute fix to that commit.

If there's nothing I want to test, or that I need, though, I don't update.

So, it all depends on your needs:
  - are you tracking -STABLE to do development?
  - are you tracking -STABLE to get updated drivers?
  - are you tracking -STABLE to get specific functionality?
  - are you tracking -STABLE to help with bug finding/fixing?
  - etc ...

What your needs are will dictate how often you update the source tree,
rebuild the world, and run with the latest bits.

 Am I right in thinking that it also depends on the type of change; i.e. if 
 the change is to a kernel and/or a kernel module then clearly I need to 
 rebuild the kernel. But, then would I need to rebuild the userland as well?

Most commit logs will include information on whether it's kernel-only,
userland-only, 1-module only, kernel+userland, multiple modules, etc.

Depending on the speed of your machine, you can do a full buildworld
cycle for every update.  Or limit it to just the kernel/userland
component that's updated.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Question About Tracking the Stable Branch

[Freddie Cash]

On Tue, Aug 28, 2012 at 2:03 PM, Kevin Oberman kob6...@gmail.com wrote:
 In all cases, if you rebuild the kernel, be sure that the old kernel
 is saved to kernel.old so you can go back to it if there si a problem.
 'make installkernel' does this) and, should you fix a problem and
 re-link the kernel, be sure NOT to overwrite the working kernel ('make
 reinstallkernel' does this.

It's not mentioned often on the lists, but KODIR and nextboot(8) are
wonderful things:
  # make whatever options buildworld
  # make KERNCONF=MYKERNEL whatever other options buildkernel
  # make KERNCONF=MYKERNEL KODIR=/boot/MYKERNEL whatever other
options installkernel
  # nextboot -k MYKERNEL
  # shutdown -r now

That will install your new kernel into /boot/MYKERNEL, leaving
/boot/kernel alone.  nextboot configures the boot process to use
/boot/MYKERNEL, again leaving /boot/kernel along.  If anything goes
wrong, a simple reboot of the box returns you to using /boot/kernel as
before.

If the new kernel works correctly, then you can manually copy/moves
things around as needed:
  # mv /boot/kernel /boot/kernel.old
  # cp -Rvp /boot/MYKERNEL /boot/kernel

Especially useful when testing new kernels on remote systems, as hit
the reset switch on a locked up box puts things back to the way they
were before.  No loader commands required.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: devd problem with 9-stable

[Freddie Cash]

On Fri, Jun 15, 2012 at 11:45 AM, Oliver Fromme o...@lurza.secnetix.de wrote:
 Chuck Swiger wrote:
   On Jun 15, 2012, at 11:23 AM, Oliver Fromme wrote:
    You can try to prepend a backslash, i.e. echo \$devnum.  This
    isn't documented, but then again, using backslashes to continue
    strings that span multiple lines isn't documented either.
  
   Line continuations and escaping special chars like $ are in man sh:

 Yes, I know that, but the question is how devd(8) parses the
 action strings.

 The problem here is that we have multiple levels or parsing.
 First, devd reads the line, concatenates continuation lines
 (apparently -- it's not documented), expands devd variables,
 and *then* it passes the resulting string to the shell for
 further parsing and processing.

If you have that many levels of backticks, variable expansions,
programs, etc, wouldn't it be a prime candidate for a script?  Just
pass in a couple of variables directly from devd, and then do
everything else inside the script?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Why Are You NOT Using FreeBSD ?

[Freddie Cash]

On Jun 1, 2012 5:34 PM, David Magda dma...@ee.ryerson.ca wrote:

 On Jun 1, 2012, at 08:33, Daniel Kalchev wrote:

  For example if one wants an e-mail server, that is better served in the
long run by IMAP+MTA than any form of Exchange, because you are not tied to
one single platform and that vendor's lunacy. Otherwise FreeBSD runs just
fine as server for about any other OS client, provided those clients use
standard Internet protocols.

 If all you want is e-mail, then there are certainly better options than
Exchange IMHO. However, once you get into calendars (private and shared,
with delegation to secretaries, etc.), meeting rooms, ActiveSync (to
remotely wipe lost devices), then it's a whole different game.

 E-mail was solved a long time ago, but Exchange does many things on top
of it that many organizations find very handy, and where there doesn't seem
to be a decent open alternative.

Zimbra, Kolab, OpenGroupware, Citadel, Zarafa, and many others have filled
the gap in recent years.

Zimbra in particular is very nice to work with. Especially the for-pay
Network Edition. It's basically a drop-in replacement for Exchange, right
down to the Outlook Connector and ActiveSync support.

And the open-source version (which has the exact same web interface) is
also very nice to work with. It's just a nice GUI/DB wrapper to Postfix,
Cyrus IMAPd, MySQL, and various other OSS bits.
___
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: Why Are You NOT Using FreeBSD ?

[Freddie Cash]

On Jun 1, 2012 8:27 PM, Glen Barber g...@freebsd.org wrote:

 On Fri, Jun 01, 2012 at 11:14:10PM -0400, David Magda wrote:
  ZFS is for storing file systems on locally connected block devices.
  Gluster is a network file system where data can be distributed over
  many nodes.
 

 Pardon my ignorance to not knowing what gluster is, but is this
 conceptually similar to HAST?

Similar in concept, but different layers in the storage stack.

HAST sits between the physical disks and the filesystem, replicating data
between two systems. So, disks -- HAST -- ZFS.

Glustre sits above the storage system, replicating data between systems.
So, disks -- ZFS (via Zvols) -- Glustre.

The primary difference is that HAST provides only a single master node that
all I/O goes through. The filesystem(s) above HAST cannot be mounted on
more than one host. I/O is limited to what the master can handle.

Glustre is distributed across hosts, so I/O is multiplied (to some extent),
and data is accessible across multiple hosts.
___
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: FreeBSD 9.0 hangs on heavy I/O

[Freddie Cash]

On Tue, May 29, 2012 at 12:26 PM, Kees Jan Koster kjkos...@gmail.com wrote:
 I seem to have a problem where really heavy disk I/O is drowning my machine. 
 I see hangs in the shell where I am logged on using ssh. Network connections 
 get dropped for no apparent reason and some HTTP requests are served really 
 slowly. Profiling the app code shows that the hangs are in completely random 
 places. Operations that are no more than a few lines of code apart suddenly 
 take seconds to complete.

 In my search I seem to find that my machine is quite slow on the disk. I find 
 that rather odd, given that the device in question is an SSD drive and it is 
 a good bit faster than the WD drive that used to carry the data set that is 
 accessed heavily. This drive is doing 1.5 times the throughput, but the hangs 
 have not gone away.

 To clarify, the data set used to live on ada2 (see the devlist below) which 
 is a spinning disk. When I experienced intermittent hangs I plugged in an SSD 
 drive (ada3 on the devlist) and moved the data there. This improved the MB's 
 per second that are being written (it is mostly-write data) but has not 
 changed the hangs. If anything, they got worse since.

 Using gstat I notice that I/O service time is quite high. From the gstat 
 below you can see that it takes just over 2s to servr the requests. The L(q) 
 seems to never drop far below 100 and %busy hovers around 100% all day long. 
 Can someone please help me troubleshoot that further? What can I do to make 
 the underlying problem visible?

 I should mention all data is referenced through cross-mountpoint symlinks, 
 would that make a difference? Should I use canonical paths in the code 
 instead?

 All file systems are mounted noatime, soft-updates.

You may want to play around with gshed, the GEOM Scheduler.

Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
order to satisfy write threads (or the other way around?).  But,
adding gsched into the mix helped things immensely, allowing mixed
reads/writes to better shares disk I/O resources.

I'll see if I can dig up a link to his testing e-mail messages.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: FreeBSD 9.0 hangs on heavy I/O

[Freddie Cash]

On Tue, May 29, 2012 at 12:34 PM, Freddie Cash fjwc...@gmail.com wrote:
 On Tue, May 29, 2012 at 12:26 PM, Kees Jan Koster kjkos...@gmail.com wrote:
 I seem to have a problem where really heavy disk I/O is drowning my machine. 
 I see hangs in the shell where I am logged on using ssh. Network connections 
 get dropped for no apparent reason and some HTTP requests are served really 
 slowly. Profiling the app code shows that the hangs are in completely random 
 places. Operations that are no more than a few lines of code apart suddenly 
 take seconds to complete.

 In my search I seem to find that my machine is quite slow on the disk. I 
 find that rather odd, given that the device in question is an SSD drive and 
 it is a good bit faster than the WD drive that used to carry the data set 
 that is accessed heavily. This drive is doing 1.5 times the throughput, but 
 the hangs have not gone away.

 To clarify, the data set used to live on ada2 (see the devlist below) which 
 is a spinning disk. When I experienced intermittent hangs I plugged in an 
 SSD drive (ada3 on the devlist) and moved the data there. This improved the 
 MB's per second that are being written (it is mostly-write data) but has not 
 changed the hangs. If anything, they got worse since.

 Using gstat I notice that I/O service time is quite high. From the gstat 
 below you can see that it takes just over 2s to servr the requests. The L(q) 
 seems to never drop far below 100 and %busy hovers around 100% all day long. 
 Can someone please help me troubleshoot that further? What can I do to make 
 the underlying problem visible?

 I should mention all data is referenced through cross-mountpoint symlinks, 
 would that make a difference? Should I use canonical paths in the code 
 instead?

 All file systems are mounted noatime, soft-updates.

 You may want to play around with gshed, the GEOM Scheduler.

 Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
 DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
 order to satisfy write threads (or the other way around?).  But,
 adding gsched into the mix helped things immensely, allowing mixed
 reads/writes to better shares disk I/O resources.

 I'll see if I can dig up a link to his testing e-mail messages.

Here's the post, part of a thread on benchmarking RAID controllers:

http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00034.html


-- 
Freddie Cash
fjwc...@gmail.com
___
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: FreeBSD 9.0 hangs on heavy I/O

[Freddie Cash]

On Tue, May 29, 2012 at 2:12 PM, Kees Jan Koster kjkos...@gmail.com wrote:
 You may want to play around with gshed, the GEOM Scheduler.

 Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
 DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
 order to satisfy write threads (or the other way around?).  But,
 adding gsched into the mix helped things immensely, allowing mixed
 reads/writes to better shares disk I/O resources.

 I'll see if I can dig up a link to his testing e-mail messages.

 Here's the post, part of a thread on benchmarking RAID controllers:

 http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00034.html

 I looked at sysctl kern.geom.confdot (another ridiculously useful feature) 
 to see where the scheduler should be placed.

 The way I was thinking, I should place a scheduler in such a way that writes 
 to one physical device (ada3 in my case) do not cause reads on another device 
 to stall (e.g. ada2, where the database lives). However, it looks like the 
 GEOM tree is actually a GEOM bush, with a separate tree for each device.

 Am I missing something? Is there a way to schedule across devices? Is the 
 bush a tree after all, maybe?

There are others much better versed in the ways of GEOM than I, and
hopefully they will jump in to simplify/clarify things.  :)

The way I understand things is that GEOM is a per-device stack of GEOM
classes, with the physical device at the bottom, and the VM/block/I/O
(?) system at the top.  Thus, unless you use one of the multi-device
GEOM classes (graid, gmirror, gstripe, gvinum), then each stack is
independent of the others.

Meaning gsched only works for a single stack (ie, a single device).

Granted, I haven't played with gsched yet (most of our high-I/O
systems are ZFS), so there may be a way to use it across-GEOMs.
-- 
Freddie Cash
fjwc...@gmail.com
___
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: FreeBSD 9.0 hangs on heavy I/O

[Freddie Cash]

On Tue, May 29, 2012 at 2:30 PM, Kees Jan Koster kjkos...@gmail.com wrote:
 Dear Freddie,

 Granted, I haven't played with gsched yet (most of our high-I/O
 systems are ZFS), so there may be a way to use it across-GEOMs.

 From my previous experiments ZFS suffers the same fate when there is heavy 
 write activity. Reads just don't get served in time.

 How do you deal with that?

We're currently only using FreeBSD (and ZFS) on our backups servers.
The two main servers do rsync backups for ~150 remote Linux servers
and FreeBSD firewalls (1 server does the elementary and secondary
schools; the other server does the admin sites).  Then they do zfs
sends to a third system off-site.

Thus, our workloads tend to be fairly one-sided (all reads on the zfs
send side; all writes on the zfs recv side; mostly reads on the rsync
side side with some writes).  And, most of our working set fits into
ARC/L2ARC.  Cache devices really help, as most reads come from the
L2ARC, while most writes go straight through to the pool.

We're still a year or so away from our ultimate goal of using
FreeBSD+ZFS+NFS to create a separate/proper SAN/NAS tier for our
virtual servers.  At that point, we'll look a little deeper into
things, and experiment with different L2ARC/ZIL setups to optimise
read and write paths.


-- 
Freddie Cash
fjwc...@gmail.com
___
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

Make filesystem type configurable for periodic(8)?

[Freddie Cash]

A few of the periodic(8) scripts in FreeBSD have constructs similar to
the following to get which filesystems to scan for various things:
MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`

For systems with large ZFS pools, and many ZFS filesystems, these
periodic scripts can grind it to its knees, and then some.  For
backups servers where we don't really care about the
ownership/permissions of files from the FreeBSD perspective, we really
don't want the ZFS filesytems to be scanned; only the UFS ones for the
FreeBSD OS install.  To that end, I have to manually edit these files
to remove the ,zfs:
MP=`mount -t ufs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
  
Would it be worthwhile to anyone else to make the filesystem type(s)
to scan via the periodic(8) scripts a variable that's set by default
in /etc/defaults/periodic.conf and that user's can override via
/etc/periodic.conf?

Or, am I the only one that's suffering here?  :)

If there's interesting in this, I can look into coming up with some
patches.  But wanted to check if anyone else would find it useful.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Make filesystem type configurable for periodic(8)?

[Freddie Cash]

On Fri, May 4, 2012 at 9:08 AM, Bryan Drewery br...@shatow.net wrote:
 On 05/04/2012 11:05 AM, Freddie Cash wrote:
 A few of the periodic(8) scripts in FreeBSD have constructs similar to
 the following to get which filesystems to scan for various things:
     MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`

 For systems with large ZFS pools, and many ZFS filesystems, these
 periodic scripts can grind it to its knees, and then some.  For
 backups servers where we don't really care about the
 ownership/permissions of files from the FreeBSD perspective, we really
 don't want the ZFS filesytems to be scanned; only the UFS ones for the
 FreeBSD OS install.  To that end, I have to manually edit these files
 to remove the ,zfs:
     MP=`mount -t ufs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
                           
 Would it be worthwhile to anyone else to make the filesystem type(s)
 to scan via the periodic(8) scripts a variable that's set by default
 in /etc/defaults/periodic.conf and that user's can override via
 /etc/periodic.conf?

 Or, am I the only one that's suffering here?  :)

 If there's interesting in this, I can look into coming up with some
 patches.  But wanted to check if anyone else would find it useful.


 I would find this useful. But further, I have a ZFS root pool as well as
 a ZFS backup pool. I don't want to exclude all of ZFS, just certain
 pools, or even certain datasets.

Would you mind testing the attached patch?  It adds four new variables
for use in periodic.conf (defaults shown):

daily_status_security_chksetuid_fs=ufs,zfs
daily_status_security_chksetuid_fs_ignore=
daily_status_security_neggrpperm_fs=ufs,zfs
daily_status_security_neggrpperm_fs_ignore=

The _fs variables take filesystem types, as would be passed to
mount(8).  These limit the entire search based on type, so an all or
nothing approach.

The _fs_ignore variables are space separated lists of mountpoints to
skip.  So you can leave zfs in the _fs list, and then list specific
filesystems here that you do not want to be scanned.

I don't claim to be any great shell script writer, but this appears to
do the job.  Any suggestions, pointers, comments, etc welcomed.  :)

-- 
Freddie Cash
fjwc...@gmail.com


periodic-fs-type.patch
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Make filesystem type configurable for periodic(8)?

[Freddie Cash]

On Fri, May 4, 2012 at 11:02 AM, Freddie Cash fjwc...@gmail.com wrote:
 On Fri, May 4, 2012 at 9:08 AM, Bryan Drewery br...@shatow.net wrote:
 On 05/04/2012 11:05 AM, Freddie Cash wrote:
 A few of the periodic(8) scripts in FreeBSD have constructs similar to
 the following to get which filesystems to scan for various things:
     MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`

 For systems with large ZFS pools, and many ZFS filesystems, these
 periodic scripts can grind it to its knees, and then some.  For
 backups servers where we don't really care about the
 ownership/permissions of files from the FreeBSD perspective, we really
 don't want the ZFS filesytems to be scanned; only the UFS ones for the
 FreeBSD OS install.  To that end, I have to manually edit these files
 to remove the ,zfs:
     MP=`mount -t ufs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
                           
 Would it be worthwhile to anyone else to make the filesystem type(s)
 to scan via the periodic(8) scripts a variable that's set by default
 in /etc/defaults/periodic.conf and that user's can override via
 /etc/periodic.conf?

 Or, am I the only one that's suffering here?  :)

 If there's interesting in this, I can look into coming up with some
 patches.  But wanted to check if anyone else would find it useful.


 I would find this useful. But further, I have a ZFS root pool as well as
 a ZFS backup pool. I don't want to exclude all of ZFS, just certain
 pools, or even certain datasets.

 Would you mind testing the attached patch?  It adds four new variables
 for use in periodic.conf (defaults shown):

 daily_status_security_chksetuid_fs=ufs,zfs
 daily_status_security_chksetuid_fs_ignore=
 daily_status_security_neggrpperm_fs=ufs,zfs
 daily_status_security_neggrpperm_fs_ignore=

 The _fs variables take filesystem types, as would be passed to
 mount(8).  These limit the entire search based on type, so an all or
 nothing approach.

 The _fs_ignore variables are space separated lists of mountpoints to
 skip.  So you can leave zfs in the _fs list, and then list specific
 filesystems here that you do not want to be scanned.

 I don't claim to be any great shell script writer, but this appears to
 do the job.  Any suggestions, pointers, comments, etc welcomed.  :)

Guess I should mention how to use the patch.  :)

cd /etc
patch -p0  /path/to/periodic-fs-type.patch

-- 
Freddie Cash
fjwc...@gmail.com
___
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

Process for getting data to report LoRs

[Freddie Cash]

Is it possible to get the backtrace for a LoR from any of the system
logs or anything like that, after the fact?  Especially after
rebooting into a non-debug kernel?

I compiled a custom kernel for our ZFS boxes that have been locking up
on me lately, adding INVARIANTS and WITNESS.  But, to be safe, I
booted the debug kernel using nextboot on Friday.  The boxes locked up
over the weekend, and we restarted, reverting them back to the
non-debug kernel.

Going through /var/log/messages, I see a couple LoRs that aren't
listed on http://ipv4.sources.zabbadoz.net/freebsd/lor.html

However, as I'm not running the debug kernel anymore, I can't go
through sysctl to grab the backtrace for it.  Is there any other way
to get the info?  Is there anyway to configure the system to log the
backtrace to a file?

Here's the info from /var/log/messages, which I'm guessing is not
enough to track down the cause of the LoR:
lock order reversal:
1st 0xfe0019415098 zfs (zfs) @
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1704
2nd 0xfe00191669f8 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:1665

lock order reversal:
1st 0xfe00194d0eb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:374
2nd 0xfe000adb2bc0 if_afdata (if_afdata) @
/usr/src/sys/netinet6/scope6.c:417

System info:
FreeBSD betadrive.sd73.bc.ca 9.0-STABLE FreeBSD 9.0-STABLE #0 r234466:
Fri Apr 20 10:57:30 PDT 2012
r...@betadrive.sd73.bc.ca:/usr/obj/usr/src/sys/ZFSHOST90  amd64

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Restricting users from certain privileges

[Freddie Cash]

On Apr 28, 2012 12:50 AM, Zenny garbytr...@gmail.com wrote:

 On Sat, Apr 28, 2012 at 9:38 AM, Daniel Braniss da...@cs.huji.ac.il
wrote:

   Hi:
  
   I could not figure out how to restrict users or other users from
certain
   privileges to execute certain commands in FreeBSD/NanoBSD?
  
   What I meant is I want to create a NanoBSD image in which there will
be
  an
   additional user, say 'admin'. I need to give this new user (admin)
some
   privileges to run some root-can-only-execute commands, but not all
(ACL
   similar to the firmwares in adsl modems from ISPs).
  
   I read Dru Lavingne's 'BSD Hacks' and Joseph Kong's 'Designing BSD
   Rootkits' besides FreeBSD handbook, but I simply could not figure out.
   Could anyone throw some light on this? Appreciate it!
  
   Thanks!
  
   /zenny
 
  try sudo from ports, security/sudo
 
  cheers,
 danny
 
 
 Thanks Daniel, but sudo gives all (not selective) root privileges to the
 user (admin in my case). So this is not what I am trying to achieve in my
 original post.

Sudo let's you do a lot more than all-or-nothing access. You can specify
individual commands that can be run, even down to the options that can be
used, and whether or not they need a passwd. And you can even specify which
user to run the command as (doesn't have to be root).

Read through the sudoers(5) man page and the comments in the default
sudoers file for all the gory details.

Cheers,
Freddie Cash
fjwc...@gmail.com
___
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: Restricting users from certain privileges

[Freddie Cash]

On Apr 28, 2012 4:03 PM, Jason Hellenthal jhellent...@dataix.net wrote:
 cp /usr/bin/vi ~/

 or upload your own...

 sudo $HOME/vi


If your Cmnd_Alias includes the full path to vi, then your last command
won't work.
___
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: top not restoring terminal echo/icanon correctly

[Freddie Cash]

On Tue, Apr 17, 2012 at 11:22 AM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
 (Please keep me CC'd as I'm not subscribed to the list)

 I'd like to request that folks running RELENG_8 (and RELENG_9, though I
 do not use it) please check the behaviour of their terminal after each
 of following commands are run (check terminal after each command):

 top -a  (press q after 1 screen refresh)
 top -b

FreeBSD omegadrive.sd73.bc.ca 9.0-STABLE FreeBSD 9.0-STABLE #4
r233844: Tue Apr 10 13:28:22 PDT 2012
r...@omegadrive.sd73.bc.ca:/usr/obj/usr/src/sys/ZFSHOST90  amd64

Both commands work correctly for me with TOP=CHP in the env, and with
TOP unset in the env.

Connecting to the console over the network using the console
redirection support in the SuperMicro K8HDGi-F motherboard.

Connecting to the terminal running tmux via SSH also works for both commands.

Have not tested either command while physically at the console.

Tested under ZSH as a normal user and CSH as root.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: top not restoring terminal echo/icanon correctly

[Freddie Cash]

On Tue, Apr 17, 2012 at 12:38 PM, Freddie Cash fjwc...@gmail.com wrote:
 On Tue, Apr 17, 2012 at 11:22 AM, Jeremy Chadwick
 free...@jdc.parodius.com wrote:
 (Please keep me CC'd as I'm not subscribed to the list)

 I'd like to request that folks running RELENG_8 (and RELENG_9, though I
 do not use it) please check the behaviour of their terminal after each
 of following commands are run (check terminal after each command):

 top -a  (press q after 1 screen refresh)
 top -b

 FreeBSD omegadrive.sd73.bc.ca 9.0-STABLE FreeBSD 9.0-STABLE #4
 r233844: Tue Apr 10 13:28:22 PDT 2012
 r...@omegadrive.sd73.bc.ca:/usr/obj/usr/src/sys/ZFSHOST90  amd64

 Both commands work correctly for me with TOP=CHP in the env, and with
 TOP unset in the env.

 Connecting to the console over the network using the console
 redirection support in the SuperMicro K8HDGi-F motherboard.

Just an update.  The console session has TERM=xterm.

 Connecting to the terminal running tmux via SSH also works for both commands.

The tmux session has TERM=screen.

 Have not tested either command while physically at the console.

 Tested under ZSH as a normal user and CSH as root.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: 157k interrupts per second causing 60% CPU load on idle system

[Freddie Cash]

On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer matt.th...@gmail.com wrote:
 So it seems that both the old and new mps driver have a problem with the
 Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS
 6G) controller (flashed with -IT firmware).

I wouldn't say the driver has a problem with that specific drive.
More that it might have a problem with a mixed SATA2/SATA3 setup.

I have a 9-STABLE box with 24x WDC WD2002FAEX SATA3 (6 Gbps) drives
attached to 3 SuperMicro AOC-USAS2-8Li controllers, using the new
mps(4) driver without any issues.  Was actually amazed yesterday when
I say it doing writes just shy of 500 MBps to the ZFS pool, via zfs
send/recv from another box.

No issues with excessive interrupts.  Using 10.0 firmware on the controllers.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: New LSI mps driver for 9.0

[Freddie Cash]

On Thu, Mar 8, 2012 at 8:17 AM, Johan Hendriks joh.hendr...@gmail.com wrote:
 Is it possible to get a 'official' patch for the latest LSI mps driver for
 9.0 RELEASE.

There are patches floating around for mpslsi(4) for 9.0.

And, if you upgrade to stable/9, mps(4) *is* the official driver from LSI.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: zfs, 1 gig of RAM and periodic weekly

[Freddie Cash]

On Mon, Feb 27, 2012 at 11:02 AM, Nenhum_de_Nos
math...@eternamente.info wrote:
 On Mon, February 27, 2012 15:33, Chuck Swiger wrote:
 On Feb 26, 2012, at 9:07 PM, Eugene M. Zheganin wrote:
 [ ... ]
 all with zfs and one gig of RAM.

 This isn't a sensible combination; I wouldn't try to run ZFS on anything 
 less than 4GB...

 regardless of the pool size ?

 I was planning on making an atom board a file server for my home, and I have 
 two options: soekris
 net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as 
 well). My plans are
 to use from 4 up to 8 disks, and they should be 2TB at least.

 As its for home use, some p2p software and mostly music listening and 
 sometimes movie streaming.

 should 2GB be that bad, that I should drop it and use UFS instead ?

 I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1.

You can get away with 2 GB of RAM, if you spend a lot of time manually
tuning things to prevent kmem exhaustion and prevent ZFS ARC from
starving the rest of the system (especially on the network side of
things).

Definitely go with a 64-bit install.  Even with less than 4 GB of RAM,
you'll benefit from the large kmem size and better auto-tuning.

Do not, under any circumstances, enable dedupe on a system with less
than 16 GB of RAM.  :)

If at all possible, find a motherboard that will let you use more RAM.
 2 GB is usable.  But 4 GB is the sweet spot for a simple file server.
 And 16 GB is best for a system with over 10 TB of storage in the
pool.

My home media server is a 32-bit install of FreeBSD 8-STABLE (Dec 2011
vintage) with only 2 GB of RAM, using 4x 500 GB SATA drives in 2
mirror vdevs (boot off USB stick).  Every couple of weeks it'll lock
up, usually under heavy torrent load.  Prior to doing a bunch of tune
loader.conf; reboot; crash; repeat cycles, the box was very unstable.
 2 GB is barely enough for ZFS + NFS + Samba + torrents + whatever.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: New BSD Installer

[Freddie Cash]

If you're mirroring the disk with gmirror, how are you dual-booting the
disk?

This discussion is about using gmirror to mirror two entire disks, and then
use GPT to partition the mirror device.

Dual-booting has no bearing on that, as gmirror is a FreeBSD-only
technology.

Cheers,
Freddie Cash
fjwc...@gmail.com
On Feb 18, 2012 10:37 PM, Kevin Oberman kob6...@gmail.com wrote:

 On Fri, Feb 17, 2012 at 1:50 PM, Freddie Cash fjwc...@gmail.com wrote:
  On Fri, Feb 17, 2012 at 1:38 PM, Andriy Gapon a...@freebsd.org wrote:
  And just in case:
  Unified Extensible Firmware Interface Specification Version 2.3.1,
 Errata A
  September 7, 2011 says:
  [snip]
  Two GPT Header structures are stored on the device: the primary and the
  backup. The primary GPT Header must be located in LBA 1 (i.e., the
 second
  logical block), and the backup GPT Header must be located in the last
 LBA
  of the device.
 
  I can not see any ambiguity or openness to interpretation in this
 paragraph.
 
  Unless it's specified somewhere else (which is possible), in this
  paragraph, device does not necessarily mean physical disk.  Last
  LBA of the device could be interpreted as last LBA of the GEOM
  provider.
 
  The beauty of GEOM is that device is whatever logical mapping it
 provides.
 
  After all, LBAs are logical addresses (it's right there in the name!),
  not hardwired physical sector addresses.  ;)  If they were hardwired,
  then how would internal sector remapping work?  ;)

 Please remember that some disks are dual-boot. FreeBSD may understand
 geom has the backup one block from the last LBA on the disk, but no
 other OS is likely to do so.

 Unless I am missing something, this should be a non-starter. Totally
 unacceptable. The backup belongs in the last and only in the last LBA
 on the physical disk.
 --
 R. Kevin Oberman, Network Engineer
 E-mail: kob6...@gmail.com

___
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: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)

[Freddie Cash]

On Fri, Feb 17, 2012 at 3:21 AM, Alexander Leidinger
alexan...@leidinger.net wrote:
 Quoting Freddie Cash fjwc...@gmail.com (from Tue, 14 Feb 2012 08:26:54
 -0800):

 On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith smi...@nimnet.asn.au wrote:

 On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
   1 IPSTEALTH                      - changes ipfw module only?

 I don't think this is specific to ipfw.  From /sys/conf/NOTES:

 # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
 # packets without touching the TTL).  This can be useful to hide
 firewalls
 # from traceroute and similar tools.

 But can it be disabled once added to kernel?  It's no good as a default.


 It's controllable via sysctl once it's compiled into the kernel.  If
 it's not compiled into the kernel, then the sysctl doesn't exist.


 Is it the following?
 net.inet.ip.stealth=0

Yeah, that's the one.
-- 
Freddie Cash
fjwc...@gmail.com
___
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: New BSD Installer

[Freddie Cash]

On Fri, Feb 17, 2012 at 3:12 AM, Pete French petefre...@ingresso.co.uk wrote:
 I wasn't aware you could do that.  I was only aware that it was the
 other way around.  That (my) misconception seems to also be relayed
 by others such as Miroslav who said:

 Should this not be the recommended way of doing things even for MBR
 disks ? I have a lot of machines booting from gmirror, but we always
 do it by mirroring MBR partitions (or GPT ones). I cant see why you would
 want to do it the other way round in fact. It doesnt gain you anything
 does it ?

The problem with mirroring partitions is that you thrash the disk
during the rebuild after replacing a failed disk.  And the more
partitions you have, the worse it gets.

If you mirror the device, then the rebuild process only has to rebuild
a single thing.

If you mirror 4 partitions on a device, then there will be four
simultaneous, parallel rebuild processes running, thrashing the drive
heads on both devices, killing you I/O throughput and extending the
length of the rebuild.

And if you mix your redundancy technologies (like gmirror and zfs
mirror) it gets even worse due to competing rebuild schedulers.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: New BSD Installer

[Freddie Cash]

On Fri, Feb 17, 2012 at 1:38 PM, Andriy Gapon a...@freebsd.org wrote:
 And just in case:
 Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A
 September 7, 2011 says:
 [snip]
 Two GPT Header structures are stored on the device: the primary and the
 backup. The primary GPT Header must be located in LBA 1 (i.e., the second
 logical block), and the backup GPT Header must be located in the last LBA
 of the device.

 I can not see any ambiguity or openness to interpretation in this paragraph.

Unless it's specified somewhere else (which is possible), in this
paragraph, device does not necessarily mean physical disk.  Last
LBA of the device could be interpreted as last LBA of the GEOM
provider.

The beauty of GEOM is that device is whatever logical mapping it provides.

After all, LBAs are logical addresses (it's right there in the name!),
not hardwired physical sector addresses.  ;)  If they were hardwired,
then how would internal sector remapping work?  ;)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: New BSD Installer

[Freddie Cash]

On Thu, Feb 16, 2012 at 6:40 PM, Warren Block wbl...@wonkity.com wrote:
 On Thu, 16 Feb 2012, Jeremy Chadwick wrote:

 On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote:


 (...Linux mdadm)

 So for version 0.90 of their metadata format, you lose drive capacity by
 about 64-128KBytes, given that the space is needed for metadata.  For
 version 1.0, I'm not sure.  For version 1.1 it looks like the metadata
 can be stored at the beginning.

 So overall, this sounds to me like the equivalent of if GEOM was to
 lie about the actual capacities of the devices when using classes that
 require use of metadata (gmirror, etc.).

 Sorry, I may be misunderstanding your point.  GEOM classes don't lie, they
 accurately represent the space.  The space provided by a gmirror is one
 block less than the actual space occupied, to allow for the metadata block
 at the end.  The problem is that GPT puts backup partition tables at the end
 of the physical (not logical) device. Create a GEOM device on that drive,
 and the GEOM metadata overwrites the backup GPT partition table.  Well, the
 last block of it, anyway.

 But create the GEOM device inside a GPT partition that spans the drive, and
 things are fine.  The GPT backup tables are safely outside the GEOM
 metadata, which is safely outside of the data.

 Short-form: GPT tables are at the absolute start and end of the physical
 disk.  GEOM metadata is relative, at the end of the logical device, not
 necessarily the end of the physical device.

Seems to me that we need a GEOM-aware loader that can taste the GEOM
metadata on a disk *before* the GPT is read, such that the first and
last physical block of the disk becomes the first and last physical
block of the GEOM provider.  Perhaps by storing the GEOM class
metadata in the first and last blocks of the provider.  Then you just
start reading the start of the disk, notice a gmirror metadata block,
setup the gmirror, notice a gstripe metadata block, setup the gstripe,
notice a GPT metadata block, load the GPT partitions, etc

No idea just how feasible this would be, though.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: New BSD Installer

[Freddie Cash]

On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato h...@freebsd.org wrote:
 Jeremy Chadwick free...@jdc.parodius.com wrote
  in 20120217030806.ga62...@icarus.home.lan:

 fr On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:
 fr  Sorry, I may be misunderstanding your point.  GEOM classes don't
 fr  lie, they accurately represent the space.  The space provided by a
 fr  gmirror is one block less than the actual space occupied, to allow
 fr  for the metadata block at the end.  The problem is that GPT puts
 fr  backup partition tables at the end of the physical (not logical)
 fr  device. Create a GEOM device on that drive, and the GEOM metadata
 fr  overwrites the backup GPT partition table.  Well, the last block of
 fr  it, anyway.
 fr 
 fr  But create the GEOM device inside a GPT partition that spans the
 fr  drive, and things are fine.  The GPT backup tables are safely
 fr  outside the GEOM metadata, which is safely outside of the data.
 fr
 fr I wasn't aware you could do that.  I was only aware that it was the
 fr other way around.  That (my) misconception seems to also be relayed
 fr by others such as Miroslav who said:
 fr
 fr GPT doesn't play nice with GEOM classes which store their metadata
 fr on last sector.  For example, you can't use gmirror of a whole drives
 fr and use GPT on top of this mirror. (and gmirror is not the only one)
 fr
 fr So if I read this correctly, it means that the erroneous behaviour is
 fr the result of someone doing things in the wrong order (for lack of
 fr better terminology).

  Well, does GPT really depend on the absolute last block?  The header
  has fields for both the first and the last LBAs and they do not have
  to be matched with the physical capacity.  Creating a gmirror first,
  and then creating a GPT on it does not work?  I do not think it is
  true, and I suspect a description on gmirror recommending
  kern.geom.debugflags=17 in the handbook is the source of the problem.

It's not the partitioning that's the issue.  It's the order that GEOM
providers and GPT partition tables are tasted.

You can gmirror two disks, then GPT partition the gm0 device without
any issues.  As you noted, the first/last sectors are 1 less than the
physical disk (the size of the gmirror provider).

When you boot, though, the gptboot loader only sees the GPT table, it
doesn't know that it's part of a gmirror setup.  Thus it loads the
GPT, notices that the size of the GPT is 1 less sector than the size
of the disk, can't find the secondary GPT table as the last sector of
the disk is gmirror metadata, and complains about corrupted GPT.

Then the kernel loads, gmirror tastes the disk, finds the gmirror
metadata, configures the gmirror provider, and now all the GPT stuff
matches again.  And the system carries on correctly.

The issue is that we don't have a GEOM-aware loader.  Or, at least,
that the gpt*boot loaders read the GPT table(s) before configuring the
GEOM providers.

If we had a gloader that understood all the different GEOM classes,
this would be a non-issue.  At least, from my limited understanding of
things.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)

[Freddie Cash]

On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith smi...@nimnet.asn.au wrote:
 On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
   1 IPSTEALTH                      - changes ipfw module only?

 I don't think this is specific to ipfw.  From /sys/conf/NOTES:

 # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
 # packets without touching the TTL).  This can be useful to hide firewalls
 # from traceroute and similar tools.

 But can it be disabled once added to kernel?  It's no good as a default.

It's controllable via sysctl once it's compiled into the kernel.  If
it's not compiled into the kernel, then the sysctl doesn't exist.

   1 IPFIREWALL_VERBOSE_LIMIT=5     - changes ipfw module only?
                                      loader tunable?

This is controllable via sysctl.  Not sure if it needs to be compiled
into the kernel before it's controllable via sysctl, though.   We have
compiled into all our firewall kernels (with a default of 1000), then
change it via sysctl when needed.

   1 IPFIREWALL_VERBOSE             - changes ipfw module only?
                                      loader tunable?

 sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit

Ah, you list the sysctls that control the last two.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: CARP carpdev

[Freddie Cash]

On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva h...@barafranca.com wrote:
 Looks like there's been conversations about porting this to FreeBSD since at
 least 2007.

 Are there any plans to have ifconfig carpdev available in 9.0-STABLE?

CARP support has been redone in 10-CURRENT, removing the whole carp0
pseudo-interface support, and just enabling the CARP protocol on the
existing network interfaces. This includes the equivalent of carpdev
support.

Search the -current archives for more information, CFT, and so on.

I don't recall seeing anything about specific plans to MFC to
stable/9, but could be mis-remembering things.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Reducing the need to compile a custom kernel

[Freddie Cash]

2012/2/10 Andreas Nilsson andrn...@gmail.com:
 IPFIREWALL_DEFAULT_TO_ACCEPT, DEVICE_POLLING and HZ=1000.

HZ can be set via /boot/loader.conf, and I think via sysctl as well.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: zfs arc and amount of wired memory

[Freddie Cash]

On Wed, Feb 8, 2012 at 10:25 AM, Eugene M. Zheganin e...@norma.perm.ru wrote:
 On 08.02.2012 18:15, Alexander Leidinger wrote:
 I can't remember to have seen any mention of SWAP on ZFS being safe
 now. So if nobody can provide a reference to a place which tells that
 the problems with SWAP on ZFS are fixed:
  1. do not use SWAP on ZFS
  2. see 1.
  3. check if you see the same problem without SWAP on ZFS (btw. see 1.)

 So, if a swap have to be used, and, it has to be backed up with something
 like gmirror so it won't come down with one of the disks, there's no need to
 use zfs for system.

 This makes zfs only useful in cases where you need to store something on a
 couple+ of terabytes, still having OS on ufs. Occam's razor and so on.

Or, you plug a USB stick into the back (or even inside the case as a
lot of mobos have internal USB connectors now) and use that for swap.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: zfs arc and amount of wired memory

[Freddie Cash]

On Wed, Feb 8, 2012 at 10:40 AM, Freddie Cash fjwc...@gmail.com wrote:
 On Wed, Feb 8, 2012 at 10:25 AM, Eugene M. Zheganin e...@norma.perm.ru 
 wrote:
 On 08.02.2012 18:15, Alexander Leidinger wrote:
 I can't remember to have seen any mention of SWAP on ZFS being safe
 now. So if nobody can provide a reference to a place which tells that
 the problems with SWAP on ZFS are fixed:
  1. do not use SWAP on ZFS
  2. see 1.
  3. check if you see the same problem without SWAP on ZFS (btw. see 1.)

 So, if a swap have to be used, and, it has to be backed up with something
 like gmirror so it won't come down with one of the disks, there's no need to
 use zfs for system.

 This makes zfs only useful in cases where you need to store something on a
 couple+ of terabytes, still having OS on ufs. Occam's razor and so on.

 Or, you plug a USB stick into the back (or even inside the case as a
 lot of mobos have internal USB connectors now) and use that for swap.

That also works well for adding L2ARC (cache) to the ZFS pool as well.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: ZFS: i/o error - all block copies unavailable on large disk number machines

[Freddie Cash]

On Mon, Jan 23, 2012 at 11:21 AM, Steven Hartland
kill...@multiplay.co.uk wrote:
 Not something I've seem made clear, but quite possibly. Even with
 9 disks you could easily get this if the BIOS doesn't see all of
 said disks, be that initially or due to disks added to the machine.

 For reference the original install was done on a zpool with 6 disks
 in a raidz2 config but then 6 additional disks where added to expand
 capacity.

 It was only when the new kernel was installed that data required
 to boot was then written to disks in the seconds raidz2 which is
 inaccessible to the boot code even though in perfect working order
 on a booted system.

 So something to document, watch out for and potentially safe
 guard against?

 It maybe something specific to machines with legacy BIOS hence not
 an issue with Sun kit?

From what I've gathered on the zfs-discuss mailing list, Solaris only
supports rpool's (bootable pool) to use mirror vdevs, and only a
single vdev in the rpool.

FreeBSD is (AFAIK) the only ZFS implementation that supports booting
from a raidz vdev, and from a pool with multiple raidz vdevs.

IME, separating the bootable disks from the storage disks will always
save you time, effort, and grief in the long run.  :)  Whether that
means using a separate UFS / filesystem, or a mirrored set of disks
for /, or a separate ZFS pool with a single mirror vdev is up to the
admin.  But boot/OS should be separate from bulk storage.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system

[Freddie Cash]

On Mon, Jan 9, 2012 at 11:25 AM, Freddie Cash fjwc...@gmail.com wrote:
 I've upgraded the BIOS to v2.00 same as betadrive.  However, using the
 exact same BIOS settings as betadrive causes the SATA controllers and
 onboard igb(4) interfaces to not be detected.  At all.  Nothing in
 dmesg or pciconf.  Resetting BIOS settings to Failsafe settings
 shows the SATA controllers and onboard NICs.  Now the fun begins to
 figure out which setting in the BIOS is causing this.

Looks like the BIOS upgrade to v2.00a solved the stability issues with
FreeBSD 9.0.  The box has been up for over 24 hours now, finished a
backups run overnight, ran multiple concurrent find processes on the
ZFS pool, without any hiccups or issues.

There's still something wonky with this BIOS and FreeBSD 9.0 and the
older AOC-USAS-L8i SATA controllers, as I had to resort to the
Failsafe Settings.  Using the exact same BIOS settings as the other
box causes all PCIe devices to disappear.

Since the box is working correctly now, as far as we can see, we'll be
leaving it like this until the summer when we have more downtime
available for testing.

Thanks for listening everyone, and offering advice.  For now, we'll
consider this issue solved.  :)
-- 
Freddie Cash
fjwc...@gmail.com
___
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

Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system

[Freddie Cash]

Good morning,

Just wondering if anyone else has run into a similar issue.

We have a ZFS storage server that was running 8.2-STABLE (from around
beginning of Dec 2011) without any issues, that was upgraded to
9.0-RELEASE (to consolidate all the ZFS and networking fixes/updates
and bring it up to version parity with our other ZFS storage server
running 9.0) last Thursday.  The svn switch of the source tree, the
buildworld, the buildkernel, the installkernel, the reboot with the
new kernel, the installworld, the reboot into the new world, the
mergemaster processes all completed successfully.  About half-way
through the make delete-old process, the box locked up.  No messages
on the console, no log entries of any kind, everything just stopped.
Had to do a power-cycle.  And then everything went to hell.  :(

On reboot, the loader complained about not being able to determine
which disk it was booting from (even though the new loader had already
booted at least once), and gave strange messages about
panic/free/something or other (didn't write that error down).

I was able to boot using a 9.0 install CD, drop to a loader prompt,
unload the kernel/modules from CD, load the kernel/modules from the
harddrive, set currdev to the harddrive, and boot.  But no matter what
I did (gpart bootcode using pmbr/gptboot from CD or from HD; copy
loader from CD, copy /boot from CD), I could not get the loader on the
HD to load the kernel; always gave the same error message:  can't
determine which disk we're booting from.

After trying for 24 hours to make it work, I just re-installed off the
9.0-RELEASE CD.

Now, this box (alphadrive) will freeze after running for between 3 and
10 hours.  Even when left completely idle, it will lock up after about
3 hours.  :(

I have another system (betadrive) that's almost identical hardware
(chassis, backplane, SATA controllers are different, everything else
is the same) that went from 8.2-STABLE to 9.0-RC2 to 9.0-RC3 to
9.0-RELEASE without any issues.  I've tried copying /boot/loader.conf,
/etc/make.conf, /etc/src.conf, /etc/sysctl.conf, /etc/rc.conf from
betadrive to alphadrive, without any change in the freezing behaviour.

These are ZFS storage systems, with / (UFS) and swap on SSDs, with 16
or 24 SATA HDs in the pool (3x 5-disk raidz2 + spare and 4x 6-disk
raidz2 resp).  All of the ZFS settings are identical between the two
systems (pool name, pool properties, ZFS filesystems, ZFS properties
per filesystem).  Dedupe and compression (LZJB) are enabled on both
systems.

When alphadrive locks up, there are no entries made in any log files;
there are no log entries on the console; there are no entries in the
BIOS event log; there are no entries in the IPMI event log; the
CPU/case temps are below 40C (emergency shutoff is 75C) as shown via
IPMI; RAM usage is under 20 GB (24 GB per box) with the lowest being
under 2 GB used (I run top on the console so I can see the stats when
it locks up, and the time it locks up).  It just ... stops.

The system will even lock up when running in single-user mode, with
only / mounted (ZFS not loaded, zpool not imported).

Hardware (alphadrive):
  Chenbro 5U rackmount chassis with 24 hot-swap drive bays
  SuperMicro H8DGi-F motherboard
  AMD Opteron 2218 CPU (8-cores at 2.0 GHz)
  24 GB DDR3-SDRAM
  3x SuperMicro AOC-USAS-L8i SATA controllers (multi-lane break-out cables)
  8x Seagate 7200.12 1.5 TB SATA harddrives
 16x WD RE4 1.0 TB SATA harddrives
  1x Kingston 60 GB SSD (for /, swap, L2ARC)

Hardware (betadrive):
  SuperMicro 4U rackmount chassis with 16 hot-swap drive bays
  SuperMicro H8DGi-F motherboard
  AMD Opteron 2218 CPU (8-cores at 2.0 GHz)
  24 GB DDR3-SDRAM
  2x SuperMicro AOC-USAS2-L8i SATA controllers (multi-lane cables)
 16x WD RE4 2.0 TB SATA harddrives
  1x Kingston 60 GB SSD (for /, swap, L2ARC)

betadrive runs perfectly with FreeBSD 9.0-RELEASE.
alphadrive locks up with FreeBSD 9.0-RELEASE.

We're currently investigating hardware firmware revisions to see if
anything else is different between the two systems.

Has anyone experience anything similar?  Does anyone have any ideas on
what to look for?  Any suggestions on what to try next?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system

[Freddie Cash]

On Mon, Jan 9, 2012 at 9:50 AM, John Nielsen li...@jnielsen.net wrote:
 From what you've said I strongly suspect that you have some kind of hardware 
 issue. Dodgy RAM is my first guess, something cooling-related is my 2nd, and 
 PSU is my 3rd. It is a little suspicious that you only started having 
 problems after your upgrade but it could be coincidence or it could be 
 something about the new software tickling the hardware differently than the 
 old.

That's what we're leaning toward as well.  We're planning on doing a
BIOS upgrade (betadrive is running v2.00 and alphadrive is v1.00),
then a memtest86+ run, then check firmware on the SATA controllers.

If none of the above helps, we're thinking of swapping the CPUs
between the two systems to see if the problems stay with the box or
follow the CPU.

Thanks for the reply.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system

[Freddie Cash]

Small correction:  these are AMD Opteron 6218 CPUs, not 2218.

 Hardware (alphadrive):
  Chenbro 5U rackmount chassis with 24 hot-swap drive bays
  SuperMicro H8DGi-F motherboard
  AMD Opteron 6218 CPU (8-cores at 2.0 GHz)
  24 GB DDR3-SDRAM
  3x SuperMicro AOC-USAS-L8i SATA controllers (multi-lane break-out cables)
  8x Seagate 7200.12 1.5 TB SATA harddrives
  16x WD RE4 1.0 TB SATA harddrives
  1x Kingston 60 GB SSD (for /, swap, L2ARC)

 Hardware (betadrive):
  SuperMicro 4U rackmount chassis with 16 hot-swap drive bays
  SuperMicro H8DGi-F motherboard
  AMD Opteron 6218 CPU (8-cores at 2.0 GHz)
  24 GB DDR3-SDRAM
  2x SuperMicro AOC-USAS2-L8i SATA controllers (multi-lane cables)
  16x WD RE4 2.0 TB SATA harddrives
  1x Kingston 60 GB SSD (for /, swap, L2ARC)



-- 
Freddie Cash
fjwc...@gmail.com
___
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: Upgrade from 8.2-STABLE to 9.0-RELEASE wedges on SuperMicro H8DGiF-based system

[Freddie Cash]

2012/1/9 Daniel Kalchev dan...@digsys.bg:
 On Jan 9, 2012, at 8:03 PM, Freddie Cash wrote:

 Small correction:  these are AMD Opteron 6218 CPUs, not 2218.

 Hardware (alphadrive):
  Chenbro 5U rackmount chassis with 24 hot-swap drive bays
  SuperMicro H8DGi-F motherboard
  AMD Opteron 6218 CPU (8-cores at 2.0 GHz)

 You meant Opteron 6128 perhaps?

Yes, 6128.  Aren't typos fun?  :)

 This looks weird coincidence indeed and considering the comments so far I too 
 would question ACPI (BIOS revision, settings etc) and the possibility for 
 some hardware going bad.

I've upgraded the BIOS to v2.00 same as betadrive.  However, using the
exact same BIOS settings as betadrive causes the SATA controllers and
onboard igb(4) interfaces to not be detected.  At all.  Nothing in
dmesg or pciconf.  Resetting BIOS settings to Failsafe settings
shows the SATA controllers and onboard NICs.  Now the fun begins to
figure out which setting in the BIOS is causing this.

I'm starting to lean toward a hardware issue with either the CPU
(since most of the chipset is in the CPU nowadays) or the motherboard.

Have a few more tests to run to try and narrow things down.

 Is it possible that you might have touched any hardware just before the 
 upgrade? I had few cases an old system die on me when doing minor 
 cleaning etc just before an update…

We bumped the RAM from 8 GB to 24 GB mid-December, to better support
dedupe.  Was running fine with the extra RAM.  Other than that, the
hardware has not been touched since it was first installed. And it's
been sitting in the server room since July 2011.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Freddie Cash]

On Thu, Dec 15, 2011 at 9:58 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
 Am 12/15/11 14:51, schrieb Daniel Kalchev:

 On Dec 15, 2011, at 3:25 PM, Stefan Esser wrote:

 Am 15.12.2011 11:10, schrieb Michael Larabel:
 No, the same hardware was used for each OS.

 In terms of the software, the stock software stack for each OS was used.

 Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with
 journaling enabled) should be an obvious choice since it is more similar
 in concept to ext4 and since that is what most FreeBSD users will use
 with FreeBSD?


 Or perhaps, since it is server Linux distribution, use ZFS on Linux as 
 well. With identical tuning on both Linux and FreeBSD. Having the same FS 
 used by both OS will help make the comparison more sensible for FS I/O.

 Daniel___

 Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it
 is legitimate to compare ZFS and ext4. It would be much more competetive
 to compare Linux BTRFS and FreeBSD ZFS.

There is a separate kernel module for ZFS that can be installed,
giving you proper kernel-level support for ZFS on Linux.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: r228152: anyone got the None cipher working with base OpenSSH?

[Freddie Cash]

On Fri, Dec 2, 2011 at 3:32 PM, Jeremy Chadwick free...@jdc.parodius.comwrote:

 On Fri, Dec 02, 2011 at 02:57:48PM -0800, Freddie Cash wrote:
  Looking through the commit messages for stable/8 and stable/9 I noticed
  that the HPN patches were applied to OpenSSH in the base install.  And
  reading through the commit messages I see that one has to manually enable
  the None cipher.  However, I cannot, for the life of me, figure out how
 to
  do that.
 
  The commit message for r228152 says to put NONE_CIPHER_ENABLED=yes into
  /etc/make.conf.  But doing so still gives the following error when world
 is
  rebuilt/reinstalled:
  command-line: line 0: Bad configuration option: NoneEnabled
 
  Putting NONE_CIPHER_ENABLED=yes into /etc/src.conf and rebuilding world
  gives the same error.
 
  And, running make -DNONE_CIPHER_ENABLED all install under
  /usr/src/secure/usr.bin/ssh/ also gives the same error.
 
  What am I missing?  What's the magic incantation to add the None cipher
 to
  base ssh?

 I have been discussing this with bz@ and brooks@ privately.  I would
 rather not go into the details of what was discussed for reasons that I
 ALSO would rather not go into.  Just know that the ambiguity is
 intentional.

 Here is what will work for you when added to /etc/make.conf:

 .if ${.CURDIR:M/usr/src/secure/*}
  CFLAGS+=-DNONE_CIPHER_ENABLED
 .endif


For the archives, the above snippet in /etc/make.conf and a buildworld
cycle enabled the NONE cipher in /usr/bin/ssh.

I'll be sure to read commit messages more carefully in the future.  :)

Here's hoping that eventually/someday this gets converted into a src.conf
knob like WITH_IDEA or similar.

Thanks for all the help everyone.

-- 
Freddie Cash
fjwc...@gmail.com
___
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