On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and
will
adjust as necessary.
So I just looked at this with an eye to validating an
On Wed, Jun 29, 2011 at 04:53:07PM +1000, Dave Chinner wrote:
On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and
will
adjust as
On 06/27/2011 07:46 AM, NeilBrown wrote:
On Thu, 23 Jun 2011 12:53:37 +0200 Nico Schottelius
nico-lkml-20110...@schottelius.org wrote:
Good morning devs,
I'm wondering whether the raid- and volume-management-builtin of btrfs is
actually a sane idea or not.
Currently we do have
On 29/06/11 08:40, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 04:53:07PM +1000, Dave Chinner wrote:
On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports
On Wed, Jun 29, 2011 at 02:00:20PM +0800, Li Zefan wrote:
Hugo Mills wrote:
@@ -2149,6 +2150,10 @@ int btrfs_balance(struct btrfs_root *dev_root)
bal_info-completed, bal_info-expected);
}
ret = 0;
+ if (bal_info-cancel_pending) {
+
On Wed, 2011-06-29 at 10:29 +0100, Ric Wheeler wrote:
On 06/27/2011 07:46 AM, NeilBrown wrote:
On Thu, 23 Jun 2011 12:53:37 +0200 Nico Schottelius
nico-lkml-20110...@schottelius.org wrote:
Good morning devs,
I'm wondering whether the raid- and volume-management-builtin of btrfs is
On 06/29/2011 02:53 AM, Dave Chinner wrote:
On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and will
adjust as necessary.
So I just
Hiya,
I've got a btrfs FS with 84 subvolumes in it (some created
with btrfs sub create, some with btrfs sub snap of the other
ones). There's no nesting of subvolumes at all (all direct
children of the root subvolume).
The btrfs subvolume list is only showing 80 subvolumes. The 4
missing ones (1
2011-06-29 15:37:47 +0100, Stephane Chazelas:
[...]
I found
http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
which looks like the same issue, with Li Zefan saying he had a
fix, but I couldn't find any mention that it was actually fixed.
Has anybody got any update on
On 06/27/2011 05:21 PM, Hubert Kario wrote:
On Monday 27 of June 2011 11:04:06 Proskurin Kirill wrote:
Hello all.
What we have:
SL6 - kernel 2.6.32-131.2.1.el6.x86_64
btrfs on mdadm RAID5 with 8 HDD - 27T partition.
I see this at top:
1182 root 20 0 000 R 100.0 0.0
On 06/29/2011 11:00 AM, Stephane Chazelas wrote:
2011-06-29 15:37:47 +0100, Stephane Chazelas:
[...]
I found
http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
which looks like the same issue, with Li Zefan saying he had a
fix, but I couldn't find any mention that it was
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
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
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 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
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
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
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
On Wed, Jun 29, 2011 at 12:16:06PM -0400, Josef Bacik wrote:
On 06/29/2011 11:00 AM, Stephane Chazelas wrote:
2011-06-29 15:37:47 +0100, Stephane Chazelas:
[...]
I found
http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
which looks like the same issue, with Li
On Wed, Jun 29, 2011 at 05:47:41PM +0100, Hugo Mills wrote:
(*) The limited cases where both behaviours return the same set of
keys are:
(i_0, 0, 0) to (i_1, -1UL, -1UL)
I clearly meant (i_1, 255, -1UL) here...
(i, t_0, 0) to (i, t_1, -1UL)
(i, t, o_0) to (i, t, o_1)
--
=== Hugo Mills:
On 06/29/2011 12:40 AM, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 04:53:07PM +1000, Dave Chinner wrote:
On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs
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
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
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
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
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 |
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
Hi Hugo
On 06/29/2011 06:47 PM, Hugo Mills wrote:
On Wed, Jun 29, 2011 at 12:16:06PM -0400, Josef Bacik wrote:
On 06/29/2011 11:00 AM, Stephane Chazelas wrote:
2011-06-29 15:37:47 +0100, Stephane Chazelas:
[...]
I found
http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
On 06/29/2011 04:10 PM, Arne Jansen wrote:
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
On 06/29/2011 04:10 PM, Arne Jansen wrote:
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
On 06/29/2011 04:10 PM, Arne Jansen wrote:
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
You can add
Reviewed-by: Josef Bacik jo...@redhat.com
Thanks,
Josef
--
To unsubscribe from
On 29/06/11 18:29, Sunil Mushran wrote:
On 06/29/2011 03:42 AM, Pádraig Brady wrote:
There is the argument, that if this interface can distinguish
these dirty unwritten extents, then why can't the fiemap interface too?
The advantage of the fiemap interface is that it can distinguish
empty
On 06/29/2011 04:10 PM, Arne Jansen wrote:
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
Stephane Chazelas wrote:
2011-06-29 15:37:47 +0100, Stephane Chazelas:
[...]
I found
http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208
which looks like the same issue, with Li Zefan saying he had a
fix, but I couldn't find any mention that it was actually fixed.
Has
34 matches
Mail list logo
