Hi Jon,
Is this what you are looking for?
After this, the CPU gets stuck and I have to reboot.
This issue has already been reported:
https://bugzilla.kernel.org/show_bug.cgi?id=59451
Regards, Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
TREE_SEARCH ioctl doesn't help in this case
the dev item don't provide all the info
that btrfs-progs might need in the long run
(and even the current needs).
Thanks, Anand
On 06/11/2013 10:24 PM, Josef Bacik wrote:
On Mon, Jun 10, 2013 at 08:59:15AM -0600, Anand Jain wrote:
This adds two
btrfs-progs has to read fs info from the kernel to
read the latest info instead of reading it from the disks,
which generally is a stale info after certain critical
operation.
getting used_bytes parameter will help to fix
btrfs filesystem show --kernel
to show the current info of the fs
This would help to reuse the function
v1-v2: removed static and updated .h file, in a preparation
work for the following patch
Signed-off-by: Anand Jain anand.j...@oracle.com
---
utils.c | 18 +-
utils.h | 1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff
This is a prepatory work for the following btrfs fi show command
fixes. So that we have a function get_df to get the fs sizes.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 146 +-
1 file changed, 79 insertions(+), 67
Code can be well reused and this is the prepatory work
for the patch following this.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 83 ---
ctree.h | 11
2 files changed, 59 insertions(+), 35
this is preparatory so that fsid found in the kernel can be
added
Signed-off-by: Anand Jain anand.j...@oracle.com
---
volumes.c | 20 +++-
volumes.h | 3 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/volumes.c b/volumes.c
index aa1c3dd..81904c6 100644
---
In an attempt to address the reviewer concern, and to
find a suitable solution to the btrfs-progs not been
able to in sync with the kernel changes, found a
solution which doesn't introduce new ioctl.
Along with it comes with new set of the dependent
patches viz 09/13 to 12/13. below.
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their last operation like,
labeling or device delete or add... etc.
This patch adds --kernel option to the 'filesystem show'
subcli, which will read from the kernel instead
btrfs-progs has to read fs info from the kernel to
read the latest info instead of reading it from the disks,
which generally is a stale info after certain critical
operation.
getting used_bytes parameter will help to fix
btrfs filesystem show --kernel
to show the current info of the fs
On Thu, 20 Jun 2013 12:47:04 -0700, Zach Brown wrote:
+/* for items that use the BTRFS_UUID_KEY */
+#define BTRFS_UUID_ITEM_TYPE_SUBVOL 0 /* for UUIDs assigned to subvols */
+#define BTRFS_UUID_ITEM_TYPE_RECEIVED_SUBVOL1 /* for UUIDs assigned
to
+
Quoting Jon Nelson (2013-06-20 21:46:46)
Is this what you are looking for?
After this, the CPU gets stuck and I have to reboot.
[360491.932226] [ cut here ]
[360491.932261] kernel BUG at
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Add one new mount option '-o hot_move' for hot
relocation support. When hot relocation is enabled,
hot tracking will be enabled automatically.
Its usage looks like:
mount -o hot_move
mount -o nouser,hot_move
mount -o nouser,hot_move,loop
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
This patchset can work well with the patchset v3 for VFS
hot tracking in RAID single mode now.
The patchset as RFC is sent out mainly to see if its design
goes in the correct development direction.
When working on this feature, i am trying to
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Add one list_head field 'reloc_list' to accommodate
hot relocation support.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
fs/hot_tracking.c| 1 +
include/linux/hot_tracking.h | 1 +
2 files changed, 2 insertions(+)
diff --git
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Add one private thread for hot relocation. It will check
if there're some extents which is hotter than the threshold
and queue them at first, if no, it will return and wait for
its next turn; otherwise, it will check if nonrotating disk
ratio is
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Introduce one new block group BTRFS_BLOCK_GROUP_DATA_NONROT,
which is used to differentiate if the block space is reserved
and allocated from one rotating disk or nonrotating disk.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
On Fri, Jun 21, 2013 at 6:30 AM, Chris Mason chris.ma...@fusionio.com wrote:
Quoting Jon Nelson (2013-06-20 21:46:46)
Is this what you are looking for?
After this, the CPU gets stuck and I have to reboot.
[360491.932226] [ cut here ]
[360491.932261] kernel BUG at
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Add three proc interfaces hot-reloc-interval, hot-reloc-threshold,
and hot-reloc-max-items under the dir /proc/sys/fs/ in order to
turn HOT_RELOC_INTERVAL, HOT_RELOC_THRESHOLD, and HOT_RELOC_MAX_ITEMS
into be tunable.
Signed-off-by: Zhi Yong Wu
On Tue, 18 Jun 2013 17:19:04 + (UTC)
Jon Nelson jnelson+bt...@jamponi.net wrote:
Josef Bacik jbacik at fusionio.com writes:
On Tue, Jun 11, 2013 at 11:43:30AM -0400, Sage Weil wrote:
I'm also seeing this hang regularly with both 3.9 and 3.10-rc5.
Is this is a known problem? In
On Tue, Jun 11, 2013 at 12:52:36AM +0100, Filipe David Borba Manana wrote:
If a device could not be opened in volumes.c:read_one_dev(), a
btrfs_device instance was allocated and added to the list of
devices of the fs - however this device instance had its fd,
name and label fields not
On Tue, Jun 11, 2013 at 12:52:36AM +0100, Filipe David Borba Manana wrote:
If a device could not be opened in volumes.c:read_one_dev(), a
btrfs_device instance was allocated and added to the list of
devices of the fs - however this device instance had its fd,
name and label fields not
Why do we need this btrfs_uuid_item structure? Why not set the key type
to either _SUBVOL or _RECEIVED_SUBVOL instead of embedding structs with
those types under items with the constant BTRFS_UUID_KEY. Then use the
item size to determine the number of u64 subids. Then the item has a
On Thu, Jun 20, 2013 at 06:08:29PM +0100, Filipe David Manana wrote:
Is there any reason why the btrfs progs (except for btrfs-show-super)
don't validate the super block's checksum?
btrfsck accepts broken filesystems, so open_ctree_broken should possibly
detect but skip the checksum mismatch.
Quoting Stefan Behrens (2013-06-21 04:47:20)
On Thu, 20 Jun 2013 12:47:04 -0700, Zach Brown wrote:
+/* for items that use the BTRFS_UUID_KEY */
+#define BTRFS_UUID_ITEM_TYPE_SUBVOL 0 /* for UUIDs assigned to subvols */
+#define BTRFS_UUID_ITEM_TYPE_RECEIVED_SUBVOL1 /* for UUIDs
On Fri, Jun 21, 2013 at 5:18 PM, David Sterba dste...@suse.cz wrote:
On Thu, Jun 20, 2013 at 06:08:29PM +0100, Filipe David Manana wrote:
Is there any reason why the btrfs progs (except for btrfs-show-super)
don't validate the super block's checksum?
btrfsck accepts broken filesystems, so
On Fri, Jun 21, 2013 at 5:11 PM, Liu Bo bo.li@oracle.com wrote:
--- a/volumes.c
+++ b/volumes.c
@@ -116,6 +116,7 @@ static int device_list_add(const char *path,
/* we can safely leave the fs_devices entry around */
return -ENOMEM;
Btrfs will default to mixed block groups for 1 gigabyte file systems and
smaller, which means data and metadata share the same area. This makes
generic/274 fail for us because we cannot reserve enough metadata space to do
our writes. Bumping the scratch fs up to 2 gigabytes allows us to do our
We always just try and reserve data space when we write, but if we are out of
space but have prealloc'ed extents we should still successfully write. This
patch will try and see if we can write to prealloc'ed space and if we can go
ahead and allow the write to continue. With this patch we now
On 6/21/13 3:30 PM, Josef Bacik wrote:
Btrfs will default to mixed block groups for 1 gigabyte file systems and
smaller, which means data and metadata share the same area. This makes
generic/274 fail for us because we cannot reserve enough metadata space to do
our writes. Bumping the scratch
hi,
i'm using Btrfs as a root partition. an hour ago i had a power failure
and the root btrfs would only mount ro. find below links to the relevant
btrfs-image, dmesg and kernel config.
used kernel when power failed: 3.9.0-1-desktop (from openSuse)
however following output from kernel:
A '\n' is missing.
Signed-off-by: Liu Bo bo.li@oracle.com
---
btrfs-image.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index 30c1a9a..ebd283e 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -2272,7 +2272,7 @@ static void
A device can be added to the device list without getting a name, so we may
access to illegal addresses while opening devices with their name.
Signed-off-by: Liu Bo bo.li@oracle.com
---
volumes.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/volumes.c b/volumes.c
Otherwise we will access illegal addresses while searching on fs_uuid list.
Signed-off-by: Liu Bo bo.li@oracle.com
---
disk-io.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 768adda..9cfd003 100644
--- a/disk-io.c
+++ b/disk-io.c
@@
As for skinny metadata, key.offset stores levels rather than extent length.
Signed-off-by: Liu Bo bo.li@oracle.com
---
btrfs-image.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index 22239fe..30c1a9a 100644
--- a/btrfs-image.c
+++
35 matches
Mail list logo
