We've stopped using highmem for extent buffers.
Signed-off-by: Li Zefan
---
fs/btrfs/ctree.h |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 365c4e1..746e6b4 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1415,17 +
BTRFS_SETGET_FUNCS macro is used to generate btrfs_set_foo() and
btrfs_foo() functions, which read and write specific fields in the
extent buffer.
The total number of set/get functions is ~200, but in fact we only
need 8 functions: 2 for u8 field, 2 for u16, 2 for u32 and 2 for u64.
It results in
We should convert the generation number to little endian before saving
it to disk.
We've just changed to use the normal checksumming infrastructure for
free space cache, so it's the perfect time to fix this bug.
Signed-off-by: Li Zefan
---
fs/btrfs/free-space-cache.c | 12 ++--
1 file
On 03.08.2011 08:57, Erik Jensen wrote:
> Had I known back in November 9 months would go by with no such tool, I
> would have certainly wiped the array and started over, as it was
> certainly not worth the wait. So here I am, several assurances of
> imminent release later, still wondering whether
I ran subvol & balance test script at current for-linus branch, I got
following warning messages.
Thanks,
Tsutomu
Aug 3 17:54:01 luna kernel: [21310.079308] [ cut here ]
Aug 3 17:54:01 luna kernel: [21310.079326] WARNING: at
fs/btrfs/extent-tree.c:5703 btrfs_alloc_free
When checking if there is enough space for balancing a block group,
since we do not take raid types into consideration, we do not account
corrent amounts of space that we needed. This makes us do some extra
work before we get ENOSPC.
Signed-off-by: Liu Bo
---
fs/btrfs/extent-tree.c | 41 +
OK so I have recovered all of my data. This was sort of a nerve wrecking
experience. I'll share what I've done in case others are experiencing the same
problem (I've seen other threads appear complaining of the same assertion which
draw no response).
So, I filled open_ctree_fd with printf statem
On 02.08.2011 19:42, Goffredo Baroncelli wrote:
>> Furthermore, receiving should not need kernel support at all (except for
>> an optional interface to create a file with a certain inode, we'll see).
>> Thus, replicating metadata corruptions should be very unlikely.
>
> I think that for receiving
On Mon, 2011-07-18 at 14:17 -0400, Josef Bacik wrote:
> I've been looking into this and I have a suspicion. Would you run
> with this patch and see if the problem goes away?
Didn't help me.
2.6.39 is not usable. 3.0.0 is ok for a few hours then too becomes
unusable. This is discussed in future
I can confirm this as well (64-bit, Core i7, single-disk).
> The issue seems to be gone in 3.0.0.
After a few hours working 3.0.0 slows down on me too. The performance
becomes unusable and a reboot is a must. Certain applications
(particularly evolution ad firefox) are next to permanently greyed
Hi,
I'm working on a patch to fix cross-volume cloning, worked for simple cases
like cloning a single file. When I cloned a full linux-2.6 tree there was a
immediate BUG_ON (after third cloned file) in btrfs_delayed_update_inode
with -ENOSPC :
[ 925.546266] [ cut here ]
[
On Fri, Jul 29, 2011 at 07:11:28PM +0200, Goffredo Baroncelli wrote:
> >$ btrfs subvol list -p .
> >ID 258 parent 5 top level 5 path subvol
> >ID 259 parent 5 top level 5 path subvol1
> >ID 260 parent 5 top level 5 path default-subvol1
> >ID 262 parent 5 top level 5 path p1/p1-snapshot
> >ID 263 pa
On Wed, Aug 03, 2011 at 08:07:42PM +0200, David Sterba wrote:
> I'm working on a patch to fix cross-volume cloning, worked for simple cases
> like cloning a single file. When I cloned a full linux-2.6 tree there was a
> immediate BUG_ON (after third cloned file) in btrfs_delayed_update_inode
> with
On Sat, Jul 30, 2011 at 12:16:44AM +0800, Zhong, Xin wrote:
> I believe I have submit a similar patch months ago:
> http://marc.info/?l=linux-btrfs&m=130208585106572&w=2
You did! I was not aware of that. I believe adding a helper make things
more clear (if it were used all over the code).
> Hope
On Wed, Aug 3, 2011 at 1:47 PM, David Sterba wrote:
> On Sat, Jul 30, 2011 at 12:16:44AM +0800, Zhong, Xin wrote:
>> I believe I have submit a similar patch months ago:
>> http://marc.info/?l=linux-btrfs&m=130208585106572&w=2
>
> You did! I was not aware of that. I believe adding a helper make thi
Hello all,
I recently had a power failure and can no longer mount my /home directory. The
harddrive has two BTRFS partitions: sda7(/) and sda8(/home). The / partition
loads up just fine, but /home does not. I've tried btrfsck as shown below and
I've included dmesg pertaining to btrfs. This is o
On Wed, Aug 03, 2011 at 04:46:01PM -0400, Adam Newby wrote:
> I recently had a power failure and can no longer mount my /home
> directory. The harddrive has two BTRFS partitions: sda7(/) and
> sda8(/home). The / partition loads up just fine, but /home does
> not. I've tried btrfsck as shown below a
Excerpts from Erik Jensen's message of 2011-08-03 02:57:24 -0400:
> The lack of any information on when btrfsck might be ready is a real
> headache to those deciding what to do with a corrupted file system.
>
> I am currently sitting on a btrfs array of 10 disks that has been
> reporting "parent t
Hi!
Since upgrading from 2.6.35+bits to 2.6.38 and then more recently to 3.0,
our "big btrfs backup box" with 20 * 3 TB AOE-attached btrfs volumes
started showing more CPU usage and backups were no longer completing in a
day. I tried Linus HEAD from yesterday merged with btrfs for-linus (same
as L
On Wed, Aug 03, 2011 at 03:06:55PM -0700, Simon Kirby wrote:
> I see Josef's 86d4a77ba3dc4ace238a0556541a41df2bd71d49 introduced the
> bitmaps list. I could try temporarily reverting this (some fixups needed)
> if anybody thinks my cache bouncing idea might be slightly possible.
I'll try the atta
On Wed, Aug 03, 2011 at 03:39:49PM -0700, Simon Kirby wrote:
> On Wed, Aug 03, 2011 at 03:06:55PM -0700, Simon Kirby wrote:
>
> > I see Josef's 86d4a77ba3dc4ace238a0556541a41df2bd71d49 introduced the
> > bitmaps list. I could try temporarily reverting this (some fixups needed)
> > if anybody thin
On Wed, 3 Aug 2011 20:07:42 +0200, David Sterba wrote:
> I'm working on a patch to fix cross-volume cloning, worked for simple cases
> like cloning a single file. When I cloned a full linux-2.6 tree there was a
> immediate BUG_ON (after third cloned file) in btrfs_delayed_update_inode
> with -ENOSP
Excerpts from Simon Kirby's message of 2011-08-03 19:10:59 -0400:
> On Wed, Aug 03, 2011 at 03:39:49PM -0700, Simon Kirby wrote:
>
> > On Wed, Aug 03, 2011 at 03:06:55PM -0700, Simon Kirby wrote:
> >
> > > I see Josef's 86d4a77ba3dc4ace238a0556541a41df2bd71d49 introduced the
> > > bitmaps list. I
Perhaps as a further clue as to what is going on, on this same backup box
after all of the rsyncs are finished/killed and a good amount of time has
passed (no cleaner processes running in the background or anything),
"sync" is still consistently takes ~4 minutes to run, and pushes out a
lot to disk
David Sterba wrote:
> On Wed, Aug 03, 2011 at 08:07:42PM +0200, David Sterba wrote:
>> I'm working on a patch to fix cross-volume cloning, worked for simple cases
>> like cloning a single file. When I cloned a full linux-2.6 tree there was a
>> immediate BUG_ON (after third cloned file) in btrfs_de
25 matches
Mail list logo
