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
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
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
]
[] __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 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"
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
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
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&
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 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
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 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:
>> >
>>
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
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
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
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
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
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 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 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
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
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
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
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
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
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
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
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
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
>>>
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
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
/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
=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
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
[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
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
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
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
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
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
> [ 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
--
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
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
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
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
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
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
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
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
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
> -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_
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
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
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
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
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
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
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 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
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.
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..
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
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
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
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
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
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
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,
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
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
--
[] ? 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
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
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
&#
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
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
_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
--
.
>>
>> Also, using 'perf' may give a good picture of where the time is spent, eg:
>>
>> $ sudo perf record -a sleep 20
>> $ sudo perf report | tee profile.txt
>> --
>> Daniel J Blueman
>>
>
> The cleaner finished before I was able to get
ously they used 2.6.33, but an upgrade was
> forced due to an nfs bug under high write loads. However, it may be
> that the nature of the jobs that we are running now has changed
> slightly too.
I was experiencing a similar pattern of ESTALE issues with NFS with
2.6.33 (IIRC) and cached da
;ll see where you
> are spending your time based on the traces.
Also, using 'perf' may give a good picture of where the time is spent, eg:
$ sudo perf record -a sleep 20
$ sudo perf report | tee profile.txt
--
Daniel J Blueman
--
To unsubscribe from this list: send the line &qu
Hi Chris,
On 25 July 2010 15:42, Josef Bacik wrote:
> On Sat, Jul 24, 2010 at 12:01:59AM +0100, Daniel J Blueman wrote:
>> Hi Chris,
>>
>> This fixes some issues relating to direct I/O submission, however a
>> further patch will be needed to handle the case where a
6_64 GNU/Linux
> For ZFS: FreeBSD 8.1-RELEASE (GENERIC)
>
> (Note that we can currently not upgrade easily due to binary drivers for
> the SAS+SATA controllers :(. I'd be happy to push the vendor though, if
> you think it makes a difference.)
>
>
> Daniel J Blueman wro
/ssd6/iozone.tmp
> KB reclen write rewrite read reread
> 33554432 1024 1628475 1640349 943416 951135
Perhaps create a new filesystem and mount with 'nodatasum' - existing
extents which were previously created will be checked, so need to
start fres
On 25 July 2010 15:42, Josef Bacik wrote:
> On Sat, Jul 24, 2010 at 12:01:59AM +0100, Daniel J Blueman wrote:
>> Hi Chris,
>>
>> This fixes some issues relating to direct I/O submission, however a
>> further patch will be needed to handle the case where allocation
'dip' and double assignment.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 1bff92a..302e6d0 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5652,7 +5652,6 @@ static void btrfs_submit_direct(int rw, struct
bio *bio, struct inode *inode,
Hi Chris,
It looks like this was the intent - if not, perhaps drop the redundant
'nr = i' assignment?
---
Limit the number of items to insert (nr) to the available space in the BTRFS
leaf as intended.
Signed-off-by: Daniel J Blueman
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctr
o. One still around is the
Nvidia CK804/MCP55, under certain patterns of spatially-local pending
reads and writes to the memory controller, a 64-byte request would
occasionally be returned with the wrong offset. I was hitting it with
some 27-Gbit adapters and managed to capture it on a PCI-e protocol
analyser. Rsync between network and local disk would hit sometimes
too.
--
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
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
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
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
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
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
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
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
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
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
.
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.
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
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
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
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
1 - 100 of 110 matches
Mail list logo
