zfs snapshot_limit is not respected

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. #

net.inet.udp.log_in_vain strange syslog reports

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)

Re: kernel installation problem on STABLE-11

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

vt(4) gibberish characters in 11.0 with nvidia

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

Re: kernel installation problem on STABLE-11

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

kernel installation problem on STABLE-11

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

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

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

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

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: