8 e8 82 c2 ff ff 48 39 d8 77 1f b8
1d 00 00 00 e9 0a ff ff ff a8 01 90 0f 85 74 fe ff ff 0f 0b eb fe <0f>
0b eb fe 0f 0b eb fe 4c 89 fb 44 8b 7d ac 83 7d 30 00 41 be
RIP [] lookup_inline_extent_backref+0x2ea/0x400 [btrfs]
RSP
--
Daniel J Blueman
--
To unsubscribe from this list: send the li
sda /store && cd /store
fio /usr/share/doc/fio/examples/iometer-file-access-server
--- [2]
kernel BUG at /home/apw/COD/linux/fs/btrfs/extent-tree.c:1481!
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majo
[13259.594221] btrfs: open_ctree failed
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21 March 2012 00:16, Andrea Gelmini wrote:
> 2012/3/20 Daniel J Blueman :
>> mkfs.btrfs -m raid0 -d raid0 /dev/sdb1 /dev/sdc1
>> mount /dev/sdb1 /mnt
>> umount /mnt
>> mount /dev/sdb1 /mnt -o compress
>> umount /mnt
>> mount /dev/sdb1 /mnt -o ssd
&g
=32m
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/dev/ram0 /mnt -o discard
cd /mnt && tar -xvzf linux.tar.gz
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
which tests out fine here. The workaround is to not mount with
'discard' until eg ~3.4-rc3 or later.
Thanks,
Daniel
[1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16409
[2] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16649
--
Daniel J Blueman
--
To unsubscribe
On 8 April 2012 16:49, Liu Bo wrote:
> On 04/06/2012 07:36 PM, Daniel J Blueman wrote:
>> Hi Josef, Chris,
>>
>> When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see
>> discard ranges exceeding the end of the block device [1], potentially
>> c
On 9 April 2012 22:44, Leho Kraav wrote:
> On 09.04.2012 17:35, Daniel J Blueman wrote:
>>
>> Leho Kraav kraav.com> writes:
>> []
>>>
>>> Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond end
>>> of device
>>>
90/0x90
[] aio_run_iocb+0x5e/0x150
[] io_submit_one+0x175/0x220
[] do_io_submit+0x129/0x1c0
[] sys_io_submit+0xb/0x10
[] system_call_fastpath+0x16/0x1b
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I was seeing root_list corruption on unmount during fs resize in 3.4-rc4; add
correct locking to address this.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/relocation.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 017281d..5a105a0
and I'll get a patch tested and sent.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix out-of-space checking, addressing a warning and potential resource
leak when resizing the filesystem down while allocating blocks.
Signed-off-by: Daniel J Blueman
Reviewed-by: Josef Bacik
---
fs/btrfs/relocation.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs
Correctly drop locks during error cases.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/transaction.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 11b77a5..ede3988 100644
--- a/fs/btrfs/transaction.c
+++ b/fs
Address some minor type issues identified by sparse checker.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/ioctl.c |2 +-
fs/btrfs/ulist.c |4 ++--
fs/btrfs/ulist.h |5 ++---
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index
y(&worker->worker_list) &&
234 list_empty(&worker->prio_pending) &&
235 list_empty(&worker->pending) &&
236 atomic_read(&worker->num_pending) == 0) {
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ice ram1) in btrfs_run_delayed_refs:2454: error 28
btrfs is forced readonly
BTRFS warning (device ram1): Skipping commit of aborted transaction.
...
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vg
On 2 May 2012 22:01, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/02/2012 01:44 AM, Daniel J Blueman wrote:
>> I see the filesystem going readonly when run_clustered_refs
>> returns -ENOSPC [1], so it looks like we need something li
Fix control flow to store count before breaking loop.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/ctree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index e801f22..2227420 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
On 3 May 2012 22:04, David Sterba wrote:
> On Thu, May 03, 2012 at 09:44:49PM +0800, Daniel J Blueman wrote:
>> Fix control flow to store count before breaking loop.
>
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg10483.html
> but it's a dead code anyway.
Fix BTRFS messages to print a newline where there should be one.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/super.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index c5f8fca..c99cb72 100644
--- a/fs/btrfs/super.c
+++ b/fs
Fix various messages to include newline and module prefix.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/super.c |8
fs/btrfs/volumes.c |6 +++---
fs/btrfs/zlib.c|8
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs
bvol+0x135/0x1a0 [btrfs]
[] ? files_lglock_local_lock+0x70/0x70
[] btrfs_ioctl_snap_create_transid+0x12a/0x190 [btrfs]
[] btrfs_ioctl_snap_create_v2.constprop.57+0xe0/0xf0 [btrfs]
[] ? __schedule+0x351/0x8b0
[] btrfs_ioctl+0x409/0x770 [btrfs]
[] do_vfs_ioctl+0x87/0x340
[] sys_ioctl+0x4a/0x80
[] system_call_fastpath+0x16/0x1b
rfs testathon script as it seems handy for QA?
Thanks,
Daniel
> On wed, 09 May 2012 11:39:36 +0800, Miao Xie wrote:
>> On tue, 8 May 2012 16:56:27 +0800, Daniel J Blueman wrote:
>>> Delayed allocation ref mutexes are taken [1] inside
>>> btrfs_commit_transact
0
[] system_call_fastpath+0x16/0x1b
note: btrfs[3219] exited with preempt_count 1
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 July 2012 21:34, Josef Bacik wrote:
> On Sun, Jul 01, 2012 at 09:35:01PM -0600, 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:
>> >
>>
Code:e8 5d f6 02 00 45 31 c9 48 8b 4d a0 89 c2 44 8b 45 a8 eb b5 66 0f
1f 44 00 00 41 bd 0d 00 00 00 00 41 be 0d 00 00 00 00 e9 6b fe ff ff
f>0b 0f 0b 0f 1f 00 55 48 89 e5 48 83 c4 80 48 8b 45 20 4c 89
RIP [] update_inline_extent_backref+0x2a9/0x2b0 [btrfs]
RSP
--
Daniel J Blueman
--
To uns
On 4 July 2012 13:19, Liu Bo wrote:
> On 07/04/2012 11:37 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
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.
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&
tpath+0x16/0x1b
Code: f9 ff 8b 45 98 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0
4c 8b 7d f8 c9 c3 66 0f 1f 84 00 00 00 00 00 b8 f4 ff ff ff eb da <0f>
0b 0f 1f 80 00 00 00 00 55 89 d0 45 31 c9 48 89 e5 41 56 41
RIP [] __add_tree_block.part.54+0xe7/0xf0 [btrfs]
RSP
--
Daniel
_NOCOW, &ordered->flags))
btrfs_free_reserved_extent(root, ordered->start,
--- [2]
Fix leak of 'dip' on error path and unnecessary double-assignment.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 558cac2..312eeb7 100644
--
ray?
>
> No, plain vanilla partition on physical hard disk. Btrfs was made with the
> command "mkfs.btrfs /dev/sdc1" no extra arguments.
By default, metadata is duplicated, thus it could be that BTRFS is
using the correct copy of the metadata after finding checksum errors
in the fir
x83/0xa0
[] vfs_fsync+0x1c/0x20
[] do_fsync+0x3a/0x60
[] sys_fsync+0x10/0x20
[] system_call_fastpath+0x16/0x1b
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eback_thread+0x0/0x260
> [ 8114.870020] [] kthread+0x97/0xa0
> [ 8114.870020] [] kernel_thread_helper+0x4/0x10
> [ 8114.870020] [] ? kthread+0x0/0xa0
> [ 8114.870020] [] ? kernel_thread_helper+0x0/0x10
Interesting. If you mount the filesystem with 'noatime,nodiratime' or
&#
he party, but does memtest86 pass over multiple iterations?
Also, can you send an 'sudo lspci -vv', so we can check for
known-buggy controllers and bridges?
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the b
[] ? vfs_fstatat+0x41/0x80
[] ? put_lock_stats+0xe/0x40
[] ? lock_release_holdtime+0xac/0x150
[] ? vfs_stat+0x16/0x20
[] ? sys_newstat+0x1f/0x50
[] ? trace_hardirqs_on_caller+0x15d/0x1b0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] ? system_call_fastpath+0x16/0x1b
--
Daniel J Blueman
--
To un
fio
[global]
direct=0
directory=/mnt
size=1024m
bsrange=4k-128k
timeout=60
numjobs=4
[f1]
rw=write
[f2]
stonewall
rw=randwrite
[f3]
stonewall
rw=read
[f4]
stonewall
rw=randread
EOF
mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc
mount /dev/sdb /mnt
fio workload.fio
...
--
Daniel J Blueman
--
90 90 90 90 90 90 90 90 55 b8 00 01 00 00 48 89 e5
66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6 c9 c3 66 0f 1f 44
RIP [] __ticket_spin_lock+0x9/0x20
RSP
CR2: 00b0
---[ end trace a7919e7f17c0a728 ]---
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe
On 24 February 2011 20:48, liubo wrote:
> On 02/24/2011 04:13 PM, Daniel J Blueman wrote:
>> When creating a filesystem (single or redundant) with BTRFS and
>> subsequently executing a balance [1], we see a kernel oops at the next
>> mount [2].
>>
>
> Hi, Daniel,
Correctly unlock delayed_refs in the error case.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index e1aa8d6..c48d699 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2787,6 +2787,7 @@ static int btrfs_destroy_delayed_refs(struct
Prevent needless exporting of internal functions from compilation
units by marking them static.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index b5baff0..5e49196 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -74,7 +74,7 @@ noinline void
space and kill
The previous patch is broken and leaks dip when dip->csums allocation
fails; bio->bi_end_io isn't set at the point where the free_ordered
branch is consequently taken, thus bio_endio doesn't call the function
which would free it in the normal case. Fix.
Signed-off-b
02 a8 08 0f 85 9c 00 00 00 be cb 0e 00 00 48 c7 c7 b8 7c
RIP [] write_extent_buffer+0xbb/0x1b0 [btrfs]
RSP
CR2:
---[ end trace a7919e7f17c0a728 ]---
note: btrfs-delalloc-exited with preempt_count 1
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubsc
ead_extent_buffer+0xf2/0x230
[] ? btrfs_search_slot+0x886/0xa90
[] ? sub_preempt_count+0x9d/0xd0
[] ? read_extent_buffer+0xf2/0x230
[] ? btrfs_balance+0x20d/0x280
[] ? btrfs_ioctl+0x1b6/0xa80
[] ? do_page_fault+0x1cc/0x440
[] ? do_vfs_ioctl+0x9d/0x590
[] ? fget_light+0x1df/0x3c0
[] ? sys_ioctl+0x4a/0x80
0x190
[] vfs_fsync_range+0x73/0x90
[] ? fget_raw+0x260/0x260
[] vfs_fsync+0x17/0x20
[] do_fsync+0x35/0x60
[] sys_fsync+0xb/0x10
[] system_call_fastpath+0x16/0x1b
---[ end trace a7919e7f17c0a728 ]---
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btr
0/0x590
[] do_vfs_ioctl+0x8d/0x330
[] ? fget_light+0x2bf/0x3c0
[] ? trace_hardirqs_on_caller+0x14d/0x190
[] sys_ioctl+0x4a/0x80
[] system_call_fastpath+0x16/0x1b
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord..
t;
0b eb fe 48 3b 50 20 0f 84 04 ff ff ff 0f 0b eb fe 83 7d c4
RIP [] btrfs_reloc_cow_block+0x28b/0x2c0
RSP
---[ end trace a7919e7f17c0a728 ]---
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.
Hi Josef, Chris,
On 8 April 2011 00:23, Josef Bacik wrote:
> On 04/07/2011 03:21 AM, Daniel J Blueman wrote:
>>
>> When running a practical stress-test on 2.6.29-rc2 trying to reproduce
>> an older (extent refcounting) issue, I am consistently able to hit an
>> oops
c6 fe ff 4c 8b 5d a0 4c 8b 55 a8 85 c0 75 bc e9 31 ff ff ff <0f>
0b 48 8b b2 d0 fc ff ff 48 8d 7d b0 b9 11 00 00 00 4d 89 d9
RIP [] btrfs_add_link+0x132/0x190
RSP
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
Hi Chris,
This didn't make it in before, so updating to 2.6.39-rc2 and resending:
Prevent needless exporting of internal functions from compilation
units by marking them static.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 84d7ca1..6581b37 1
Fix address space annotation correct in ioctl.c.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index cfc264f..0474ec3 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2287,7 +2287,7 @@ long btrfs_ioctl_space_info(struct btrfs_root
*root, void __user
On 11 April 2011 23:32, Josef Bacik wrote:
> On 04/10/2011 04:29 AM, Daniel J Blueman wrote:
>>
>> When rebooting from a crash, thus during log replay on 2.6.29-rc2,
>> btrfs_insert_dir_item caused an assertion failure [1]. The fs was
>> being mounted clear_cache on
On 11 April 2011 23:45, Josef Bacik wrote:
> On 04/11/2011 11:40 AM, Daniel J Blueman wrote:
>>
>> Hi Chris,
>>
>> This didn't make it in before, so updating to 2.6.39-rc2 and resending:
>>
>> Prevent needless exporting of internal functions from
This didn't make it in before, so updating to 2.6.39-rc3 and resending:
Prevent needless exporting of internal functions from compilation units by
marking them static.
---
fs/btrfs/ctree.c |2 +-
fs/btrfs/disk-io.c |2 +-
fs/btrfs/extent-tree.c |4 ++--
fs/btrfs/inode.c
Fix address space annotation.
---
fs/btrfs/ioctl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index de76a6d..2b1e53e 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2287,7 +2287,7 @@ static long btrfs_ioctl_space_info(s
> -static inline void btrfs_descending_sort_devices(
> - struct btrfs_device_info *devices,
> - size_t nr_devices)
> -{
> - sort(devices, nr_devices, sizeof(struct btrfs_device_info),
> - btrfs_
6112 14165978 14166000 32
1726144 14165988 14166009 2850 eof
sdhci.ppm: 170 extents found
--- [2]
# btrfs filesystem defragment -c sdhci.ppm
# filefrag -v sdhci.ppm
Filesystem type is: 9123683e
File size of sdhci.ppm is 36838232 (8994 blocks, blocksize 4096)
ext logical physical expecte
ems to work fine on 2.6.39-rc5; I mounted with '-o
compress,clear_cache' though.
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
If posix_acl_from_xattr() returns an error code, a negative address is
dereferenced causing an oops; fix by checking for error code first.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/acl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/acl.c b/fs/btrfs
If posix_acl_from_xattr() returns an error code, a negative address is
dereferenced causing an oops; fix by checking for an error code first.
Typo fixed; too much late-night coding.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/acl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions
55 48 89
RIP [] merge_reloc_roots+0x273/0x280 [btrfs]
RSP
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3.13-rc5, it's possible to remount a mounted BTRFS filesystem with
'nobarrier', but not possible to remount with 'barrier'.
Is this expected?
Many thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
b9 04 00 00 00 f6 c2 02 74 0e 44 0f
RIP [] __btrfs_write_out_cache+0x3e4/0x8e0
RSP
CR2: 000000200000
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
04 00 00 00 f6 c2 02 74 0e 44 0f
RIP [] __btrfs_write_out_cache+0x3e4/0x8e0
RSP
CR2: 000000200000
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
]
[] __do_page_cache_readahead+0x1b9/0x270
[] ondemand_readahead+0x152/0x2a0
[] page_cache_sync_readahead+0x31/0x50
[] generic_file_aio_read+0x4c5/0x700
[] do_sync_read+0x5a/0x90
[] vfs_read+0x95/0x160
[] SyS_read+0x49/0xa0
[] tracesys+0xe1/0xe6
--
Daniel J Blueman
--
To unsubscribe from this list: send
On 12 April 2011 00:07, Daniel J Blueman wrote:
> On 11 April 2011 23:32, Josef Bacik wrote:
>> On 04/10/2011 04:29 AM, Daniel J Blueman wrote:
>>>
>>> When rebooting from a crash, thus during log replay on 2.6.29-rc2,
>>> btrfs_insert_dir_item caused
Hi Chris,
On 4 May 2011 22:40, Josef Bacik wrote:
> On 05/03/2011 10:54 PM, Daniel J Blueman wrote:
>>
>> If posix_acl_from_xattr() returns an error code, a negative address is
>> dereferenced causing an oops; fix by checking for an error code first.
>>
>> Typo
gt;
> Hi Josef
>
> Forgive me as i am a 'storage guy' - so when you say pull down linus's
> git tree and test do you mean grab the latest kernel? i know very
> stupid question, but just want to make sure i get it right... if so,
> then yes i will and i will add s
180
[] kernel_thread_helper+0x4/0x10
[] ? finish_task_switch+0x77/0x100
[] ? retint_restore_args+0xe/0xe
[] ? __init_kthread_worker+0x70/0x70
[] ? gs_change+0xb/0xb
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
On 10 April 2011 16:29, Daniel J Blueman wrote:
> When rebooting from a crash, thus during log replay on 2.6.29-rc2,
> btrfs_insert_dir_item caused an assertion failure [1]. The fs was
> being mounted clear_cache on an SSD.
On 3.0-rc1 with a fresh filesystem, after a few crashes with o
> [ 15.004255] kernel BUG at fs/btrfs/inode.c:4676!
[]
I've been experiencing the same issue also.
Josef/Chris, would an metadata snapshot or full block snapshot help
debug this regression? I can probably setup a small testcase to
trigger this.
Thanks,
Daniel
--
Daniel J Blueman
--
I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
If lookup_extent_backref fails, path->nodes[0] reasonably could be
null, so look before leaping [2].
Chris, if happy, can you squeeze this into the drop for -rc4 please?
Signed-off-by: Daniel J Blueman
--- [1]
l
One of the casts in ioctl.c loses the __user annotation; cast so it is
correctly maintained.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a3c4751..79c32d8 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2708,7 +2708,7 @@ long
On 23 June 2011 18:31, David Sterba wrote:
> Hi,
>
> On Sun, Jun 19, 2011 at 06:53:28PM +0800, Daniel J Blueman wrote:
>> I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
>>
>> If lookup_extent_backref fails, path->nodes[0] reasonably co
rr = generic_write_checks(file, &pos, &count, S_ISBLK(inode->i_mode));
if (err)
goto out_nolock;
if (count == 0)
goto out_nolock;
err = remove_suid(fdentry(file)); <---
--
Daniel J Blueman
--
To unsubscribe from this list: send t
On Fri, Jul 4, 2008 at 2:11 PM, Yan Zheng <[EMAIL PROTECTED]> wrote:
> 2008/7/4 Daniel J Blueman <[EMAIL PROTECTED]>:
>> Having done a current checkout, creating a new FS and running iozone
>> [1] on it results in an oops [2]. remove_suid is called, accessing
>
aniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d idea for btrfsprogs
also, if not already available?
Daniel
--- [1]
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to major
tic inline struct btrfs_inode *BTRFS_I(struct inode *inode)
{
return container_of(inode, struct btrfs_inode, vfs_inode);
}
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
mov %rdx,-0x80(%rcx)
--- [3]
static inline struct btrfs_inode *BTRFS_I(struct inode *inode)
{
return container_of(inode, struct btrfs_inode, vfs_inode);
}
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
[] __btrfs_end_transaction+0x59/0x130
[] btrfs_end_transaction+0xb/0x10
--- [2] fs/btrfs/extent_io.c:46
static struct kmem_cache *extent_state_cache;
static struct kmem_cache *extent_buffer_cache
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the b
On Fri, Aug 14, 2009 at 5:35 PM, Catalin Marinas wrote:
> Daniel J Blueman wrote:
>> There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
>> [1] are false-positives, due to the overwriting of the static pointers
>> [2]. Does this ring true with anyone else
118456832
Is it better to not trust compression, autodefrag, or is this
filesystem corruption from previous issues, so I should rebuild the
FS?
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
you'd like the
stacktrace, as I can resolve the symbols by hand.
Many thanks,
Daniel
--- [1]
WARN_ON(!(entry->vfs_inode.i_state & (I_WILL_FREE | I_FREEING | I_CLEAR)));
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
'm using. Also see my
> postings on this very issue here, top two entries:
>
> http://axboe.livejournal.com/
>
> So that pretty much looks like it reaffirms some of my suspicions. Is
> the drive in a laptop that you suspend and resume?
If you're on firmware < 1.30,
On Wed, Sep 9, 2009 at 9:26 AM, Jens Axboe wrote:
> On Wed, Sep 09 2009, Daniel J Blueman wrote:
>> On Wed, Sep 9, 2009 at 8:01 AM, Jens Axboe wrote:
>> > On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
>> >> On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrot
On Sep 20, 11:50 am, wbr...@gmail.com wrote:
> On Sun, Sep 20, 2009 at 3:47 AM, Daniel J Blueman
>
> wrote:
> > On Sep 19, 7:20 pm, wbr...@gmail.com wrote:
>
> >> RAID details:
> >>
> >> md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1]
> >&g
hout closing the transaction, is there a way to drop the
reference/'deallocate' the new tree nodes, thus moving back to the
prior state? Presumably the new tree nodes would get linked in when
the transaction is closed.
--
Daniel J Blueman
--
To unsubscribe from this list: send the line &qu
M to mange the array, then see if performance under write load
is better, and with or without writeback caching...
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
For now, exposing this via an IOCTL may be sufficient, though any
ideas for introducing it in a more standard way? (it's a pity that
when stat64 was introduced, reserved fields weren't added)
Thanks,
Daniel
[1] http://www.research.ibm.com/haifa/satran/ips/Vince-Luben-crc32c-01.
On Wed, Jan 27, 2010 at 12:30 PM, Andi Kleen wrote:
> Daniel J Blueman writes:
>
>> For purposes of data deduplication and data synchronisation, it would
>> be a powerful tool to expose file data checksums.
>>
>> Since eg BTRFS uses the crc32c algorithm [1], i
affect just array reconstruction, not general I/O
performance/throughput, so affect just an edge-case of applications
requiring maximum latency/minimum throughout guarantees.
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
o the filesystem identified by \fI\fR.
> +.PP
> +
> +.SH EXIT STATUS
> +\fBbtrf\fR returns a zero exist status if it succeeds. Non zero is returned
> in
> +case of failure.
> +
> +.SH AVAILABILITY
> +.B btrfs
> +is part of btrfs-progs. Btrfs filesystem is currently under
ntarg;
> int ret = 0;
>
> @@ -143,6 +143,7 @@ int btrfs_parse_options(struct btrfs_root *root, char
> *options)
> if (!options)
> return -ENOMEM;
>
> + orig = options;
>
> while ((p = strsep(&options, ",")) != NULL) {
&g
read' does the opposite, where
RMW cycles are higher penalty. Elsewhere IIRC, Chris also said BTRFS
attempts to submit 128KB BIOs where possible (or wishful thinking?):
http://markmail.org/message/4sq4uco2lghgxzzz
--
Daniel J Blueman
--
To unsubscribe from this list: send the line &quo
may be
an obvious difference. Also, for metadata-write-intensive workloads,
when creating the filesystem try 'mkfs.btrfs -m single'. Of course,
all this doesn't explain the variance.
I'd say it's worth emplying 'blktrace' to see what happening at a
lower leve
property of B-trees, which guarantees
>>> non-zero utilization, has been lost, and I don't see in Btrfs code any
>>> substitution for this property. In other words, where is a formal
>>> guarantee that all disk space of our users won't be eaten by internal
>&g
normal hardlinks). So I would end up with duplicated
> files.
>
> What is the correct way to do this?
The only way to do this preserving duplication is to use hardlinks
between duplicated files (which reference counts the inode), and use
'rsync -H'.
Dan
--
Daniel J Blueman
--
To unsub
s:
$ sudo -s
# dmesg -c >/dev/null
# echo t >/proc/sysrq-trigger
# dmesg >backtraces.txt
(there are other ways with
The problem is that you'll be taking instantaneous snapshots, which
may or may not be representative of the main looping, but over a few
shots should be.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 110 matches
Mail list logo
