zfs snapshot_limit is not respected

[Ultima]

I recently moved some data on a box with limited space. I decided I should
limit the snapshots so that space would not become an issue. I just check
back a week later to find out the box is hitting the borderline. Doing I
quick check I realized that the snapshot_limit is not being respected.

# uname -a
FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10
EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL
 amd64

# zfs create zroot/bhyve/test
# zfs set snapshot_limit=0 zroot/bhyve/test
# zfs snapshot zroot/bhyve/test@1


# zfs snapshot zroot/bhyve/test@2
# zfs snapshot zroot/bhyve/test@3
# zfs list -t snapshot | grep zroot/bhyve/test
zroot/bhyve/test@1   0  -
 88K  -
zroot/bhyve/test@2   0  -
 88K  -
zroot/bhyve/test@3   0  -
 88K  -
# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit0  local
zroot/bhyve/test  snapshot_count3  local

Also wanted to verify 0 was not being mistaken for none.

# for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
'{print $1}'`; do zfs destroy $snapshot ; done

# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit0  local
zroot/bhyve/test  snapshot_count0  local

# zfs set snapshot_limit=1 zroot/bhyve/test
# zfs snapshot zroot/bhyve/test@1
# zfs snapshot zroot/bhyve/test@2
# zfs snapshot zroot/bhyve/test@3
# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit1  local
zroot/bhyve/test  snapshot_count3  local


Also tested on head
FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
12:38:52 EST 2017
root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
 amd64
___
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"

net.inet.udp.log_in_vain strange syslog reports

[Mark Martinec]

11.0-RELEASE-p7, net.inet.udp.log_in_vain=1

The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).

(the actual failed connection attempts were indeed there,
it's just that the reported IP address is highly suspicious)

  Mark


Connection attempt to UDP 193.2.4.2:53 from 95.87.1521242:26375
Connection attempt to UDP 193.2.4.2:53 from 95.87.1521242:55806
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:54530
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:55504
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:54530
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:49526
Connection attempt to UDP 193.2.4.2:53 from 95.8231520242:56838
Connection attempt to UDP 193.2.4.2:53 from 95.8231520242:32768
Connection attempt to UDP 193.2.4.2:53 from 95.8241523242:5387
Connection attempt to UDP 193.2.4.2:53 from 95.8241523242:54530
Connection attempt to UDP 193.2.4.2:53 from 21.823154.242:46692
Connection attempt to UDP 193.2.4.2:53 from 21.823154.242:32768
Connection attempt to UDP 193.2.4.2:53 from 19387.154.242:51931
Connection attempt to UDP 193.2.4.2:53 from 19387.154.242:59881
Connection attempt to UDP 193.2.4.2:53 from 212873154.242:53424
Connection attempt to UDP 193.2.4.2:53 from 212873154.242:53937
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:46692
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:52594
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:59639
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:50869
Connection attempt to UDP 193.2.4.2:53 from 19382.1587242:55806
Connection attempt to UDP 193.2.4.2:53 from 19382.1587242:54650
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:54322
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:49871
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:57807
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:51931
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:52930
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:50869
Connection attempt to UDP 193.2.4.2:53 from 212823152.242:56838
Connection attempt to UDP 193.2.4.2:53 from 212823152.242:32768
Connection attempt to UDP 193.2.4.2:53 from 21.8231521242:63724
Connection attempt to UDP 193.2.4.2:53 from 21.8231521242:55222
Connection attempt to UDP 193.2.4.2:53 from 1948249.230.46:52599
Connection attempt to UDP 193.2.4.2:53 from 1948249.230.46:38496
Connection attempt to UDP 193.2.4.2:53 from 2128235.209.250:43608
Connection attempt to UDP 193.2.4.2:53 from 2128235.209.250:47257
Connection attempt to UDP 193.2.4.2:53 from 19387.1594242:54324
Connection attempt to UDP 193.2.4.2:53 from 19387.1594242:34613
Connection attempt to UDP 193.2.4.2:53 from 2128235.2124180:54377
Connection attempt to UDP 193.2.4.2:53 from 2128235.2124180:50869
Connection attempt to UDP 193.2.4.2:53 from 95.87.1547242:51698
Connection attempt to UDP 193.2.4.2:53 from 95.87.1547242:55222
Connection attempt to UDP 193.2.4.2:53 from 193.2.4.2242:55222
Connection attempt to UDP 193.2.4.2:53 from 19.8241523242:38496
Connection attempt to UDP 193.2.4.2:53 from 19.8241523242:55135
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:50370
Connection attempt to UDP 193.2.4.2:53 from 95.824154.242:64533
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:55222
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:56228
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:53424
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:61230
Connection attempt to UDP 193.2.4.2:53 from 212823154.242:59716
Connection attempt to UDP 193.2.4.2:53 from 212823154.242:53424
Connection attempt to UDP 193.2.4.2:53 from 19387.154.242:36439
Connection attempt to UDP 193.2.4.2:53 from 19387.154.242:60638
Connection attempt to UDP 193.2.4.2:53 from 19387.1521242:59008
Connection attempt to UDP 193.2.4.2:53 from 19387.1521242:35505
Connection attempt to UDP 193.2.4.2:53 from 19.824154.242:54322
Connection attempt to UDP 193.2.4.2:53 from 19.824154.242:30943
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:51752
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:35165
Connection attempt to UDP 193.2.4.2:53 from 95.87.1587242:36439
Connection attempt to UDP 193.2.4.2:53 from 95.87.1587242:57311
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:36439
Connection attempt to UDP 193.2.4.2:53 from 19387.1587242:59280
Connection attempt to UDP 193.2.4.2:53 from 19487.154.242:53424
Connection attempt to UDP 193.2.4.2:53 from 19487.154.242:53247
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:35165
Connection attempt to UDP 193.2.4.2:53 from 95.823154.242:50473
Connection attempt to UDP 193.2.4.2:53 from 21287.154.242:56838
Connection attempt to UDP 193.2.4.2:53 from 21287.154.242:63658
Connection attempt to UDP 193.2.4.2:53 from 21287.154.242:54322
Connection attempt to UDP 193.2.4.2:53 from 21287.154.242:60637

Re: kernel installation problem on STABLE-11

[Jonathan Chen]

On 3 February 2017 at 06:21, Sergey Matveychuk  wrote:
> And it looks like it works without COMPILER_TYPE=clang if you buildworld
> before. But I'm not sure.

/usr/src/UPDATING recommends that buildworld should always be done
before buildkernel.

Cheers.
-- 
Jonathan Chen 
___
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"

vt(4) gibberish characters in 11.0 with nvidia

[Mark Martinec]

I have recently upgraded two hosts with identical nvidia boards (GeForce 
GT 730,
fresh driver nvidia-driver-375.26 from ports), one has been following 
11-STABLE
every now and then, the other was on 10.3. So they are now at 
11.0-RELEASE-p7

or on a recent 11-STABLE respectively.

The problem now showing on both hosts is that a virtual terminal console 
driver

(vt(4), no special settings) now shows gibberish character-cells in an
approx 90x24 raster. Character cells are of varying colors, some 
textured,

so it looks as if the font loaded was just random junk.

The boot screen sequence looks fine up to the moment when the X starts.
The X11 screen (with KDE) is fine too. It's just the ttyv0-ttyv7 
consoles

which are broken.

Solved my immediate problem by adding hw.vga.textmode=1 to 
/boot/loader.conf,
so that ttyv consoles now look fine (in fact much nicer, as the vt fonts 
are

pretty squashed and ugly to my eyes).

What puzzles me is what has changed recently, as both hosts were happily
using vt consoles in graphical mode until the upgrade.

(btw, I do have nvidia-modeset.ko and nvidia.ko loaded)

  Mark
___
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: kernel installation problem on STABLE-11

[David Wolfskill]

On Thu, Feb 02, 2017 at 08:21:29PM +0300, Sergey Matveychuk wrote:
> Hi.
> 
> On FreeBSD 11.0 kernel installation procedure is broken. It does not 
> work without COMPILER_TYPE=clang:

That state ment appears to be ... overly broad.  I've been doing daily
builld/installs of stable/11 on my laptop & a build machine; for me:

g1-252(11.0-S)[1] egrep -i 'clang|cc|compile' /etc/src* /etc/make.conf
g1-252(11.0-S)[2] echo $?
1
g1-252(11.0-S)[3]

> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to 
> determine compiler type for CC=cc .  Consider setting COMPILER_TYPE.
> 
> Command 'make installworld COMPILER_TYPE=clang KERNCONF=MYKERNERL' works 
> fine.
> 
> And it looks like it works without COMPILER_TYPE=clang if you buildworld 
> before. But I'm not sure.

Oh -- well, I always buildworld before buildkernel before installkernel,
of course.

>  

Links to pages showing what builds worked for me are at
.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

kernel installation problem on STABLE-11

[Sergey Matveychuk]

Hi.

On FreeBSD 11.0 kernel installation procedure is broken. It does not 
work without COMPILER_TYPE=clang:


make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to 
determine compiler type for CC=cc .  Consider setting COMPILER_TYPE.


Command 'make installworld COMPILER_TYPE=clang KERNCONF=MYKERNERL' works 
fine.


And it looks like it works without COMPILER_TYPE=clang if you buildworld 
before. But I'm not sure.

___
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.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

[Jakub Lach]

I just now successfully copied 38G (second data set) to the same HDD
via USB (after it has passed extended SMART), both with UFS2 and FAT32 
fs (6 CAM write errors in the second case, but as far as I can see, data 
is ok). I think I hit something unrelated above, and as I've said, cannot 
replicate first issue I had.



--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/FreeBSD-11-0-STABLE-0-r310265-amd64-seems-to-be-cpi-ing-garbage-to-mounted-FAT32-fs-after-10-20-GB-tp6154963p6164918.html
Sent from the freebsd-stable mailing list archive at Nabble.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: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

[Jakub Lach]

To sum up, looks like I cannot replicate original problem (corruption) 
with the USB dual card reader any more, and the HDD via USB thing is 
something different (maybe hardware related as it's exactly the same
with UFS/FAT).



--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/FreeBSD-11-0-STABLE-0-r310265-amd64-seems-to-be-cpi-ing-garbage-to-mounted-FAT32-fs-after-10-20-GB-tp6154963p6164851.html
Sent from the freebsd-stable mailing list archive at Nabble.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"