While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit
On Wed, 24 Sep 2014 11:28:26 +0100, Filipe Manana wrote:
[SNIP]
> int btrfs_wait_marked_extents(struct btrfs_root *root,
> + struct btrfs_trans_handle *trans,
> struct extent_io_tree *dirty_pages, int mark)
> {
> int err = 0;
> @@ -852,6
On Wed, Sep 24, 2014 at 12:16 PM, Miao Xie wrote:
> On Wed, 24 Sep 2014 11:28:26 +0100, Filipe Manana wrote:
> [SNIP]
>> int btrfs_wait_marked_extents(struct btrfs_root *root,
>> + struct btrfs_trans_handle *trans,
>> struct extent_io_tree *di
Simone Ferretti posted on Tue, 23 Sep 2014 14:06:41 +0200 as excerpted:
> we're testing BTRFS on our Debian server. After a lot of operations
> simulating a RAID1 failure, every time I mount my BTRFS RAID1 volume the
> kernel logs these messages:
>
> [73894.436173] BTRFS: bdev /dev/etherd/e30.20
GEO posted on Tue, 23 Sep 2014 14:58:06 +0200 as excerpted:
> Is that supposed to be that way? Why is readonly not enough to import
> data using btrfs send?
This is a known issue. The subvolume itself needs to be set read-only,
and of course that can't be done when the whole filesystem is set r
Wed, Sep 24, 2014 at 01:23:32PM +, Duncan wrote:
> Simone Ferretti posted on Tue, 23 Sep 2014 14:06:41 +0200 as excerpted:
>
> > we're testing BTRFS on our Debian server. After a lot of operations
> > simulating a RAID1 failure, every time I mount my BTRFS RAID1 volume the
> > kernel logs the
Hello all seeing something odd with btrfs and lvm thin-provisioning snapshots.
Sent my finding to the lvm list and thought I might post here after some
feedback which I have included. Apologies in advance if this is bad form.
Please let me know. Hopefully the trail below is not too confusing.
I ran 'btrfs check --repair --init-extent-tree' and appear to be in an
infinite loop. It performed heavy IO for about 1.5 hours then the IO
stopped and the CPU stayed at 100%. It's been like that for more than 12
hours now.
I made a hardware change last week that resulted in unstable RAM so I
susp
On Wed, Sep 24, 2014 at 02:34:45PM +, Robb Walker wrote:
> Hello all seeing something odd with btrfs and lvm thin-provisioning
> snapshots. Sent my finding to the lvm list and thought I might post
> here after some feedback which I have included. Apologies in advance
> if this is bad form. Plea
I noticed the following:
(gdb) print nrscan
$19 = 1680726970
(gdb) print tree->cache_size
$20 = 1073741824
(gdb) print cache_hard_max
$21 = 1073741824
It appears that cache_size can not shrink below cache_hard_max so we
never end up breaking out of the loop. The FS in question is 30TB with
~26TB
Thanks very much! btrfs OR lvm thin prov gets me where I want to go, so I can
live with them being mutually exclusive. Though yes, I would have used them
both if I could. ;)
Thanks for the clear explanation and your explanation also syncs with what the
lvm developers also were thinking.
It als
On Sun, 21 Sep 2014 11:05:46 Chris Murphy wrote:
> On Sep 20, 2014, at 7:39 PM, Russell Coker wrote:
> > Anyway the new drive turned out to have some errors, writes failed and
> > I've
> > got a heap of errors such as the above.
>
> I'm curious if smartctl -t conveyance reveals any problems, it's
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit
I got past the loop issue with the larger cache_hard_max then hit:
repaired damaged extent references
Unable to find block group for 0
btrfs: extent-tree.c:288: find_search_start: Assertion `!(1)' failed.
Not sure what to try next. Ideas?
--Larkin
On 9/24/2014 10:29 AM, Larkin Lowrey wrote:
> I
bi_sector and bi_size moved to bi_iter since commit 4f024f3797c4
("block: Abstract out bvec iterator")
Signed-off-by: Fabian Frederick
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 5b5a5c4..d47289c 100
Any idea how to recover? I can't cut-paste but it's
Total devices 1 FS bytes used 176.22GiB
size 233.59GiB used 233.59GiB
Basically it's been data allocation happy, since I haven't deleted
53GB at any point. Unfortunately, none of the chunks are at 0% usage
so a balance -dusage=0 finds nothing t
On Fri, 2014-09-19 at 13:10 -0500, Jeb Thomson wrote:
> With the advanced features of btrfs, it would be an additional
> simple task to make different platters run in parallel.
>
> In this case, say a disk has three platters, and so three seek heads
> as well. If we can identify that much, and w
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit
On Wed, 24 Sep 2014 16:43:43 -0400, Dan Merillat wrote:
> Any idea how to recover? I can't cut-paste but it's
> Total devices 1 FS bytes used 176.22GiB
> size 233.59GiB used 233.59GiB
The notorious -EBLOAT. But don't despair just yet.
> Basically it's been data allocation happy, since I haven't
Simone Ferretti posted on Wed, 24 Sep 2014 16:28:35 +0200 as excerpted:
> Wed, Sep 24, 2014 at 01:23:32PM +, Duncan wrote:
>> Simone Ferretti posted on Tue, 23 Sep 2014 14:06:41 +0200 as excerpted:
>>
>>> we're testing BTRFS on our Debian server. After a lot of operations
>>> simulating a RA
Btrfs developers,
Can someone who knows how this is all supposed to work pass an eye
over this patch series to determine the validity of what is being
tested? Given the number of problems this patchset seems to expose,
it looks pretty important to me to get this into all of your regular
testing.
Hi David,
(2014/09/22 21:01), David Sterba wrote:
On Fri, Sep 19, 2014 at 05:52:17PM +0900, Satoru Takeuchi wrote:
@@ -99,7 +99,7 @@ find_prop_handler(const char *name,
return NULL;
}
-static int __btrfs_set_prop(struct btrfs_trans_handle *trans,
+int __btrfs_set_prop(struct btrfs_tr
From: Naohiro Aota
Fix the following two problems in compression related ioctl() code.
a) Updating compression flags and updating inode attribute
in two separated transaction. So, if something bad happens
after the former, and before the latter, file system
would become inconsis
23 matches
Mail list logo
