[Bug 207940] [patch] sys/boot/efi/boot1 select boot partition

2016-03-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940

--- Comment #8 from Tomoaki AOKI  ---
(In reply to Naomichi Nonaka from comment #6)

Tried, and working as expected for me.

ThinkPad T420 with 2 drives (second one is in UltraBay adapter),
each drive have one UFS partition and one ZFS pool.

The default matches current in-tree boot1.efi, either booted from internal
first drive or second drive in UltraBay.

 *Means that if I select first drive with UEFI firmware, ZFS pool in
  first drive is auto-selected, and that if I select second drive,
  ZFS pool in second drive is auto-selected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

[Bug 208071] AutoFS seems to disturb NFS server

2016-03-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208071

Rick Macklem  changed:

   What|Removed |Added

 CC||rmack...@freebsd.org

--- Comment #5 from Rick Macklem  ---
Every time you mount(8) any file system on the NFS server, mountd reloads
the /etc/exports. This has two effects:
1 - Unless you are running mountd with the "-S" option, the file systems
will become unexported for a short period of time during the reload.
2 - If the new file system is mounted on top of the exported file system,
mountd will try to export that new file system.
--> NFS mounts can never be exported, so if the new file system is
an NFS client mount, the export will no longer work. (This has
been the case since 1985 and is in part the case because you
can't safely put a file handle inside a file handle.)

To fix #1, add "-S" to mountd_flags.
#2 just won't work and needs to be avoided. You can look at
/var/log/messages for entries related to export problems generated
by mountd.

I don't know amd-utils or autofs, but it may be that one of them uses
mount(8) and the other does not. FreeBSD's mount(8) always sends a
SIGHUP to mountd, which makes it reload /etc/exports.

Basically #1 and #2 only occurs because mountd reloads /etc/exports
and that happens when mountd receives a SIGHUP. It may be that amd-utils
doesn't send a SIGHUP to mountd?)

rick

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

[Bug 207701] vlan interface over failover lagg has empty/00:00:00:00:00:00 mac/ether address

2016-03-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207701

Pushkar Kothavade  changed:

   What|Removed |Added

 CC||pushka...@gmail.com

--- Comment #2 from Pushkar Kothavade  ---
Hi Team, 

After going through the issue specified here, I investigated this issue on
FreeBSD 10 stable, Freebsd 10.2 release and FreeBSD HOL platforms by creating
lagg and vlan interfaces.

After investigation, problem statement is as follows:

*
*** Problem Statement ***
*

After machine boots up, when we create a vlan on Lagg interface, vlan interface
takes the same MAC address as that of lagg interface. This works fine as
expected.  Now going further, when we add/delete members of lagg bundle, 
MAC address of the lagg bundle changes as expected. It is expected that vlan
MAC should also get changed, when MAC of lagg interface changes, but it is not
happening. 

This issue is present in only 10 stable. It is not present in HOL and 10.2
release. 


*
 Fix 
*

https://reviews.freebsd.org/differential/diff/14418/


*
* Test Plan *
*


 Before Fix 


[Step-0] uname -a

** Output **

FreeBSD Host-XXX 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #2 r294978M: Thu Jan
28 16:46:33 IST 2016 amd64

[Step-1] ifconfig lagg1 create

[Step-2] ifconfig lagg1 laggproto failover laggport le1 laggport le2

[Step-3] ifconfig vlan1 create

[Step-4] ifconfig vlan1 vlan 1 vlandev lagg1

[Step-5] ifconfig

** Output **

lagg1: flags=8802 metric 0 mtu 1500
options=8
ether 00:0c:29:5b:6a:04
nd6 options=29
media: Ethernet autoselect
status: no carrier
laggproto failover lagghash l2,l3,l4
laggport: le1 flags=1
laggport: le2 flags=0<>

vlan1: flags=8842 metric 0 mtu 1500
ether 00:0c:29:5b:6a:04
nd6 options=29
media: Ethernet autoselect
status: no carrier
vlan: 1 parent interface: lagg1

[Step-6] ifconfig lagg1 -laggport le1

[Step-7] ifconfig

** Output **

lagg1: flags=8802 metric 0 mtu 1500
options=8
ether 00:0c:29:5b:6a:0e
nd6 options=29
media: Ethernet autoselect
status: no carrier
laggproto failover lagghash l2,l3,l4
laggport: le2 flags=1

vlan1: flags=8842 metric 0 mtu 1500
ether 00:0c:29:5b:6a:04
nd6 options=29
media: Ethernet autoselect
status: no carrier
vlan: 1 parent interface: lagg1

** Conclusion  **

vlan1 MAC does not change, when Lagg1 MAC changes. 

###
 After Fix 
###

[Step-0] uname -a

** Output **

FreeBSD Host-XXX 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #6 r296988: Fri Mar 18
08:30:25 IST 2016 amd64

[Step-1] ifconfig lagg1 create

[Step-2] ifconfig lagg1 laggproto failover laggport le1 laggport le2

[Step-3] ifconfig vlan1 create

[Step-4] ifconfig vlan1 vlan 1 vlandev lagg1

[Step-5] ifconfig

** Output **

lagg1: flags=8802 metric 0 mtu 1500
options=8
ether 00:0c:29:5b:6a:04
nd6 options=29
media: Ethernet autoselect
status: no carrier
laggproto failover lagghash l2,l3,l4
laggport: le1 flags=1
laggport: le2 flags=0<>

vlan1: flags=8842 metric 0 mtu 1500
ether 00:0c:29:5b:6a:04
nd6 options=29
media: Ethernet autoselect
status: no carrier
vlan: 1 parent interface: lagg1

[Step-6] ifconfig lagg1 -laggport le1

[Step-7] ifconfig

** Output **

lagg1: flags=8802 metric 0 mtu 1500
options=8
ether 00:0c:29:5b:6a:0e
nd6 options=29
media: Ethernet autoselect
status: no carrier
laggproto failover lagghash l2,l3,l4
laggport: le2 flags=1

vlan1: flags=8842 metric 0 mtu 1500
ether 00:0c:29:5b:6a:0e
nd6 options=29
media: Ethernet autoselect
status: no carrier
vlan: 1 parent interface: lagg1

** Conclusion  **

vlan1 MAC changes, when Lagg1 MAC changes. 

Thanks,
Pushkar Kothavade

-- 
You are receiving this mail because:
You are on the CC list for the

[Bug 208130] smbfs is slow because it (apparently) doesn't do any caching/buffering

2016-03-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208130

Bug ID: 208130
   Summary: smbfs is slow because it (apparently) doesn't do any
caching/buffering
   Product: Base System
   Version: 10.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-b...@freebsd.org
  Reporter: noah.bergba...@tum.de
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@FreeBSD.org

I set up an smbfs mount on FreeBSD 10.2-RELEASE today and was noticed that it's
very slow. How slow? Some numbers: Reading a 600MB file from the share with dd
reports around 1 MB/s while doing the same in a Linux VM running inside bhyve
on this very same machine yields a whopping 100 MB/s. I conclude that the SMB
server is irrelevant in this case.

There's a recent
[discussion](https://lists.freebsd.org/pipermail/freebsd-hackers/2015-November/048597.html)
about this on freebsd-hackers which reveals an interesting detail: The
situation can be improved massivley up to around 60MB/s on the FreeBSD side
just by using a larger dd buffer size (e.g. 1MB). Interestingly, using very
small buffers has only negligible impact on Linux (until the whole affair gets
CPU-bottlenecked of course).

I know little about SMB but a quick network traffic analysis gives some
insights: FreeBSD's smbfs seems to translate every read() call from dd directly
into an SMB request. So with a small buffer size of e.g. 1k, something like
this seems to happen:

* client requests 1k of data
* client waits for a response (network round-trip)
* client receives response
* client hands data to dd which then issues another read()
* client requests 1k of data
* ...

Note how we're spending most of our time waiting for network round-trips.
Because a bigger buffer means larger SMB requests, this obviously leads to
higher network saturation and less wasted time.

I'm unable to spot a similar pattern on Linux. Here, a steady flow of data is
maintained even with small buffer sizes, so apparently some caching/buffering
must be happening. Linux's cifs has a "cache" option and indeed, disabling it
produces exactly the same performance (and network) behavior I'm seeing on
FreeBSD.


So to sum things up: The fact that smbfs doesn't have anything like Linux's
cache causes a 100-fold performance hit. Obviously, that's a problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"