On Thu, May 16, 2013 at 02:11:41PM -0500, Kyle Gates wrote:
and mounted with autodefrag
Am I actually just seeing large ranges getting split while remaining
contiguous on disk? This would imply crc calculation on the two
outside ranges. Or perhaps there is some data being inlined for each
HI,
You should check the patchset about VFS hot tracking
https://lwn.net/Articles/550495/
On Thu, May 16, 2013 at 3:12 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Hi!
I think such a solution as part of the filesystem could do much better than
something outside of it (like bcache).
We need to unlock and free extent buffer before the return.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/relocation.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 704a1b8..5c5b8bb 100644
---
On Fri, 17 May 2013 16:45:44 +0800, Liu Bo wrote:
We need to unlock and free extent buffer before the return.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/relocation.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/relocation.c
On Fri, May 17, 2013 at 10:52:16AM +0200, Stefan Behrens wrote:
On Fri, 17 May 2013 16:45:44 +0800, Liu Bo wrote:
We need to unlock and free extent buffer before the return.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/relocation.c |2 +-
1 files changed, 1
oops, please ignore this as there is already a same patch from Stefan.
Sorry for the trouble.
thanks,
liubo
On Fri, May 17, 2013 at 04:45:44PM +0800, Liu Bo wrote:
We need to unlock and free extent buffer before the return.
Signed-off-by: Liu Bo bo.li@oracle.com
---
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part
The idea was to introduce /dev/mapper to find for btrfs disk,
However I found first we need to congregate the disk scan
procedure at a function so it would help to consistently tune
it across the btrfs-progs. As of now both fi show and
dev scan use the disks scan they do it on their own.
So here
So update the usage and man page
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 2 +-
man/btrfs.8.in| 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 6ba27ad..470de31 100644
---
btrfs_scan_for_fsid uses only one argument run_ioctl out of 3
so remove the rest two of them
and also update to use the new function
scan_devs_for_btrfs
Signed-off-by: Anand Jain anand.j...@oracle.com
---
btrfs-find-root.c | 2 +-
disk-io.c | 2 +-
utils.c | 12 +++-
Currently, btrsf fi show uses
/proc/partitions (by default) (with priority given
to dm-x over sdy paths) and with -d option would scan
/dev only (with /dev/mapper skipped since its a link).
However using /dev/mapper paths are in common practice
with mount, fstab, and lvm, so its better to be
The btrfs fi show --all-devices is odd man out as compared to the
rest of the command line options with in btrfs-progs. So match it
with the btrfs-progs symantics
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 18 ++
man/btrfs.8.in| 6 +++---
2 files
On Fri, 17 May 2013 18:54:38 +0800, Anand Jain wrote:
The idea was to introduce /dev/mapper to find for btrfs disk,
However I found first we need to congregate the disk scan
procedure at a function so it would help to consistently tune
it across the btrfs-progs. As of now both fi show and
Just scan /dev/block/*. That contains all block devices.
Oh, this is about finding nicer names. Never mind.
--
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
In some cases the extent tree can just be so gone there is no point in trying to
figure out how to put it back together. So add a --init-extent-tree mode which
will zero out the extent tree and then re-add extents for all of the blocks we
find. This will also undo any balance that was going on
On Fri, 17 May 2013 15:04:45 +0800, Liu Bo wrote:
On Thu, May 16, 2013 at 02:11:41PM -0500, Kyle Gates wrote:
and mounted with autodefrag
Am I actually just seeing large ranges getting split while remaining
contiguous on disk? This would imply crc calculation on the two
outside ranges. Or
On Thu, May 16, 2013 at 09:19 (+0200), Kai Krakow wrote:
3.9.2 still does not fix anything. I'll go with autodefrag=off for the
moment until I hear some news in that regard. With this new information, is
it still helpful to get a metadata image from me? It should be reproducable
if you
Hey Christian,
On Fri, May 17, 2013 at 05:02:21AM -0700, Christian Kujau wrote:
a while ago I was setting reading extended attributes to ~25000 files
in a directory structure on an XFS filesystem. The files were usually a
few MB in size, but some where up to 2GB in size.
Anyway, I *felt*
On Thu, May 16, 2013 at 08:09:18AM -0700, Marc MERLIN wrote:
I've reported this bug a few times over different kernel versions over the
last year now, and unfortunately it's still not fixed as of 3.8 (yes, I know
3.9 is out, I'm just about to switch).
What happens as far as I know:
I have
On Thu, May 16, 2013 at 09:09:18AM -0600, Marc MERLIN wrote:
I've reported this bug a few times over different kernel versions over the
last year now, and unfortunately it's still not fixed as of 3.8 (yes, I know
3.9 is out, I'm just about to switch).
What happens as far as I know:
I have
If we fail to load the chunk tree we'll call free_root_pointers, except we may
not have assigned the roots for the dev_root/extent_root/csum_root yet, so we
could NULL pointer deref at this point. Just add checks to make sure these
roots are set to keep us from panicing. Thanks,
Signed-off-by:
On Fri, May 17, 2013 at 12:54:56PM -0400, Josef Bacik wrote:
If so, could you add this to the list of things to fix to make btrfs a bit
less scary to others? :)
(and of course more production ready, this repeated problem would kill any
server it happens on)
This has been all fixed in
On Fri, May 17, 2013 at 07:25:12PM -0600, Marc MERLIN wrote:
On Fri, May 17, 2013 at 12:54:56PM -0400, Josef Bacik wrote:
If so, could you add this to the list of things to fix to make btrfs a bit
less scary to others? :)
(and of course more production ready, this repeated problem would
On 17/05/2013 19:21, Gabriel de Perthuis wrote:
On Fri, 17 May 2013 18:54:38 +0800, Anand Jain wrote:
The idea was to introduce /dev/mapper to find for btrfs disk,
However I found first we need to congregate the disk scan
procedure at a function so it would help to consistently tune
it across
25 matches
Mail list logo
