Sorry it took so long to reply its been a crazy week for me. Anyway
thanks for figuring this out for me. I can't believe I made such a
stupid mistake. Anyway here is the rebased patch.
Lee
diff -Naur btrfs-orig/async-thread.c btrfs/async-thread.c
--- btrfs-orig/async-thread.c 2009-02-26
I have also cleaned up the backport experimental patch so it applies
cleanly on the latest code.
Lee
diff -Naur btrfs-orig/async-thread.c btrfs/async-thread.c
--- btrfs-orig/async-thread.c 2009-02-26 13:07:03.0 -0500
+++ btrfs/async-thread.c2009-02-26 13:09:18.0 -0500
, and apply the patch
supplied in the Feb. 11 message to the M/L.
I then create a kernel module based on the results in /fs/btrfs/
I have also tried replicating the experimental branch, and merging the
patch into that branch, but I get the same results.
On Wed, Feb 25, 2009 at 12:26 AM, Lee Trager
On Tue, Feb 24, 2009 at 11:24:06AM -0500, jim owens wrote:
Lee Trager wrote:
The more and more I look at this problem the more I tend to think that
the issue is because of some change in the way the VFS or something
interacts with the file system. Does anyone know of any big changes? Why
I'm not sure when we should start developing BTRFS support for GRUB but
I do agree that it will be very difficult to support all the features of
BTRFS. As far as I know GRUB does not support LVM and only supports
RAID1. Doing this shouldn't be that hard to do, in fact it should be
easier to do
Mitch, I haven't seen any problems using BTRFS and my patch on 2.6.28 or
2.6.27, what are you doing to cause this error? Are you using the latest
sources from btrfs-unstable?
Lee
Mitch Harder (aka DontPanic) wrote:
I have also been getting similar warnings filling up my logs.
However, in my
-12 at 01:31 -0500, Lee Trager wrote:
While running a few tests with the btrfs sources pulled from
btrfs-unstable patched with my patch to compile under 2.6.26 I
encountered a very weird problem. Everything works fine the first time I
mount the file system (either actual disk or loop back
I've noticed that the btrfs-unstable-standalone repository hasn't been
updated in over three weeks. It seems all active development is taking
place on btrfs-unstable. What is happening to the
btfs-unstable-standalone repository? Will all future development only be
on btrfs-unstable or is there
Since for the past three weeks all new patches have been submitted only
to btrfs-unstable I have updated my backport patch for btrfs-unstable.
This patch only works with 2.6.27 and 2.6.26(thanks Michele for testing
it for me)
Lee
diff -Naur btrfs-old/async-thread.c btrfs/async-thread.c
---
While running a few tests with the btrfs sources pulled from
btrfs-unstable patched with my patch to compile under 2.6.26 I
encountered a very weird problem. Everything works fine the first time I
mount the file system (either actual disk or loop back). When I
unmounted the file system and mounted
This patch will allow btrfs-unstable-standalone to compile cleanly
against 2.6.27, 2.6.26, and possibly older(I havn't tested older then
26).
Signed-off-by: Lee Trager l...@cs.drexel.edu
---
compat.h | 24
export.h | 28
extent
A couple of weeks ago it was mentioned that btrfs in the stand alone
tree would be patched to support 2.6.27 with older versions coming
after. Has anyone actually done these patches? I'd like to get btrfs
running on 2.6.26(Debian Lenny kernel) and if no one has done any code
towards it I'd be
On Wed, Dec 17, 2008 at 05:43:50PM +, Michele Petrazzo wrote:
Hi,
I just tried to compile the last unstable version, but:
CC [M] /home/michele/btrfs-unstable-standalone/inode.o
/home/michele/btrfs-unstable-standalone/inode.c: In function
???btrfs_new_inode???:
If multiple compression schemes are implemented how should the user go
about choosing which one they want? Should it be done at kernel time? Or
with the userland tools on a per file basis(maybe zlib is the default
but a user could say I want this directory to be bzip)?
On Mon, Dec 15, 2008 at
On Tue, Dec 09, 2008 at 03:22:29PM -0500, jim owens wrote:
Joshua J. Berry wrote:
On Tuesday 09 December 2008 08:35:16 Chris Mason wrote:
On Tue, 2008-12-09 at 09:59 -0500, Lee Trager wrote:
Currently compression and I assume if encryption is implemented it is
turned on or off during mount
On Tue, Dec 09, 2008 at 05:22:18PM +0100, Christian Hesse wrote:
On Tuesday 09 December 2008, Miguel Figueiredo Mascarenhas Sousa Filipe wrote:
Hi there,
On Tue, Dec 9, 2008 at 2:59 PM, Lee Trager [EMAIL PROTECTED] wrote:
Currently compression and I assume if encryption is implemented
wrote:
On Tue, 2008-12-09 at 09:59 -0500, Lee Trager wrote:
Currently compression and I assume if encryption is implemented it is
turned on or off during mount. There are however many times when a user may
want to select which files/directories they want to compress or encrypt.
This will also
Because the last bug I dealt with had so much to do with the disk being
full I decided to test and see what happens when I fill up the disk.
Unfortunatly the disk thinks its full before it actually is. I have a
7539M btrfs partition and tried to fill it by doing
dd if=/dev/zero of=/mnt/btrfs/fill
Is that just finishing btrfs_check_free_space? What would that involve?
I haven't done much kernel work but I could give it a try.
Lee
Josef Bacik wrote:
On Wed, Nov 19, 2008 at 05:24:34PM -0500, Lee Trager wrote:
Because the last bug I dealt with had so much to do with the disk being
I to am getting the same error when running bonnie++.
Lee
Content-Description: Forwarded message - Re: [PATCH] fix free space leak
From: Mitch Harder (aka DontPanic) [EMAIL PROTECTED]
To: linux-btrfs@vger.kernel.org linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] fix free space leak
I still get a kernel panic with both of your patches installed. When I
checked with df the file system is about 65% full. But even if it was
full it shouldn't cause a kernel panic.
Lee
Nov 17 21:16:50 Intrepid-btrfs kernel: [ 1201.234036] we were searching
for 24576 bytes, num_bytes 24576, loop
+0x3c2/0x480 [btrfs] SS:ESP 0068:d82dbd74
Nov 14 16:23:46 Intrepid-btrfsc kernel: [ 1299.159252] ---[ end trace
ae4786bfdd8753ad ]---?
On Thu, Nov 13, 2008 at 02:20:05PM -0500, Josef Bacik wrote:
On Thu, Nov 13, 2008 at 01:49:07PM -0500, Lee Trager wrote:
I wanted to see how btrfs compares to other
7539M
Lee
On Fri, Nov 14, 2008 at 03:26:37PM -0500, Josef Bacik wrote:
How big is your fs? Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I wanted to see how btrfs compares to other filesystems so I have been
running bonnie++ on it. While the results are good(much faster then
ext2) every once in awhile I get a kernel oops. I am testing on xubuntu
8.10 with the 2.6.27-7-686 kernel using the latest git sources. Most of the
time the
24 matches
Mail list logo
