Hello,
1.
I normally copy btrfs into the mainline and run make,
however with the recent btrfs release its failing with
the following, any idea. ?
-
# make
scripts/kconfig/conf --silentoldconfig Kconfig
fs/btrfs/Kconfig:6: syntax error
fs/Kconfig
On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=12435
Congratulations ;)
Rejected documented, that's the best buzilla tag ever ;)
Thanks,
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
Hi,
On Mon, Jan 12, 2009 at 1:58 PM, Chris Mason chris.ma...@oracle.com wrote:
On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=12435
This is by far the biggest issue btrfs has for simple/domestic users.
Its probably the most tested
On Mon, 2009-01-12 at 15:14 +, Miguel Figueiredo Mascarenhas Sousa
Filipe wrote:
Hi,
On Mon, Jan 12, 2009 at 1:58 PM, Chris Mason chris.ma...@oracle.com wrote:
On Sun, 2009-01-11 at 15:34 -0800, Andrew Morton wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=12435
This is by far
On Tue, 2009-01-06 at 14:41 -0500, Chris Mason wrote:
Hello everyone,
Thanks for all of the comments so far. I've pushed out a number of
fixes for btrfs mainline, covering most of the comments from this
thread.
* All LINUX_KERNEL_VERSION checks are gone.
* checkpatch.pl fixes
* Extra
. This
is definitely the case for the -rt patchset, because they deliberately
trade performance by change even very short held spinlocks to sleeping
locks.
So I don't really know if -rt justifies adaptive locks in mainline/btrfs.
Is there no way for the short critical sections to be decoupled from
On Wed, Jan 07, 2009 at 02:07:42PM +0100, Ingo Molnar wrote:
* Chris Mason chris.ma...@oracle.com wrote:
All of this is a long way of saying the btrfs locking scheme is far from
perfect. I'll look harder at the loop and ways to get rid of it.
ob'plug
adaptive spinning mutexes perhaps?
* Matthew Wilcox matt...@wil.cx wrote:
On Wed, Jan 07, 2009 at 02:07:42PM +0100, Ingo Molnar wrote:
* Chris Mason chris.ma...@oracle.com wrote:
All of this is a long way of saying the btrfs locking scheme is far from
perfect. I'll look harder at the loop and ways to get rid of it.
On Wed, 2009-01-07 at 09:33 +, David Woodhouse wrote:
On Tue, 2009-01-06 at 14:41 -0500, Chris Mason wrote:
One more thing I'd suggest is removing the INSTALL file. The parts about
having to build libcrc32c aren't relevant when it's part of the kernel
tree and you have 'select LIBCRC32C',
J. Bruce Fields wrote:
Old kernel versions may still get booted after brtfs has gotten a
reputation for stability. E.g. if I move my / to brtfs in 2.6.34, then
one day need to boot back to 2.6.30 to track down some regression, the
reminder that I'm moving back to some sort of brtfs dark-ages
don't really know if -rt justifies adaptive locks in mainline/btrfs.
Is there no way for the short critical sections to be decoupled from the
long/sleeping ones?
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
On Sat, 2009-01-03 at 18:44 +0900, Ryusuke Konishi wrote:
On Fri, 02 Jan 2009 14:38:07 -0500, Chris Mason
Btrfs seems to have other helpful code including pages/bio compression
which may become separable, too. And, this may be the same for
pages/bio encryption/decryption code which would
they deliberately
trade performance by change even very short held spinlocks to sleeping locks.
So I don't really know if -rt justifies adaptive locks in mainline/btrfs.
Is there no way for the short critical sections to be decoupled from the
long/sleeping ones?
Yes and no. The locks are used here
[trim ccs]
Feel free to ignore this diversion ;) I'd like to see btrfs go upstream
sooner rather than later. But eventually we'll have to resurrect fsblock
vs extent map discussion.
On Tuesday 06 January 2009 00:21:43 Chris Mason wrote:
On Mon, 2009-01-05 at 21:32 +1100, Nick Piggin wrote:
On
On Tue, 2009-01-06 at 01:39 +1100, Nick Piggin wrote:
[trim ccs]
Feel free to ignore this diversion ;) I'd like to see btrfs go upstream
sooner rather than later. But eventually we'll have to resurrect fsblock
vs extent map discussion.
There's extent_map, extent_state and extent_buffer.
On Sun, 2009-01-04 at 22:52 +0100, Arnd Bergmann wrote:
On Saturday 03 January 2009, Chris Mason wrote:
Actually a lot of the ioctl API don't just need documentation but
a complete redo. That's true at least for the physical device
management and subvolume / snaphot ones.
On Mon, 2009-01-05 at 21:32 +1100, Nick Piggin wrote:
On Saturday 03 January 2009 06:38:07 Chris Mason wrote:
The extent_map and extent_buffer code was also intended for generic use.
It needs some love and care (making it work for blocksize != pagesize)
before I'd suggest moving it out of
Hi Chris,
Does this means that disk format finalised or at least backward
compatible?
On Wed, 2008-12-31 at 06:28 -0500, Chris Mason wrote:
Hello everyone,
I've done some testing against Linus' git tree from last night and the
current btrfs trees still work well.
There are a few bug
On January 4, 2009, KOSAKI Motohiro wrote:
Hi
One possibility would be to mimic ext4 and register the fs as btrfsdev
until it's considered stable enough for production. I agree with the
consensus that we want to use the upstream kernel as a nexus for
coordinating btrfs development, so
On Sun, Jan 04, 2009 at 07:21:50PM +0100, Peter Zijlstra wrote:
The -rt tree has adaptive spin patches for the rtmutex code, its really
not all that hard to do -- the rtmutex code is way more tricky than the
regular mutexes due to all the PI fluff.
For kernel only locking the simple rule:
Hi
One possibility would be to mimic ext4 and register the fs as btrfsdev
until it's considered stable enough for production. I agree with the
consensus that we want to use the upstream kernel as a nexus for
coordinating btrfs development, so I don't think it's worth waiting a
release or
On Saturday 03 January 2009, Chris Mason wrote:
Actually a lot of the ioctl API don't just need documentation but
a complete redo. That's true at least for the physical device
management and subvolume / snaphot ones.
The ioctl interface is definitely not finalized. Adding more vs
On Sat, Jan 03, 2009 at 02:50:34PM -0500, Christoph Hellwig wrote:
On Sat, Jan 03, 2009 at 12:17:06PM -0700, Matthew Wilcox wrote:
It's no worse than XFS (which still has its own implementation of
'synchronisation variables',
Which are a trivial wrapper around wait queues. I have patches
Hi,
On Wed, 31 Dec 2008 18:19:09 -0500, Chris Mason chris.ma...@oracle.com wrote:
This has only btrfs as a module and would be the fastest way to see
the .c files. btrfs doesn't have any changes outside of fs/Makefile and
fs/Kconfig
I found some overlapping (or cloned) functions in
On Sat, 2009-01-03 at 01:37 +0900, Ryusuke Konishi wrote:
Hi,
On Wed, 31 Dec 2008 18:19:09 -0500, Chris Mason chris.ma...@oracle.com
wrote:
This has only btrfs as a module and would be the fastest way to see
the .c files. btrfs doesn't have any changes outside of fs/Makefile and
On Fri, 2009-01-02 at 20:05 +0100, Andi Kleen wrote:
Chris Mason chris.ma...@oracle.com writes:
On Wed, 2008-12-31 at 10:45 -0800, Andrew Morton wrote:
On Wed, 31 Dec 2008 06:28:55 -0500 Chris Mason chris.ma...@oracle.com
wrote:
Hello everyone,
Hi!
I've done some testing
On Sat, 2009-01-03 at 01:37 +0900, Ryusuke Konishi wrote:
Hi,
On Wed, 31 Dec 2008 18:19:09 -0500, Chris Mason chris.ma...@oracle.com
wrote:
This has only btrfs as a module and would be the fastest way to see
the .c files. btrfs doesn't have any changes outside of fs/Makefile and
On Fri, Jan 02, 2009 at 02:32:29PM -0500, Chris Mason wrote:
If combination spinlocks/mutexes are really a win they should be
in the generic mutex framework. And I'm still dubious on the hardcoded
numbers.
Sure, I'm happy to use a generic framework there (or help create one).
They are
On Fri, 2009-01-02 at 22:01 +0100, Andi Kleen wrote:
On Fri, Jan 02, 2009 at 02:32:29PM -0500, Chris Mason wrote:
If combination spinlocks/mutexes are really a win they should be
in the generic mutex framework. And I'm still dubious on the hardcoded
numbers.
Sure, I'm happy to use
I don't disagree, please do keep in mind that I'm not suggesting anyone
use this in production yet.
When it's in mainline I suspect people will start using it for that.
I think the larger question here is where we want development to happen.
I'm definitely not pretending that
On Wed, 31 Dec 2008 06:28:55 -0500 Chris Mason chris.ma...@oracle.com wrote:
Hello everyone,
Hi!
I've done some testing against Linus' git tree from last night and the
current btrfs trees still work well.
what's btrfs? I think I've heard the name before, but I've never
seen the patches :)
On Wed, 2008-12-31 at 10:45 -0800, Andrew Morton wrote:
On Wed, 31 Dec 2008 06:28:55 -0500 Chris Mason chris.ma...@oracle.com wrote:
Hello everyone,
Hi!
I've done some testing against Linus' git tree from last night and the
current btrfs trees still work well.
what's btrfs? I
32 matches
Mail list logo
