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 transid verify failed since last November. While
the data on the drive is by
We've stopped using highmem for extent buffers.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
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
+++
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
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 l...@cn.fujitsu.com
---
fs/btrfs/free-space-cache.c | 12
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 it
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
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 liubo2...@cn.fujitsu.com
---
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
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 we can
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 parent 259
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-btrfsm=130208585106572w=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 it
On Wed, Aug 3, 2011 at 1:47 PM, David Sterba d...@jikos.cz 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-btrfsm=130208585106572w=2
You did! I was not aware of that. I believe adding a helper
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
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 and
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
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
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
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 thinks my
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 -ENOSPC :
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 could try
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
26 matches
Mail list logo
