Scrub starts the workers each time a scrub starts and stops them after it
finished. This patch adds an initialization for the workers before each
start, otherwise the workers behave strangely.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/disk-io.c |2 --
fs/btrfs/scrub.c |6
read_extent_buffer_pages currently has two modes, either trigger a read
without waiting for anything, or wait for the I/O to finish. The former
also bails when it's unable to lock the page. This patch now adds an
additional parameter to allow it to block on page lock, but don't wait
for
Add state information for readahead to btrfs_fs_info and btrfs_device
Changes v2:
- don't wait in radix_trees
- add own set of workers for readahead
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/ctree.h |5 +
fs/btrfs/disk-io.c | 11 +++
fs/btrfs/volumes.c |
This series introduces a generic readahead interface for btrfs trees.
The intention is to use it to speed up scrub in a first run, but balance
is another hot candidate. In general, every tree walk could be accompanied
by a readahead. Deletion of large files comes to mind, where the fetching
of the
Add a READAHEAD extent buffer flag.
Add a function to trigger a read with this flag set.
Changes v2:
- use extent buffer flags instead of extent state flags
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/disk-io.c | 32
fs/btrfs/disk-io.h |2
This is the implementation for the generic read ahead framework.
To trigger a readahead, btrfs_reada_add must be called. It will start
a read ahead for the given range [start, end) on tree root. The returned
handle can either be used to wait on the readahead to finish
(btrfs_reada_wait), or to
This ioctl is added to trigger a readahead from user mode. It implements
a readahead using the new interface and also a traditional tree walk.
This way it's possible to measure the two side by side.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/ioctl.c | 93
This adds the hooks needed for readahead. In the readpage_end_io_hook,
the extent state is checked for the EXTENT_READAHEAD flag. Only in this
case the readahead hook is called, to keep the impact on non-ra as low
as possible.
Additionally, a hook for a failed IO is added, otherwise readahead
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/scrub.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 92cac19..a8d03d5 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -16,13 +16,7 @@
* Boston, MA
Scrub uses a simple tree-enumeration to bring the relevant portions
of the extent- and csum-tree into the page cache before starting the
scrub-I/O. This is now replaced by using the new readahead-API.
During readahead the scrub is being accounted as paused, so it won't
hold off transaction
On 06/09/2011 10:06 PM, Daniel J Blueman wrote:
On 10 June 2011 09:57, Andy Lutomirski l...@mit.edu wrote:
On 06/06/2011 06:19 AM, Marek Otahal wrote:
Hello,
the issue happens every time when i have to hard power-off my notebook
(suspend problems).
With kernel 2.6.39 the partition is
David Sterba wrote:
Hi,
a candidate fix:
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
With Linus' tree, today's linux-next build (powercp ppc64_defconfig)
produced this warning:
fs/btrfs/delayed-inode.c: In
On Thu, Jun 09, 2011 at 08:00:15PM +0200, David Sterba wrote:
On Thu, Jun 09, 2011 at 10:00:42AM -0400, Josef Bacik wrote:
We're not trying to be perfect here, we're trying to be fast :).
Be even faster with smp_rmb() :)
Arne made me think about this again. Let's analyze it in more detail:
On 06/10/2011 01:47 PM, David Sterba wrote:
On Thu, Jun 09, 2011 at 08:00:15PM +0200, David Sterba wrote:
On Thu, Jun 09, 2011 at 10:00:42AM -0400, Josef Bacik wrote:
We're not trying to be perfect here, we're trying to be fast :).
Be even faster with smp_rmb() :)
Arne made me think about
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those should be fixed in rc2.
When I did my bisection, my criteria for success/failure was
did mkcephfs succeed?. When I apply
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those should be fixed in rc2.
When I did my bisection, my criteria for
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those should be fixed in rc2.
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in btrfs were from the uninit variables and
those
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs crashes ]
I think your two crashes in
On 06/10/2011 02:35 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of 2011-06-10 13:06:22 -0400:
[ two different btrfs
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:35 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's message of
Excerpts from Josef Bacik's message of 2011-06-10 14:34:21 -0400:
On 06/10/2011 02:35 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim
On Fri, Jun 10, 2011 at 2:43 PM, Marek Otahal markota...@gmail.com wrote:
The test-case is quite easy,
1. mount the FS, just with compress-force=lzo option // I didn't try without,
but on my other btrfs partition that doesn't use compression the err never
happened ...so, can the others who
Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:35 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Josef Bacik wrote:
On 06/10/2011 02:14 PM, Sage Weil wrote:
On Fri, 10 Jun 2011, Sage Weil wrote:
On Fri, 10 Jun 2011, Chris Mason wrote:
Excerpts from Jim Schutt's
We used to store the checksums of the space cache directly in the space cache,
however that doesn't work out too well if we have more space than we can fit the
checksums into the first page. So instead use the normal checksumming
infrastructure. There were problems with doing this originally but
On 06/10/2011 02:43 PM, Marek Otahal wrote:
On Friday 10 of June 2011 15:33:20 Josef Bacik wrote:
On 06/09/2011 10:06 PM, Daniel J Blueman wrote:
On 10 June 2011 09:57, Andy Lutomirski l...@mit.edu wrote:
On 06/06/2011 06:19 AM, Marek Otahal wrote:
Hello,
the issue happens every time when i
On Friday 10 of June 2011 16:52:36 Josef Bacik wrote:
On 06/10/2011 02:43 PM, Marek Otahal wrote:
On Friday 10 of June 2011 15:33:20 Josef Bacik wrote:
On 06/09/2011 10:06 PM, Daniel J Blueman wrote:
On 10 June 2011 09:57, Andy Lutomirski l...@mit.edu wrote:
On 06/06/2011 06:19 AM, Marek
Dear all,
(please Cc)
yesterday I had two bugs with btrfs and ext3 occurrences, always happening
when plugging in an external USB btrfs disk.
Today I had a BUG which is purely ext3 related.
The last bug was with yesterdays latest git checkout.
Here are the three bugs/oops:
that one was with
28 matches
Mail list logo
