On Tue, 27 Sep 2011, h h wrote:
Kevin Oberman writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to cho
Kevin Oberman writes:
> On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote:
>
>> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
>> expected, ports/ is going to be essentially unusable for a while.
>>
>> The issue stems from configure scripts (to choose something completel
On 27/09/2011, at 13:33, Ade Lovett wrote:
> That is to say, until 9.0-R happens, and for some considerable period
> afterwards, ya'll can pretty much expect ports/ to be non-functional on
> HEAD. PRs mentioning this will be gleefully closed referencing this
> message.
I imagine you can work aro
> It just means that folks didn't plan ahead and didn't think up
> proper contingency plans.
First off, apologies to Garrett, I'm not picking on you directly, but I
kinda knew this would come up.
The undeniable fact is that configure scripts in general have chosen to
do things a certain way. Un
On Mon, Sep 26, 2011 at 10:15 PM, Kevin Oberman wrote:
> On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper wrote:
>> It's not the FreeBSD dev's fault. Unfortunately the autotools folks
>> were microoptimizing and didn't consider that the future would come
>> sooner than it actually did.
>
> First,
On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper wrote:
> It's not the FreeBSD dev's fault. Unfortunately the autotools folks
> were microoptimizing and didn't consider that the future would come
> sooner than it actually did.
Garrett,
First, I'm not complaining or criticizing any of the develop
On Mon, Sep 26, 2011 at 9:56 PM, Kevin Oberman wrote:
> On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote:
>> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
>> expected, ports/ is going to be essentially unusable for a while.
>>
>> The issue stems from configure scripts (
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote:
> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
> expected, ports/ is going to be essentially unusable for a while.
>
> The issue stems from configure scripts (to choose something completely
> at random) assuming that Fre
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to choose something completely
at random) assuming that FreeBSD would never jump to a double-digit
major version number,
On 2011-07-16 13:55, Doug Barton wrote:
> Howdy,
>
> I wanted to let everyone know that BIND 9.8.0-P4 has just been imported
> to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has
> many nice new features vs. 9.6.x, especially in the area of DNSSEC. You
> can read more about the n
Howdy,
I wanted to let everyone know that BIND 9.8.0-P4 has just been imported
to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has
many nice new features vs. 9.6.x, especially in the area of DNSSEC. You
can read more about the new features in the README file included in
/usr/shar
>From: Rick Macklem
>
>Well, I doubt you'll find much difference performance wise. An NFS server can
>be looked as a protocol translator, converting the NFS RPCs into VFS/VOP
>calls. Performance is largely defined by how well the network stack and/or
>file system perform.
>
>When you set up a se
Chris Forgeron wrote:
[stuff snipped]
>
> I hope to do a speed test comparison between new and old NFS servers
> this weekend - At this stage, my feeling is that the new NFS server is
> at least as fast. I suspect tests will show it to be faster (at least
> the code looks faster. :-) ).
>
Well, I
On Sat, Jun 04, 2011 at 07:52:31AM -0400, Thomas Dickey wrote:
> On Sat, Jun 04, 2011 at 05:54:49AM +0400, Andrey Chernov wrote:
> > On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
> > > On a freshly installed -CURRENT, to view a colorized manpage in color
> > > and in full terminal
On Sat, Jun 04, 2011 at 05:54:49AM +0400, Andrey Chernov wrote:
> On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
> > On a freshly installed -CURRENT, to view a colorized manpage in color
> > and in full terminal width, try this:
> >
> > env MANCOLOR=yes MANWIDTH=tty man grotty
On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
> On a freshly installed -CURRENT, to view a colorized manpage in color
> and in full terminal width, try this:
>
> env MANCOLOR=yes MANWIDTH=tty man grotty
>
SGR presence can be easily autodetected analyzing termcap capibilit
BTW,
I've been pounding on the new NFS server with a few test VM's from my ESX
cluster for the last 2 weeks, 24/7. Everything looks solid, no panics, no
errors, no corruption. Memory usage is staying stable, so I haven't found any
leaks. I'm using IOMETER to move a few TB of randomized data a
Hi there,
On a freshly installed -CURRENT, to view a colorized manpage in color
and in full terminal width, try this:
env MANCOLOR=yes MANWIDTH=tty man grotty
Both features are disabled by default for POLA reasons. Bikeshedding
will be redirected to /dev/null.
Cheers,
--
Ruslan Ermil
Hi,
I just committed r221615 that changes the sysctl naming for
the new NFS server from vfs.newnfs to vfs.nfsd.
When you upgrade to a post-r221615 kernel, you will also need
a post-r221615 /etc/rc.d/nfsd shell script if you are using
an NFS server.
rick
__
Since r221543 moves nfs_kdtrace.h, you'll need to do a fresh
make cleandepend; make depend to update your kernel dependencies.
rick
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, sen
On 04/29/11 11:00, Boris Samorodov wrote:
On Wed, 27 Apr 2011 13:59:49 -0400 (EDT) Rick Macklem wrote:
Hopefully, you won't need to do anything to keep things working
and this won't cause you grief, rick
I've updated my tiny home network (host + two diskless clients).
No problems so far. Grea
On Wed, 27 Apr 2011 13:59:49 -0400 (EDT) Rick Macklem wrote:
> Hopefully, you won't need to do anything to keep things working
> and this won't cause you grief, rick
I've updated my tiny home network (host + two diskless clients).
No problems so far. Great work, thanks!
--
WBR, Boris Samorodov
> On Wed, Apr 27, 2011 at 07:39:17PM -0400, Rick Macklem wrote:
> > > Hi,
> > >
> > > Is there any impact on /usr/sbin/amd?
> > >
> > I'll admit I haven't tested it (I've never used the FreeBSD amd). I
> > will
> > do so once I figure out how to set it up, but I'm hoping others will
> > report
> >
On Tue, Apr 26, 2011 at 09:26:05AM -0400, John Baldwin wrote:
> Actually, I think we should switch GENERIC in HEAD to the new client and
> kernel very soon. The goal is to get current users testing the new client
> and
> server so they can uncover any bugs. If problems crop up during the testi
On Wed, Apr 27, 2011 at 07:39:17PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > Is there any impact on /usr/sbin/amd?
> >
> I'll admit I haven't tested it (I've never used the FreeBSD amd). I will
> do so once I figure out how to set it up, but I'm hoping others will report
> any problems. If you c
> On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote:
> > The commit r221124 switches the default NFS client to the new one in
> > head.
> > The fstype "newnfs" is now "nfs" and the regular/old NFS client is
> > now fstype "oldnfs". As such, "mount -t nfs ..." will use the new
> > client.
On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote:
> The commit r221124 switches the default NFS client to the new one in head.
> The fstype "newnfs" is now "nfs" and the regular/old NFS client is
> now fstype "oldnfs". As such, "mount -t nfs ..." will use the new client.
Hi,
Is there
The commit r221124 switches the default NFS client to the new one in head.
The fstype "newnfs" is now "nfs" and the regular/old NFS client is
now fstype "oldnfs". As such, "mount -t nfs ..." will use the new client.
Although most kernels will still work with the old mount(8) and
mount_nfs(8) binar
>
> Actually, I think we should switch GENERIC in HEAD to the new client
> and
> kernel very soon. The goal is to get current users testing the new
> client and
> server so they can uncover any bugs. If problems crop up during the
> testing
> that can't be resolved, we can always revert to the old
On 04/26/11 15:54, Rick Macklem wrote:
Since today's source (FreeBSD 9.0-CURRENT/amd64 (source is:
Revision:
221060) update I get the follwoing error while building the kernel
(options NFSD/options NFSCL instead of options NFSSERVER/options
NFSCLIENT):
cc -c -O2 -frename-registers -pipe -fno-str
> > Since today's source (FreeBSD 9.0-CURRENT/amd64 (source is:
> > Revision:
> > 221060) update I get the follwoing error while building the kernel
> > (options NFSD/options NFSCL instead of options NFSSERVER/options
> > NFSCLIENT):
> >
> > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing
>
On Sunday, April 24, 2011 3:12:13 pm Rick Macklem wrote:
> > On 04/24/11 02:00, Rick Macklem wrote:
> > > There will soon be a commit to head that will change the
> > > default NFS server to the new one that was called the
> > > experimental NFS server (but no longer experimental). After
> > > this
Hi,
I will be making a commit to head/sys that will change the .h file
dependencies for the experimental NFS client. You probably want to
do a fresh:
make cleandepend
make depend
when building a kernel after updating to r221014.
rick
___
freebsd-curren
> On 04/24/11 02:00, Rick Macklem wrote:
> > There will soon be a commit to head that will change the
> > default NFS server to the new one that was called the
> > experimental NFS server (but no longer experimental). After
> > this commit, you must use "-o" on both mountd and nfsd to
> > force the
On 04/24/11 02:00, Rick Macklem wrote:
There will soon be a commit to head that will change the
default NFS server to the new one that was called the
experimental NFS server (but no longer experimental). After
this commit, you must use "-o" on both mountd and nfsd to
force the system to use the o
There will soon be a commit to head that will change the
default NFS server to the new one that was called the
experimental NFS server (but no longer experimental). After
this commit, you must use "-o" on both mountd and nfsd to
force the system to use the old/regular server but, please,
try the ne
On 22 April 2011 15:20, Sevan / Venture37 wrote:
> On Friday, 22 April 2011, Adrian Chadd wrote:
>> Hm, I'll revert this change for now.
>>
>> Sorry!
>
> Could you post a diff of your reverted change, I currently have no
> connectivity to be able to update src.
or I could just pull the diff from
On Friday, 22 April 2011, Adrian Chadd wrote:
> Hm, I'll revert this change for now.
>
> Sorry!
Could you post a diff of your reverted change, I currently have no
connectivity to be able to update src.
Sevan
___
freebsd-current@freebsd.org mailing lis
Hm, I'll revert this change for now.
Sorry!
Adrian
On 21 April 2011 23:40, Sevan / Venture37 wrote:
> On 21 April 2011 06:19, Adrian Chadd wrote:
> > It's possible, but none of the current drivers in -head implement MIMO
> and
> > the data wasn't actually filled out in net80211, so it's hig
On 21 April 2011 06:19, Adrian Chadd wrote:
> It's possible, but none of the current drivers in -head implement MIMO and
> the data wasn't actually filled out in net80211, so it's highly unlikely it
> was being used.
The rt2860/70 driver was, attempting to compile the drive now results in
rt2860.
It's possible, but none of the current drivers in -head implement MIMO and
the data wasn't actually filled out in net80211, so it's highly unlikely it
was being used.
Adrian
On 21 April 2011 13:07, Arnaud Lacombe wrote:
> Hi,
>
> On Thu, Apr 21, 2011 at 12:21 AM, Adrian Chadd
> wrote:
> > Hi,
Hi,
On Thu, Apr 21, 2011 at 12:21 AM, Adrian Chadd wrote:
> Hi,
>
> If you're using wireless on -HEAD and using an older base w/ newer kernels,
> you may wish to recompile ifconfig.
> I've changed the binary ABI used for MIMO statistics (which nothing actually
> exports yet) but it may generate g
Hi,
If you're using wireless on -HEAD and using an older base w/ newer kernels,
you may wish to recompile ifconfig.
I've changed the binary ABI used for MIMO statistics (which nothing actually
exports yet) but it may generate garbage looking MIMO noise floor output (in
ifconfig X list station.)
If
--- On Mon, 4/18/11, Scott Long wrote:
...
> >
> > We do not have f2c in tree and it was disconnected
> from the build even
> > longer than that.
> >
>
> Guess I was looking on an old system, sorry for the noise.
>
> Scott
>
Ugh.. pointyhat is all mine please...
It's still linked in the
On Apr 18, 2011, at 9:47 AM, Alexander Kabaev wrote:
> On Mon, 18 Apr 2011 06:37:10 -0700 (PDT)
> "Pedro F. Giffuni" wrote:
>
>>
>> --- On Mon, 4/18/11, Scott Long wrote:
>> ...
Yeah it's too outdated to be of any use.
IMHO, you can axe libf2c too...
>>>
>>> Honest questi
On Mon, 18 Apr 2011 06:37:10 -0700 (PDT)
"Pedro F. Giffuni" wrote:
>
> --- On Mon, 4/18/11, Scott Long wrote:
> ...
> > > Yeah it's too outdated to be of any use.
> > >
> > > IMHO, you can axe libf2c too...
> > >
> >
> > Honest question here, is there a newer version of libf2c
> > that lives
--- On Mon, 4/18/11, Scott Long wrote:
...
> > Yeah it's too outdated to be of any use.
> >
> > IMHO, you can axe libf2c too...
> >
>
> Honest question here, is there a newer version of libf2c
> that lives in ports and is adopted by people who use
> fortran? The one that I find in the base sy
On Apr 17, 2011, at 12:33 PM, Pedro F. Giffuni wrote:
> Yeah it's too outdated to be of any use.
>
> IMHO, you can axe libf2c too...
>
Honest question here, is there a newer version of libf2c that lives in ports
and is adopted by people who use fortran? The one that I find in the base
system
Yeah it's too outdated to be of any use.
IMHO, you can axe libf2c too...
cheers,
Pedro.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...
I will be removing libobjc and other Objective-C related components
from the base system, as these are extremely outdated, and not used by
anything in the base system.
The previous thread about this (*) did not generate much discussion, but
if there are any objections, please speak up.
*) http:
Hi all,
I'd like to split the ath driver back up into some of its sub-components in
-HEAD before 9.0-RELEASE is done.
Those components are:
* ath (the BSD/net80211 facing interface itself)
* ath_hal (hardware layer)
* ath_rate_* (the rate control modules)
* ath_pci (the ath<->PCI glue)
Since I'
On Wed, 23 Mar 2011, Mattia Rossi wrote:
On 21/03/11 18:36, Jeff Roberson wrote:
[..]
I would not expect any instability in non ofed systems from this import.
Hi Jeff,
I've tried to compile netstat, and it bails out immediately if I try to make
obj:
"/usr/src/usr.bin/netstat/Makefile", l
On 21/03/11 18:36, Jeff Roberson wrote:
[..]
I would not expect any instability in non ofed systems from this import.
Hi Jeff,
I've tried to compile netstat, and it bails out immediately if I try to
make obj:
"/usr/src/usr.bin/netstat/Makefile", line 21: Malformed conditional
(${MK_OFED}
Hi Folks,
Just a notice that the 1.5.3 OFED Infiniband stack will be committed as
soon as a fresh buildworld/installworld completes on my test machine.
This brings in new drivers and user code and a very small number of
changes to system sources. OFED will not be built by default and
WITH_OF
On Mar 18, 2011, at 6:51 PM, Nathan Whitehorn wrote:
> On 03/15/11 12:20, Marcel Moolenaar wrote:
>> On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote:
>>
>>> I just committed (r219641) changes that make the release infrastructure
>>> (src/release/Makefile) use bsdinstall by default instead o
On 03/14/11 19:20, Dan Mack wrote:
On Mar 14, 2011, at 9:13 AM, Nathan Whitehorn wrote:
I just committed (r219641) changes that make the release infrastructure
(src/release/Makefile) use bsdinstall by default instead of sysinstall on
install media. A big thank you is in order to everyone who
On 03/14/11 12:07, Poul-Henning Kamp wrote:
In message<4d7e228a.4090...@freebsd.org>, Nathan Whitehorn writes:
I just committed (r219641) changes that make the release infrastructure
(src/release/Makefile) use bsdinstall by default instead of sysinstall
on install media. A big thank you is in o
On 03/15/11 12:20, Marcel Moolenaar wrote:
On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote:
I just committed (r219641) changes that make the release infrastructure
(src/release/Makefile) use bsdinstall by default instead of sysinstall on
install media. A big thank you is in order to every
On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote:
> I just committed (r219641) changes that make the release infrastructure
> (src/release/Makefile) use bsdinstall by default instead of sysinstall on
> install media. A big thank you is in order to everyone who provided advice,
> criticism,
On Mon, Mar 14, 2011 at 5:38 PM, Nathan Whitehorn
wrote:
> On 03/14/11 10:38, Giorgos Keramidas wrote:
>> Naturally, I volunteer to *make* the mdoc changes. As long as someone
>> (e.g. you Nathan?) who is acquainted with the new release building
>> Makefile can hepl me by reviewing the updates an
On Mar 14, 2011, at 9:13 AM, Nathan Whitehorn wrote:
> I just committed (r219641) changes that make the release infrastructure
> (src/release/Makefile) use bsdinstall by default instead of sysinstall on
> install media. A big thank you is in order to everyone who provided advice,
> criticism, a
In message <4d7e228a.4090...@freebsd.org>, Nathan Whitehorn writes:
>I just committed (r219641) changes that make the release infrastructure
>(src/release/Makefile) use bsdinstall by default instead of sysinstall
>on install media. A big thank you is in order to everyone who provided
>advice, c
On Monday, March 14, 2011 11:56:14 am Nathan Whitehorn wrote:
> On 03/14/11 10:44, John Baldwin wrote:
> > On Monday, March 14, 2011 10:13:30 am Nathan Whitehorn wrote:
> >> I just committed (r219641) changes that make the release infrastructure
> >> (src/release/Makefile) use bsdinstall by default
On 03/14/11 10:38, Giorgos Keramidas wrote:
On Mon, Mar 14, 2011 at 3:13 PM, Nathan Whitehorn
wrote:
Changes to release(7)
-
Release builds work and look slightly different now, so everyone who
snapshot tinderboxes will likely find them breaking shortly. The neares
On Mon, Mar 14, 2011 at 3:13 PM, Nathan Whitehorn
wrote:
> Changes to release(7)
> -
>
> Release builds work and look slightly different now, so everyone who
> snapshot tinderboxes will likely find them breaking shortly. The nearest
> analog to the old make release (wit
On 03/14/11 10:44, John Baldwin wrote:
On Monday, March 14, 2011 10:13:30 am Nathan Whitehorn wrote:
I just committed (r219641) changes that make the release infrastructure
(src/release/Makefile) use bsdinstall by default instead of sysinstall
on install media. A big thank you is in order to eve
On Monday, March 14, 2011 10:13:30 am Nathan Whitehorn wrote:
> I just committed (r219641) changes that make the release infrastructure
> (src/release/Makefile) use bsdinstall by default instead of sysinstall
> on install media. A big thank you is in order to everyone who provided
> advice, crit
I just committed (r219641) changes that make the release infrastructure
(src/release/Makefile) use bsdinstall by default instead of sysinstall
on install media. A big thank you is in order to everyone who provided
advice, criticism, and testing for this project over the last few months!
Along
Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 19:27:
> On 03/06/11 12:49, Edward Tomasz Napierała wrote:
>>
>> The above looks like old-style, "canonical six" trivial ACL. Now,
>> cp(1) shouldn't even try to copy the ACL in this case, since there
>> is nothing to copy. So, for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 12:49, Edward Tomasz Napierała wrote:
>
> The above looks like old-style, "canonical six" trivial ACL. Now,
> cp(1) shouldn't even try to copy the ACL in this case, since there
> is nothing to copy. So, for some reason, something failed
Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 15:43:
> On 03/06/11 08:35, Steve Wills wrote:
>> On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
>>> Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
>>
>>> [..]
>>
Thanks for your work on this, I'm very
On Sun, Mar 06, 2011 at 08:23:42AM -0800, Jeremy Chadwick wrote:
> On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:
> > On 03/06/11 10:37, Jeremy Chadwick wrote:
> > >
> > > At first glance it looks like acl_set_fd_np(3) isn't working on an
> > > md-backed filesystem; specifically, it'
On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:
> On 03/06/11 10:37, Jeremy Chadwick wrote:
> >
> > At first glance it looks like acl_set_fd_np(3) isn't working on an
> > md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
> > should be able to reproduce the problem by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 11:30, Jeremy Chadwick wrote:
> On Sun, Mar 06, 2011 at 08:23:42AM -0800, Jeremy Chadwick wrote:
>> On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:
>>
>> Sorry, I should have been more clear -- my investigation wasn't to
>> det
On 6 Mar 2011, at 16:30, Jeremy Chadwick wrote:
2. Are you absolutely 100% sure the kernel you're using was built
with "options UFS_ACL" defined in it? Doing a "strings -a
/boot/kernel/kernel | grep UFS_ACL" should suffice.
>>>
>>> Yep, it does:
>>>
>>> % strings -a /b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 10:37, Jeremy Chadwick wrote:
>
> At first glance it looks like acl_set_fd_np(3) isn't working on an
> md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
> should be able to reproduce the problem by doing a setfacl on some
On Sun, Mar 06, 2011 at 09:43:34AM -0500, Steve Wills wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/06/11 08:35, Steve Wills wrote:
> > On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
> >> Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
> >
> >> [..]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 08:35, Steve Wills wrote:
> On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
>> Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
>
>> [..]
>
>>> Thanks for your work on this, I'm very happy to have ZFS v28. I just
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 04:22, Edward Tomasz Napierała wrote:
> Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
>
> [..]
>
>> Thanks for your work on this, I'm very happy to have ZFS v28. I just
>> updated my -CURRENT system from a snapsho
Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
[..]
> Thanks for your work on this, I'm very happy to have ZFS v28. I just
> updated my -CURRENT system from a snapshot from about a month ago to
> code from today. I have 3 pools and one of them is for ports tinderbox.
> I o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Pawel,
On 02/27/11 15:29, Pawel Jakub Dawidek wrote:
> Hi.
>
> I just committed ZFSv28 to HEAD.
>
> New major features:
>
> - Data deduplication.
> - Triple parity RAIDZ (RAIDZ3).
> - zfs diff.
> - zpool split.
> - Snapshot holds.
> - zpool impo
28.02.2011 15:24, lhmwzy wrote:
Tks for PJD's work for zfs.
Would V28 is the last version of zfs because oracle don't open the zfs
code after V28?
1. Oracle opens the code, but only after some time. AFAIR they do open
the code after the major releases.
2. All head developers have quit Oracle.
Alexander Leidinger wrote:
> Quoting Fabian Keil (from Thu, 3 Mar
> 2011 13:01:30 +0100):
>
> > Alexander Leidinger wrote:
> >
> >> On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil
> >> wrote:
> >>
> >> > Pawel Jakub Dawidek wrote:
> >> >
> >> > > I just committed ZFSv28 to HEAD.
> >> >
> >>
On Thu, 3 Mar 2011, Fabian Keil wrote:
When you add the tuning back, does it take minutes again to boot? If
not, I assume it was cleaning up some leftovers the old version was not
able to cleanup.
I haven't tried that yet, but as I didn't upgrade the system's
storage pool I don't think ZFS is
Quoting Fabian Keil (from Thu, 3 Mar
2011 13:01:30 +0100):
Alexander Leidinger wrote:
On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil
wrote:
> Pawel Jakub Dawidek wrote:
>
> > I just committed ZFSv28 to HEAD.
>
> I updated the system without removing the tuning for ZFSv15
> first, and so
Alexander Leidinger wrote:
> On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil
> wrote:
>
> > Pawel Jakub Dawidek wrote:
> >
> > > I just committed ZFSv28 to HEAD.
> >
> > I updated the system without removing the tuning for ZFSv15
> > first, and somehow this completely messed up the performanc
On Mon, Feb 28, 2011 at 08:34:08AM +0100, Martin Sugioarto wrote:
> > PS. If you like my work, you help me to promote yomoli.com:)
> >
> > http://yomoli.com
> > http://www.facebook.com/pages/Yomolicom/178311095544155
> >
>
> I would like, but you should at least tell me what it is (what
On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil
wrote:
> Pawel Jakub Dawidek wrote:
>
> > I just committed ZFSv28 to HEAD.
>
> I updated the system without removing the tuning for ZFSv15
> first, and somehow this completely messed up the performance.
> Booting the system took more than ten minu
Pawel Jakub Dawidek wrote:
> I just committed ZFSv28 to HEAD.
I updated the system without removing the tuning for ZFSv15
first, and somehow this completely messed up the performance.
Booting the system took more than ten minutes and even once
it was up it was next to unresponsive.
I'm not sure
Tks for PJD's work for zfs.
Would V28 is the last version of zfs because oracle don't open the zfs
code after V28?
2011/2/28 Pawel Jakub Dawidek :
> Hi.
>
> I just committed ZFSv28 to HEAD.
>
> New major features:
>
> - Data deduplication.
> - Triple parity RAIDZ (RAIDZ3).
> - zfs diff.
> - zpool
On 28 February 2011 08:47, Pawel Jakub Dawidek wrote:
> On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote:
>> I'm so excited for your work. Thanks so much for bringing zpool v28 to
>> FreeBSD. Will v28 come to 8-stable?
>
> Yes, hopefully in 1-2 month(s).
>
> --
> Pawel Jakub Dawidek
On Sun, Feb 27, 2011 at 09:29:57PM +0100, Pawel Jakub Dawidek wrote:
> I just committed ZFSv28 to HEAD.
Thank you so much for this effort! I look forward to trying this once
it's MFC'd to RELENG_8 in the upcoming future.
--
| Jeremy Chadwick j...@parodius.com |
On Mon, Feb 28, 2011 at 10:37:25AM +, krad wrote:
> On 28 February 2011 08:47, Pawel Jakub Dawidek wrote:
> > On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote:
> >> I'm so excited for your work. Thanks so much for bringing zpool v28 to
> >> FreeBSD. Will v28 come to 8-stable?
> >
> >
On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote:
> I'm so excited for your work. Thanks so much for bringing zpool v28 to
> FreeBSD. Will v28 come to 8-stable?
Yes, hopefully in 1-2 month(s).
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer
Am Sun, 27 Feb 2011 21:29:57 +0100
schrieb Pawel Jakub Dawidek :
> Hi.
>
> I just committed ZFSv28 to HEAD.
>
> New major features:
>
> - Data deduplication.
> - Triple parity RAIDZ (RAIDZ3).
> - zfs diff.
> - zpool split.
> - Snapshot holds.
> - zpool import -F. Allows to rewind corrupted pool
On
Behalf Of Pawel Jakub Dawidek
Sent: Sunday, February 27, 2011 4:30 PM
To: freebsd...@freebsd.org
Cc: freebsd-current@FreeBSD.org
Subject: HEADS UP: ZFSv28 is in!
Hi.
I just committed ZFSv28 to HEAD.
New major features:
- Data deduplication.
- Triple parity RAIDZ (RAIDZ3).
- zfs diff.
- zpo
I'm so excited for your work. Thanks so much for bringing zpool v28 to
FreeBSD. Will v28 come to 8-stable?
Thanks,
Shawn
On Feb 27, 2011 1:56 PM, "Pawel Jakub Dawidek" wrote:
> Hi.
>
> I just committed ZFSv28 to HEAD.
>
> New major features:
>
> - Data deduplication.
> - Triple parity RAIDZ (RAI
Hi.
I just committed ZFSv28 to HEAD.
New major features:
- Data deduplication.
- Triple parity RAIDZ (RAIDZ3).
- zfs diff.
- zpool split.
- Snapshot holds.
- zpool import -F. Allows to rewind corrupted pool to earlier
transaction group.
- Possibility to import pool in read-only mode.
PS. If y
This weekend I updated our copy of llvm/clang again, from trunk r126079
to trunk r126547.
There are several bugfixes in this update, but the most important one is
to ensure __start_ and __stop_ symbols for linker sets and kernel module
metadata are always emitted in object files.
Before this fix
On 2011-02-19 15:35, Dimitry Andric wrote:
Okay, binutils 2.17.50 has now been merged to head in r218822. If you
compile kernels by hand, make sure to first run "make buildworld", or at
least "make kernel-toolchain", to get a new ld in /usr/obj. Otherwise,
linking your kernel might fail.
Note
801 - 900 of 3193 matches
Mail list logo
