Is this making it TRIM aware globally -- even on your cache and log
devices?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler
i...@protected-networks.net wrote:
- From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp)
that Steve Kargl referenced (dated July 2012).
I don't know where this guy is getting his info, but CLANG is /more/
standards
Clang produces incorrect code vs Clang's floating point has issues are two
different arguments.
For a mathematical application it would be stupid to use clang if this is the
case. I see no problem with it being the default compiler though. If Atlas is
in ports the maintainer can just force it
Thank you for taking time to explain the situation. I don't follow as closely
as many on the current list do (and not subbed to toolchain).
I'm sure the libm situation is on many people's radar now. Hopefully this can
be resolved.
My apologies for being so daft :-)
On Thu, 28 Jun 2012 14:49:02 -0500, Alexander Leidinger
alexan...@leidinger.net wrote:
What about multipathing? In case the disk is attached via two paths but
multipath is not enabled, the OS sees the same disk (and the same
identical unique disk identifier) multiple times. Is this a
On Thu, 07 Jun 2012 08:09:06 -0500, Vitaly Magerya vmage...@gmail.com
wrote:
Will it be possible to provide, say pkgng repo with packages compiled
with new xorg and new mesa? That would simplify testing (and using) by a
very large factor. We'd just change PACKAGESITE and run pkg upgrade.
Check man adduser.conf(5)
There is an option for uidstart which should do what you want. If you
set it to 1000 every time you run adduser it will show:
# adduser
Username: foo
Full name: bar
Uid [1000]:
Don't worry -- it's just showing you the starting range. If there is
already a UID of
On Thu, 17 May 2012 13:41:19 -0500, Joel Dahl j...@vnode.se wrote:
Thanks, setting uidstart to 1000 indeed works around the problem. :)
However, I would still like to know if this is intended behaviour.
I'm not sure but hopefully someone here can answer that for you.
Would it be appropriate to perhaps have a port option to OVERWRITE_BASE
and then people could just install that port, build world and kernel...
build a ton of ports. See if anything that might possibly use it breaks?
___
freebsd-current@freebsd.org
On Wed, 14 Mar 2012 20:26:23 -0500, Adrian Chadd adr...@freebsd.org
wrote:
I must be thinking of our mailer trick then?
I know i've seen it somewhere before.
Alternatives sounds fun though?
I've seen several discussions on the bsd lists with everyone against the
debian alternatives
I think I may have jumped the gun on this guys -- I'm seeing this behavior
again. I've got a few more tests in mind now that I need to perform before
I can really nail down what's going on.
___
freebsd-current@freebsd.org mailing list
Hi all,
Previous kernel I was running on a test SAN was 9-STABLE from Jan 24th.
Sorry, no commit # -- didn't have svn on the machine back then.
Today I built r231282 because it had an interesting fix in it:
r231141 | mm | 2012-02-07 11:57:33 -0600 (Tue, 07 Feb 2012) | 25 lines
MFC r230514:
Hi all,
Just wanted to report back that I found time to do more diagnostics.
ZFS/FreeBSD/etc are not to blame. ZFS / FreeBSD never reported any I/O
errors and scrubs always came up clean because one of the disks was
failing and had issues reading the disk but would eventually return
accurate
After many hours of testing, reproducing, and testing again I've
finally been able to narrow down what the real issue is and it's not ZFS
as I suspected. After completely turning off all NFS functionality and
serving my files over Samba I haven't had a single issue. It seems there
is something
It appears that I'm mistaken about those messages then . However this does both
happen on my AMD x6 and Intel Atom machines with different hard drives,
controllers, etc. I feel it would be unlikely to be hardware.
Unfortunately the procstat command is probably of no use because I can't
13:14:32 nas:~ uname -a
FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M:
Fri Nov 25 10:07:48 CST 2011
r...@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64
This seemed to start happening sometime after RC1. I tried 8-STABLE and
it's happening there too right now. I
On 25.11.2011 13:39, Freddie Cash wrote:
There's a lot of uma_* stuff in there. Just curious, what's the
following
sysctl set to:
vfs.zfs.zio.use_uma
Back in the 8.x days, it was recommended to set it to 0 due to bugs:
I saw identical behavior a very long time ago but didn't have time to
reproduce and report. It was very confusing.
Regards,
Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
On Tue, 16 Aug 2011 12:29:47 -0500, Edwin L. Culp W.
edwinlc...@gmail.com wrote:
Worked perfectly. Maybe it would be a good idea to put the step by
step solution for other folks like me who haven't put enough effort
to understand the 20110815: entry.
These steps are detailed in the
On Mon, 15 Aug 2011 08:13:48 -0500, Andriy Gapon a...@freebsd.org wrote:
I guess that the root cause of your trouble is the GEOM_PART integrity
check
failing (see the messages in IMG_1312.JPG).
You should investigate and fix that.
Meanwhile you may want to set the
Here's a followup with some pics I was able to take. Sorry about the
quality :-(
http://feld.me/stuff/freebsd/geom_mirror_9/
Cheers,
Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
Hi all,
I was originally running 8.2 on my NAS at home -- later 8-STABLE for ZFS
-- and decided to see how 9.0-BETA1 fairs on it due to seeing some changes
coming in 9.0 that would be favorable. After installing the kernel and
trying to reboot into it I discovered it doesn't like my
101 - 122 of 122 matches
Mail list logo
