8801c766db18
--
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
--
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 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 majord...@vger.kernel.org
More
, 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 info at http://vger.kernel.org/majordomo-info.html
[811c4129] __btrfs_end_transaction+0x59/0x130
[811c421b] 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
On Fri, Aug 14, 2009 at 5:35 PM, Catalin Marinascatalin.mari...@arm.com wrote:
Daniel J Blueman daniel.blue...@gmail.com 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
in certain circumstances
http://www.ocztechnologyforum.com/forum/showthread.php?t=57516
--
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 Wed, Sep 9, 2009 at 9:26 AM, Jens Axboejens.ax...@oracle.com wrote:
On Wed, Sep 09 2009, Daniel J Blueman wrote:
On Wed, Sep 9, 2009 at 8:01 AM, Jens Axboejens.ax...@oracle.com wrote:
On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe
On Sep 20, 11:50 am, wbr...@gmail.com wrote:
On Sun, Sep 20, 2009 at 3:47 AM, Daniel J Blueman
daniel.blue...@gmail.com wrote:
On Sep 19, 7:20 pm, wbr...@gmail.com wrote:
RAID details:
md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1]
62925824 blocks 256K chunks 2 far-copies
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
/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 24 February 2011 20:48, liubo liubo2...@cn.fujitsu.com 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,
After digging
Correctly unlock delayed_refs in the error case.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
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
Prevent needless exporting of internal functions from compilation
units by marking them static.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
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
taken, thus bio_endio doesn't call the function
which would free it in the normal case. Fix.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0efdb65..53f4c8e 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6056,6 +6056,7
/0x1b0 [btrfs]
RSP 880303a0bbc0
CR2:
---[ end trace a7919e7f17c0a728 ]---
note: btrfs-delalloc-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
+0x9d/0x590
[8113943f] ? fget_light+0x1df/0x3c0
[8114a97a] ? sys_ioctl+0x4a/0x80
[81002dfb] ? 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
[8116bb43] vfs_fsync_range+0x73/0x90
[81141470] ? fget_raw+0x260/0x260
[8116bbb7] vfs_fsync+0x17/0x20
[8116bbf5] do_fsync+0x35/0x60
[8116bc4b] sys_fsync+0xb/0x10
[816edf3b] system_call_fastpath+0x16/0x1b
---[ end trace a7919e7f17c0a728 ]---
--
Daniel J
[812c9ec0] btrfs_ioctl+0x450/0x590
[81152e8d] do_vfs_ioctl+0x8d/0x330
[8114148f] ? fget_light+0x2bf/0x3c0
[8109629d] ? trace_hardirqs_on_caller+0x14d/0x190
[8115317a] sys_ioctl+0x4a/0x80
[81709ffb] system_call_fastpath+0x16/0x1b
--
Daniel J Blueman
8803057817f0
---[ 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.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Josef, Chris,
On 8 April 2011 00:23, Josef Bacik jo...@redhat.com 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 [] and an assertion
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
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 daniel.blue...@gmail.com
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index
Fix address space annotation correct in ioctl.c.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
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
On 11 April 2011 23:32, Josef Bacik jo...@redhat.com 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 an SSD.
Probably it's
On 11 April 2011 23:45, Josef Bacik jo...@redhat.com 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 compilation
units by marking them static
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
start,
u64 end, u64 *length);
btrfs_cmp_device_free_bytes() can be marked static, since there are no
users outside the compilation unit.
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
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 daniel.blue...@gmail.com
---
fs/btrfs/acl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs
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 daniel.blue...@gmail.com
---
fs/btrfs/acl.c |5 +++--
1 files changed, 3
On 12 April 2011 00:07, Daniel J Blueman daniel.blue...@gmail.com wrote:
On 11 April 2011 23:32, Josef Bacik jo...@redhat.com 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
Hi Chris,
On 4 May 2011 22:40, Josef Bacik jo...@redhat.com 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 fixed; too much late-night
://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/
(eg kernel-default-2.6.38.6-1.1.x86_64.rpm)
You'll probably have to download dependent RPMs from there too.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
/0x10
[81048a47] ? finish_task_switch+0x77/0x100
[8171afc4] ? retint_restore_args+0xe/0xe
[8107ddf0] ? __init_kthread_worker+0x70/0x70
[8171c890] ? gs_change+0xb/0xb
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
On 10 April 2011 16:29, Daniel J Blueman daniel.blue...@gmail.com 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
/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
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
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 daniel.blue
One of the casts in ioctl.c loses the __user annotation; cast so it is
correctly maintained.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
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
[81157f51] page_cache_sync_readahead+0x31/0x50
[8114d655] generic_file_aio_read+0x4c5/0x700
[811b671a] do_sync_read+0x5a/0x90
[811b6db5] vfs_read+0x95/0x160
[811b78c9] SyS_read+0x49/0xa0
[81715bff] tracesys+0xe1/0xe6
--
Daniel J Blueman
--
To unsubscribe
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.pdf
--
Daniel J Blueman
On Wed, Jan 27, 2010 at 12:30 PM, Andi Kleen a...@firstfloor.org wrote:
Daniel J Blueman daniel.blue...@gmail.com 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], it's
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 of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
)
}
}
out:
- kfree(options);
+ kfree(orig);
return ret;
}
The patch is good, and the same as I was testing to fix this issue I
found a day before with -rc8.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux
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 unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
'. Of course,
all this doesn't explain the variance.
I'd say it's worth emplying 'blktrace' to see what happening at a
lower level, and even eg varying between deadline/CFQ I/O schedulers.
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
some good discussion with potential to improve from
where we are.
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
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 unsubscribe from this list: send the line unsubscribe linux
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
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
On 25 July 2010 15:42, Josef Bacik jo...@redhat.com 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 of
'dip' fails, which
Hi Chris,
On 25 July 2010 15:42, Josef Bacik jo...@redhat.com 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 of
'dip
to time performing kernel rebuilds over NFS.
I've CC'd Trond on the full email to see if it rings a bell. The best
outcome may be if we write a micro-reproducer which exploits this race
using cached data.
Thanks,
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line
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 any debug, however,
here's sysrq's and perf data from my very slow running backups. I also
did a test
))
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 daniel.blue...@gmail.com
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 558cac2..312eeb7 100644
--- a/fs
?
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 first copy.
Daniel
--
Daniel J
it allow ls to return?
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
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 body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 July 2012 12:20, Liu Bo liubo2...@cn.fujitsu.com 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
On 11 July 2012 09:37, Liu Bo liubo2...@cn.fujitsu.com wrote:
On 07/10/2012 08:18 PM, Daniel J Blueman wrote:
On 2 July 2012 12:20, Liu Bo liubo2...@cn.fujitsu.com 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
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 [a00fb327] __add_tree_block.part.54+0xe7/0xf0 [btrfs]
RSP 88021bbb9ad8
--
Daniel J Blueman
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 [a061c3ca] lookup_inline_extent_backref+0x2ea/0x400 [btrfs]
RSP 88021f7038d0
--
Daniel J Blueman
--
To unsubscribe from this list: send
/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 majord...@vger.kernel.org
More
On 21 March 2012 00:16, Andrea Gelmini andrea.gelm...@gmail.com wrote:
2012/3/20 Daniel J Blueman dan...@quora.org:
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
umount /mnt
mount
=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
access beyond end of device and livelock
--
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
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 from this list: send
On 9 April 2012 22:44, Leho Kraav l...@kraav.com wrote:
On 09.04.2012 17:35, Daniel J Blueman wrote:
Leho Kraavlehoat kraav.com writes:
[]
Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond end
of device
Apr 8 02:46:11 s9 kernel: [ 189.691787] dm-3: rw=129, want
] aio_run_iocb+0x5e/0x150
[8115d265] io_submit_one+0x175/0x220
[8115d6d9] do_io_submit+0x129/0x1c0
[8115d77b] sys_io_submit+0xb/0x10
[815ad122] system_call_fastpath+0x16/0x1b
--
Daniel J Blueman
--
To unsubscribe from this list: send the line unsubscribe linux
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 dan...@quora.org
---
fs/btrfs/relocation.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index
be 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 dan...@quora.org
Reviewed-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/relocation.c |2 +-
1 file changed, 1 insertion(+), 1
Correctly drop locks during error cases.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
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
Address some minor type issues identified by sparse checker.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
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
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
On 2 May 2012 22:01, Jeff Mahoney je...@suse.com 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 like:
--- a/fs/btrfs
Fix control flow to store count before breaking loop.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
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
On 3 May 2012 22:04, David Sterba d...@jikos.cz 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.
Noted.
Chris
Fix BTRFS messages to print a newline where there should be one.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
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
Fix various messages to include newline and module prefix.
Signed-off-by: Daniel J Blueman dan...@quora.org
---
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
] do_vfs_ioctl+0x87/0x340
[81128a6a] sys_ioctl+0x4a/0x80
[815b09a2] 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
] ? lockdep_sys_exit_thunk+0x35/0x67
[81130c8a] sys_ioctl+0x4a/0x80
[815bc622] 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
On 2 July 2012 21:34, Josef Bacik jba...@fusionio.com 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:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux
--
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 4 July 2012 13:19, Liu Bo liubo2...@cn.fujitsu.com 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/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus
: 0020
--
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
: 0020
--
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
the
FS?
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
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 in
the body of a message to majord
90 matches
Mail list logo
