On 11 July 2012 09:37, Liu Bo wrote:
> On 07/10/2012 08:18 PM, Daniel J Blueman wrote:
>
>> On 2 July 2012 12:20, Liu Bo wrote:
>>> On 07/02/2012 11:35 AM, Daniel J Blueman wrote:
>>>
> Hi everyone,
>
> I've got a nice set of fixes from Josef, Jan, Ilya and others in my
> for-linu
On 07/11/2012 02:58 AM, Josef Bacik wrote:
> On Tue, Jul 10, 2012 at 05:27:59AM -0600, Liu Bo wrote:
>> While testing with my buffer read fio jobs[1], I find that btrfs does not
>> perform well enough.
>>
>> Here is a scenario in fio jobs:
>>
>> We have 4 threads, "t1 t2 t3 t4", starting to buffer
On 07/10/2012 08:18 PM, Daniel J Blueman wrote:
> On 2 July 2012 12:20, Liu Bo wrote:
>> On 07/02/2012 11:35 AM, Daniel J Blueman wrote:
>>
Hi everyone,
I've got a nice set of fixes from Josef, Jan, Ilya and others in my
for-linus branch:
git://git.kernel.org/pub/scm
Hi Goffredo,
Am 10.07.2012 20:42, schrieb Goffredo Baroncelli:
> Hi Arnd,
>
> I am trying to reproduce this bug. Which kernel version are you using ?
I'm using linus' vanilla tree from Sunday which is 3.5.0-rc6
plus some unsuspicious commits.
Best regards
Arnd
--
To unsubscribe from this list:
On Tue, Jul 10, 2012 at 01:39:42PM -0600, Arne Jansen wrote:
> On 07/10/2012 08:52 PM, Josef Bacik wrote:
> > Daniel Blueman reported a bug with fio+balance on a ramdisk setup.
> > Basically what happens is the balance relocates a tree block which will drop
> > the implicit refs for all of its chil
On 07/10/2012 08:52 PM, Josef Bacik wrote:
> Daniel Blueman reported a bug with fio+balance on a ramdisk setup.
> Basically what happens is the balance relocates a tree block which will drop
> the implicit refs for all of its children and adds a full backref. Once the
> block is relocated we have
On Mon, Jul 09, 2012 at 08:21:07PM -0600, Li Zefan wrote:
> Inodes always allocate free space with BTRFS_BLOCK_GROUP_DATA type,
> which means every inode has the same BTRFS_I(inode)->free_space pointer.
>
> This shrinks struct btrfs_inode by 4 bytes (or 8 bytes on 64 bits).
>
> Signed-off-by: Li
So, I got the sysq-w + the whole dmesg until crash
<6>[0.00] Initializing cgroup subsys cpuset
<6>[0.00] Initializing cgroup subsys cpu
<5>[0.00] Linux version 3.4.0-00091-gcb77fcd (root@navilaptop)
(gcc version 4.6.2 (Gentoo 4.6.2-r1 p1.4, pie-0.5.0) ) #1 SMP Thu Jun
21 18
On Tue, Jul 10, 2012 at 05:27:59AM -0600, Liu Bo wrote:
> While testing with my buffer read fio jobs[1], I find that btrfs does not
> perform well enough.
>
> Here is a scenario in fio jobs:
>
> We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file,
> and all of them will race on
Daniel Blueman reported a bug with fio+balance on a ramdisk setup.
Basically what happens is the balance relocates a tree block which will drop
the implicit refs for all of its children and adds a full backref. Once the
block is relocated we have to add the implicit refs back, so when we cow the
b
Hi Arnd,
I am trying to reproduce this bug. Which kernel version are you using ?
BR
G.Baroncelli
On 07/10/2012 07:55 PM, Goffredo Baroncelli wrote:
> On 07/10/2012 10:52 AM, Arnd Hannemann wrote:
>> Hi,
>>
>> Am 10.07.2012 05:30, schrieb Christian Robert:
>>> I agree with you, but you should nev
On 07/10/2012 10:52 AM, Arnd Hannemann wrote:
> Hi,
>
> Am 10.07.2012 05:30, schrieb Christian Robert:
>> I agree with you, but you should never mount a snapshot of a btrfs
>> filesystem at the same time the original is,
>> because both the original and the snapshot had same "device fsid
>> 5c3e
Am 21.06.2012 22:10, schrieb Josef Bacik:
> Harald Hoyer has had this as a feature request for ages and I've finally
> gotten
> around to hacking something up. This is probably going to get bikeshedded to
> death, bring it on, I'm not married to any of the behaviors in these patches,
> I
> just
Alexander,
this focuses on area of sending file extents:
> +static int is_extent_unchanged(struct send_ctx *sctx,
> + struct btrfs_path *left_path,
> + struct btrfs_key *ekey)
> +{
> + int ret = 0;
> + struct btrfs_key key;
> +
>From btree_read_extent_buffer_pages(), currently repair_io_failure()
can be called with mirror_num being zero when submit_one_bio() returned
an error before. This used to cause a BUG_ON(!mirror_num) in
repair_io_failure() and indeed this is not a case that needs the I/O
repair code to rewrite disk
On Tue, 10 Jul 2012 09:48:27 +1000, Shavi N wrote:
> Hi,
>
> I have this problem after trying to run btrfsck.
> I have new 11 HDDs WD 2tb, on two RAID controllers
> Arch Linux, latest kernel. What I was doing was copying and reading
> multiple data at the same time
> After getting I/O errors while
On 2 July 2012 12:20, Liu Bo wrote:
> On 07/02/2012 11:35 AM, Daniel J Blueman wrote:
>
>>> Hi everyone,
>>>
>>> I've got a nice set of fixes from Josef, Jan, Ilya and others in my
>>> for-linus branch:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
>>> for-linus
>>>
Since root can be fetched via BTRFS_I macro directly, we can save an args
for btrfs_is_free_space_inode().
Signed-off-by: Liu Bo
---
fs/btrfs/btrfs_inode.h |5 +++--
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/file-item.c |2 +-
fs/btrfs/inode.c | 22 +++---
4 fi
While testing with my buffer read fio jobs[1], I find that btrfs does not
perform well enough.
Here is a scenario in fio jobs:
We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file,
and all of them will race on add_to_page_cache_lru(), and if one thread
successfully puts its page
For btree inode, its root is also 'tree root', so btree inode can be
misunderstood as a free space inode.
We should add one more check for btree inode.
Signed-off-by: Liu Bo
---
fs/btrfs/btrfs_inode.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/btrfs_i
This code should detect the problem without SIGSEGV but a Assertition.
...
Csum didn't match
btrfsck: btrfsck.c:1177: walk_down_tree: Assertion `!(1)' failed.
Aborted
...
--- btrfsck.c 2012-07-10 10:23:24.781622144 +0200
+++ btrfsck.c 2012-07-10 12:59:00.120146266 +0200
@@ -1173,7 +1173,7 @@
Anand Jain hat am 10. Juli 2012 um 08:30 geschrieben:
>
> Christian,
>
> line # is still confusing to me as well. patch was to avoid seg
> fault when csum_root node is null and it might not be the case
> here then.
>
> (If the original problem stack-trace has remained the same
> whic
Am 10.07.2012 00:49, schrieb cwillu:
> On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann wrote:
>> Hi,
>>
>> using btrfs with LVM snapshots seems to be confusing /proc/mounts
>> After mounting a snapshot of an original filesystem, the devicename of the
>> original filesystem is overwritten with that
Hi,
Am 10.07.2012 05:30, schrieb Christian Robert:
> I agree with you, but you should never mount a snapshot of a btrfs filesystem
> at the same time the original is,
> because both the original and the snapshot had same "device fsid
> 5c3e8ca2-da56-4ade-9fef-103a6a8a70c2"
>
> the kernel will t
24 matches
Mail list logo
