[PATCH 4/4] Btrfs: cleanup of function where btrfs_extend_item() is called
Argument 'trans' became unnecessary from setup_inline_extent_backref()
that called btrfs_extend_item().
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 151b0ad..f3ff02a 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1590,8 +1590,7 @@ out:
* helper to add new inline back ref
*/
static noinline_for_stack
-void setup_inline_extent_backref(struct btrfs_trans_handle *trans,
-struct btrfs_root *root,
+void setup_inline_extent_backref(struct btrfs_root *root,
struct btrfs_path *path,
struct btrfs_extent_inline_ref *iref,
u64 parent, u64 root_objectid,
@@ -1764,7 +1763,7 @@ int insert_inline_extent_backref(struct
btrfs_trans_handle *trans,
update_inline_extent_backref(root, path, iref,
refs_to_add, extent_op);
} else if (ret == -ENOENT) {
- setup_inline_extent_backref(trans, root, path, iref, parent,
+ setup_inline_extent_backref(root, path, iref, parent,
root_objectid, owner, offset,
refs_to_add, extent_op);
ret = 0;
--
1.7.12.2
--
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
[PATCH 3/4] Btrfs: remove unused argument of btrfs_extend_item()
Argument 'trans' is not used in btrfs_extend_item().
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c | 3 +--
fs/btrfs/ctree.h | 3 +--
fs/btrfs/dir-item.c| 2 +-
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/file-item.c | 2 +-
fs/btrfs/inode-item.c | 4 ++--
fs/btrfs/tree-log.c| 2 +-
7 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 76e11d7..d5f22db 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -4378,8 +4378,7 @@ void btrfs_truncate_item(struct btrfs_root *root, struct
btrfs_path *path,
/*
* make the item pointed to by the path bigger, data_size is the new size.
*/
-void btrfs_extend_item(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+void btrfs_extend_item(struct btrfs_root *root, struct btrfs_path *path,
u32 data_size)
{
int slot;
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 7da1b74..de3b483 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -3197,8 +3197,7 @@ int btrfs_copy_root(struct btrfs_trans_handle *trans,
struct extent_buffer **cow_ret, u64 new_root_objectid);
int btrfs_block_can_be_shared(struct btrfs_root *root,
struct extent_buffer *buf);
-void btrfs_extend_item(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+void btrfs_extend_item(struct btrfs_root *root, struct btrfs_path *path,
u32 data_size);
void btrfs_truncate_item(struct btrfs_root *root, struct btrfs_path *path,
u32 new_size, int from_end);
diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c
index 47cab8d..71fa113 100644
--- a/fs/btrfs/dir-item.c
+++ b/fs/btrfs/dir-item.c
@@ -49,7 +49,7 @@ static struct btrfs_dir_item *insert_with_overflow(struct
btrfs_trans_handle
di = btrfs_match_dir_item_name(root, path, name, name_len);
if (di)
return ERR_PTR(-EEXIST);
- btrfs_extend_item(trans, root, path, data_size);
+ btrfs_extend_item(root, path, data_size);
} else if (ret < 0)
return ERR_PTR(ret);
WARN_ON(ret > 0);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d265625..151b0ad 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1001,7 +1001,7 @@ static int convert_extent_item_v0(struct
btrfs_trans_handle *trans,
return ret;
BUG_ON(ret); /* Corruption */
- btrfs_extend_item(trans, root, path, new_size);
+ btrfs_extend_item(root, path, new_size);
leaf = path->nodes[0];
item = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_extent_item);
@@ -1614,7 +1614,7 @@ void setup_inline_extent_backref(struct
btrfs_trans_handle *trans,
type = extent_ref_type(parent, owner);
size = btrfs_extent_inline_ref_size(type);
- btrfs_extend_item(trans, root, path, size);
+ btrfs_extend_item(root, path, size);
ei = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_extent_item);
refs = btrfs_extent_refs(leaf, ei);
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index def004f..da9edca 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -834,7 +834,7 @@ again:
diff /= csum_size;
diff *= csum_size;
- btrfs_extend_item(trans, root, path, diff);
+ btrfs_extend_item(root, path, diff);
goto csum;
}
diff --git a/fs/btrfs/inode-item.c b/fs/btrfs/inode-item.c
index cb44398..1640e03 100644
--- a/fs/btrfs/inode-item.c
+++ b/fs/btrfs/inode-item.c
@@ -361,7 +361,7 @@ static int btrfs_insert_inode_extref(struct
btrfs_trans_handle *trans,
name, name_len, NULL))
goto out;
- btrfs_extend_item(trans, root, path, ins_len);
+ btrfs_extend_item(root, path, ins_len);
ret = 0;
}
if (ret < 0)
@@ -417,7 +417,7 @@ int btrfs_insert_inode_ref(struct btrfs_trans_handle *trans,
goto out;
old_size = btrfs_item_size_nr(path->nodes[0], path->slots[0]);
- btrfs_extend_item(trans, root, path, ins_len);
+ btrfs_extend_item(root, path, ins_len);
ref = btrfs_item_ptr(path->nodes[0], path->slots[0],
struct btrfs_inode_ref);
ref = (struct btrfs_inode_ref *)((unsigned long)ref + old_size);
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c2d55ed..0a5601b 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -410,7 +410,7 @@ insert:
if (found_size > item_size)
btrfs_truncate_item(root, path, item_size, 1);
else if (found_size < item_siz
[PATCH 2/4] Btrfs: cleanup of function where fixup_low_keys() is called
If argument 'trans' is unnecessary in the function where
fixup_low_keys() is called, 'trans' is deleted.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c | 28
fs/btrfs/ctree.h | 10 +++---
fs/btrfs/delayed-inode.c | 11 +--
fs/btrfs/dir-item.c | 3 +--
fs/btrfs/extent-tree.c | 9 -
fs/btrfs/file-item.c | 11 +--
fs/btrfs/file.c | 8
fs/btrfs/inode-item.c| 4 ++--
fs/btrfs/inode.c | 3 +--
fs/btrfs/tree-log.c | 4 ++--
10 files changed, 39 insertions(+), 52 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index b5eec7c..76e11d7 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -37,8 +37,8 @@ static int balance_node_right(struct btrfs_trans_handle
*trans,
struct btrfs_root *root,
struct extent_buffer *dst_buf,
struct extent_buffer *src_buf);
-static void del_ptr(struct btrfs_trans_handle *trans, struct btrfs_root *root,
- struct btrfs_path *path, int level, int slot);
+static void del_ptr(struct btrfs_root *root, struct btrfs_path *path,
+ int level, int slot);
static void tree_mod_log_free_eb(struct btrfs_fs_info *fs_info,
struct extent_buffer *eb);
struct extent_buffer *read_old_tree_block(struct btrfs_root *root, u64 bytenr,
@@ -1818,7 +1818,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
if (btrfs_header_nritems(right) == 0) {
clean_tree_block(trans, root, right);
btrfs_tree_unlock(right);
- del_ptr(trans, root, path, level + 1, pslot + 1);
+ del_ptr(root, path, level + 1, pslot + 1);
root_sub_used(root, right->len);
btrfs_free_tree_block(trans, root, right, 0, 1);
free_extent_buffer_stale(right);
@@ -1862,7 +1862,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
if (btrfs_header_nritems(mid) == 0) {
clean_tree_block(trans, root, mid);
btrfs_tree_unlock(mid);
- del_ptr(trans, root, path, level + 1, pslot);
+ del_ptr(root, path, level + 1, pslot);
root_sub_used(root, mid->len);
btrfs_free_tree_block(trans, root, mid, 0, 1);
free_extent_buffer_stale(mid);
@@ -2927,8 +2927,7 @@ static void fixup_low_keys(struct btrfs_root *root,
struct btrfs_path *path,
* This function isn't completely safe. It's the caller's responsibility
* that the new key won't break the order
*/
-void btrfs_set_item_key_safe(struct btrfs_trans_handle *trans,
-struct btrfs_root *root, struct btrfs_path *path,
+void btrfs_set_item_key_safe(struct btrfs_root *root, struct btrfs_path *path,
struct btrfs_key *new_key)
{
struct btrfs_disk_key disk_key;
@@ -4262,7 +4261,7 @@ int btrfs_duplicate_item(struct btrfs_trans_handle *trans,
return ret;
path->slots[0]++;
- setup_items_for_insert(trans, root, path, new_key, &item_size,
+ setup_items_for_insert(root, path, new_key, &item_size,
item_size, item_size +
sizeof(struct btrfs_item), 1);
leaf = path->nodes[0];
@@ -4279,9 +4278,7 @@ int btrfs_duplicate_item(struct btrfs_trans_handle *trans,
* off the end of the item or if we shift the item to chop bytes off
* the front.
*/
-void btrfs_truncate_item(struct btrfs_trans_handle *trans,
-struct btrfs_root *root,
-struct btrfs_path *path,
+void btrfs_truncate_item(struct btrfs_root *root, struct btrfs_path *path,
u32 new_size, int from_end)
{
int slot;
@@ -4452,8 +4449,7 @@ void btrfs_extend_item(struct btrfs_trans_handle *trans,
* to save stack depth by doing the bulk of the work in a function
* that doesn't call btrfs_search_slot
*/
-void setup_items_for_insert(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+void setup_items_for_insert(struct btrfs_root *root, struct btrfs_path *path,
struct btrfs_key *cpu_key, u32 *data_size,
u32 total_data, u32 total_size, int nr)
{
@@ -4569,7 +4565,7 @@ int btrfs_insert_empty_items(struct btrfs_trans_handle
*trans,
slot = path->slots[0];
BUG_ON(slot < 0);
- setup_items_for_insert(trans, root, path, cpu_key, data_size,
+ setup_items_for_insert(root, path, cpu_key, data_size,
total_data, total_size, nr);
return 0;
}
@@ -4607,8 +4603,8 @@ int btrfs_insert_item(struct btrfs_trans_handle *trans,
struct btrfs_root
[PATCH 1/4] Btrfs: remove unused argument of fixup_low_keys()
Argument 'trans' is not used in fixup_low_keys(). So, remove it.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index ca9d8f1..b5eec7c 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -2902,8 +2902,7 @@ again:
* higher levels
*
*/
-static void fixup_low_keys(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+static void fixup_low_keys(struct btrfs_root *root, struct btrfs_path *path,
struct btrfs_disk_key *key, int level)
{
int i;
@@ -2951,7 +2950,7 @@ void btrfs_set_item_key_safe(struct btrfs_trans_handle
*trans,
btrfs_set_item_key(eb, &disk_key, slot);
btrfs_mark_buffer_dirty(eb);
if (slot == 0)
- fixup_low_keys(trans, root, path, &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
}
/*
@@ -3687,7 +3686,7 @@ static noinline int __push_leaf_left(struct
btrfs_trans_handle *trans,
clean_tree_block(trans, root, right);
btrfs_item_key(right, &disk_key, 0);
- fixup_low_keys(trans, root, path, &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
/* then fixup the leaf pointer in the path */
if (path->slots[0] < push_items) {
@@ -4047,8 +4046,7 @@ again:
path->nodes[0] = right;
path->slots[0] = 0;
if (path->slots[1] == 0)
- fixup_low_keys(trans, root, path,
- &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
}
btrfs_mark_buffer_dirty(right);
return ret;
@@ -4367,7 +4365,7 @@ void btrfs_truncate_item(struct btrfs_trans_handle *trans,
btrfs_set_disk_key_offset(&disk_key, offset + size_diff);
btrfs_set_item_key(leaf, &disk_key, slot);
if (slot == 0)
- fixup_low_keys(trans, root, path, &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
}
item = btrfs_item_nr(leaf, slot);
@@ -4531,7 +4529,7 @@ void setup_items_for_insert(struct btrfs_trans_handle
*trans,
if (slot == 0) {
btrfs_cpu_key_to_disk(&disk_key, cpu_key);
- fixup_low_keys(trans, root, path, &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
}
btrfs_unlock_up_safe(path, 1);
btrfs_mark_buffer_dirty(leaf);
@@ -4642,7 +4640,7 @@ static void del_ptr(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
struct btrfs_disk_key disk_key;
btrfs_node_key(parent, &disk_key, 0);
- fixup_low_keys(trans, root, path, &disk_key, level + 1);
+ fixup_low_keys(root, path, &disk_key, level + 1);
}
btrfs_mark_buffer_dirty(parent);
}
@@ -4744,7 +4742,7 @@ int btrfs_del_items(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
struct btrfs_disk_key disk_key;
btrfs_item_key(leaf, &disk_key, 0);
- fixup_low_keys(trans, root, path, &disk_key, 1);
+ fixup_low_keys(root, path, &disk_key, 1);
}
/* delete the leaf if it is mostly empty */
--
1.7.12.2
--
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
Re: [PATCH 02/11, RESEND] btrfs-progs: no pending balance is not an error
On 04/16/2013 12:21 AM, David Sterba wrote: On Mon, Apr 15, 2013 at 02:38:08PM +0800, Anand Jain wrote: +/* Checks the status of the balance if any + * return codes: + * -1 : Error failed to know if there is any pending balance + * 1 : Successful to know status of a pending balance + * 0 : When there is no pending balance or completed The error code will become the return code of the 'btrfs balance status' command in the end: btrfs.c:main() 295 exit(cmd->fn(argc, argv)); and that's why I've suggested to return 1 or 2, though -1 matches shell error code 255 but I'd rathe avoid using it. makes sense. v3 is out. -- 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
[PATCH 02/11 v3] btrfs-progs: no pending balance is not an error
Having no balance running/ paused/completed is a normal
situation, so the current output message should be positive
with return val zero.
Signed-off-by: Anand Jain
---
cmds-balance.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/cmds-balance.c b/cmds-balance.c
index f5dc317..cffa807 100644
--- a/cmds-balance.c
+++ b/cmds-balance.c
@@ -616,6 +616,12 @@ static const char * const cmd_balance_status_usage[] = {
NULL
};
+/* Checks the status of the balance if any
+ * return codes:
+ * 2 : Error failed to know if there is any pending balance
+ * 1 : Successful to know status of a pending balance
+ * 0 : When there is no pending balance or completed
+ */
static int cmd_balance_status(int argc, char **argv)
{
struct btrfs_ioctl_balance_args args;
@@ -654,7 +660,7 @@ static int cmd_balance_status(int argc, char **argv)
fd = open_file_or_dir(path);
if (fd < 0) {
fprintf(stderr, "ERROR: can't access to '%s'\n", path);
- return 12;
+ return 2;
}
ret = ioctl(fd, BTRFS_IOC_BALANCE_PROGRESS, &args);
@@ -662,9 +668,13 @@ static int cmd_balance_status(int argc, char **argv)
close(fd);
if (ret < 0) {
+ if (e == ENOTCONN) {
+ printf("No balance found on '%s'\n", path);
+ return 0;
+ }
fprintf(stderr, "ERROR: balance status on '%s' failed - %s\n",
- path, (e == ENOTCONN) ? "Not in progress" :
strerror(e));
- return 19;
+ path, strerror(e));
+ return 2;
}
if (args.state & BTRFS_BALANCE_STATE_RUNNING) {
@@ -688,7 +698,7 @@ static int cmd_balance_status(int argc, char **argv)
if (verbose)
dump_ioctl_balance_args(&args);
- return 0;
+ return 1;
}
const struct cmd_group balance_cmd_group = {
--
1.8.1.227.g44fe835
--
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
Re: Activating space_cache after read-only snapshots without space_cache have been taken
On Tue, Apr 16, 2013 at 02:28:51AM +0200, Ochi wrote:
> Hello everyone,
>
> I've ran into problems with _very_ slow unmounting of my
> btrfs-formatted "backup" volume. I have a suspicion what might be
> the cause but maybe someone with more experience with the btrfs code
> could enlighten me whether it is actually correct.
>
> The situation is the following: I have created a backup-volume to
> which I regularly rsync a backup of my system into a subvolume.
> After rsync'ing, I take a _read-only_ snapshot of that subvolume
> with a timestamp added to its name.
>
> Now at the time I started using this backup volume, I was _not_
> using the space_cache mount option and two read-only snapshots were
> taken during this time. Then I started using the space_cache option
> and continued doing snapshots.
>
> A bit later, I started having very long lags when unmounting the
> backup volume (both during shutdown and when unmounting manually). I
> scrubbed and fsck'd the volume but this didn't show any errors.
> Defragmenting the root and subvolumes took a long time but didn't
> improve the situation much.
So are you using '-o nospace_cache' when creating two RO snapshots?
>
> Now I started having the suspicion that maybe the space cache
> possibly couldn't be written to disk for the readonly
> subvolumes/snapshots that were created during the time when I wasn't
> using the space_cache option, forcing the cache to be rebuilt every
> time.
>
> Clearing the cache didn't help. But when I deleted the two snapshots
> that I think were taken during the time without the mount option,
> the unmounting time seems to have improved considerably.
I don't know why this happens, but maybe you can observe the umount process's
very slow behaviour by using 'cat /proc/{umount-pid}/stack' or 'perf top'.
thanks,
liubo
>
> I will have to observe whether unmounting stays quick now but my
> question is whether it is possible that the read-only snapshots
> taken during the time when I wasn't using space_cache might actually
> have been the culprits.
>
> Best,
> Sebastian
> --
> 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
--
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
Activating space_cache after read-only snapshots without space_cache have been taken
Hello everyone, I've ran into problems with _very_ slow unmounting of my btrfs-formatted "backup" volume. I have a suspicion what might be the cause but maybe someone with more experience with the btrfs code could enlighten me whether it is actually correct. The situation is the following: I have created a backup-volume to which I regularly rsync a backup of my system into a subvolume. After rsync'ing, I take a _read-only_ snapshot of that subvolume with a timestamp added to its name. Now at the time I started using this backup volume, I was _not_ using the space_cache mount option and two read-only snapshots were taken during this time. Then I started using the space_cache option and continued doing snapshots. A bit later, I started having very long lags when unmounting the backup volume (both during shutdown and when unmounting manually). I scrubbed and fsck'd the volume but this didn't show any errors. Defragmenting the root and subvolumes took a long time but didn't improve the situation much. Now I started having the suspicion that maybe the space cache possibly couldn't be written to disk for the readonly subvolumes/snapshots that were created during the time when I wasn't using the space_cache option, forcing the cache to be rebuilt every time. Clearing the cache didn't help. But when I deleted the two snapshots that I think were taken during the time without the mount option, the unmounting time seems to have improved considerably. I will have to observe whether unmounting stays quick now but my question is whether it is possible that the read-only snapshots taken during the time when I wasn't using space_cache might actually have been the culprits. Best, Sebastian -- 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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
> Anyways, thought I would reply back with some insight on the matter
> and see what others had to say, since I am in no position to dictate
> the direction that brtfsck/fsck.btrfs should take as far as wrapper
> script or no is concerned. Look forward to your replies! o/
FWIW: debian has been carrying a patch to ignore fsck args to help it
run as fsck.btrfs. I think modern versions of their btrfs-tools package
that are based on more recent btrfs-progs also include the hunk to
recognize being called as fsck.btrfs.
It might be worth finding someone who knows the history of the debian
package. I'm certainly not that person :). Here's the result of some
light googling:
http://ftp.de.debian.org/debian/pool/main/b/btrfs-tools/btrfs-tools_0.19+20130131-3+really20121004-1.debian.tar.xz
debian/patches/08-fsck.patch:
Author: Sten Heinze
Description:
Ignore all arguments starting with -a in btrfsck for the time being
(Closes: #567681, #571300, #612809, #668832).
diff -Naurp btrfs-tools.orig/btrfsck.c btrfs-tools/btrfsck.c
--- btrfs-tools.orig/btrfsck.c 2012-12-10 10:44:57.283351955 +0100
+++ btrfs-tools/btrfsck.c 2012-12-10 10:56:20.971516720 +0100
@@ -3477,6 +3477,12 @@ static void print_usage(void)
exit(1);
}
+static void print_info(void)
+{
+ fprintf(stderr, "%s\n", BTRFS_BUILD_VERSION);
+ exit(0);
+}
+
static struct option long_options[] = {
{ "super", 1, NULL, 's' },
{ "repair", 0, NULL, 0 },
@@ -3501,7 +3507,7 @@ int main(int ac, char **av)
while(1) {
int c;
- c = getopt_long(ac, av, "s:", long_options,
+ c = getopt_long(ac, av, "s:anry", long_options,
&option_index);
if (c < 0)
break;
@@ -3514,6 +3520,12 @@ int main(int ac, char **av)
break;
case '?':
print_usage();
+ break;
+ case 'a':
+ case 'n':
+ case 'r':
+ case 'y':
+ print_info();
}
if (option_index == 1) {
printf("enabling repair mode\n");
--
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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
Jan,
It would appear that:
# fsck -- --repair /dev/storage/lv_btrfs
doesn't work, but if I put the fs-specific-options at the end:
# fsck /dev/storage/lv_btrfs -- --repair
it works fine. As we were/are discussing on irc, I also have no idea
where the ext4 lines come from. *scratcheshead*
And to save you guys some testing, here is the script I used and some
sample output:
fsck.btrfs:
#!/bin/sh -f
# fsck exit codes for convenience
# 0- No errors
# 1- Filesystem errors corrected
# 2- System should be rebooted
# 4- Filesystem errors left uncorrected
# 8- Operational error
# 16 - Usage or syntax error
# 32 - Fsck canceled by user request
# 128 - Shared-library error
AUTO=false
while getopts ":aApy" c
do
case $c in
a|A|p|y)AUTO=true; echo "DEBUG: $c";;
esac
done
eval DEV=\${$#}
if [ ! -e $DEV ]; then
echo "$0: $DEV does not exist"
exit 8
fi
if $AUTO; then
echo "$0: BTRFS file system."
else
echo "If you wish to check the consistency of an BTRFS filesystem or"
echo "repair a damaged filesystem, see btrfsck(8)."
fi
exit 0
Output:
==
# fsck /dev/storage/lv_btrfs -- --repair
fsck from util-linux 2.20.1
DEBUG: p
DEBUG: a
/sbin/fsck.btrfs: BTRFS file system.
# fsck /dev/storage/lv_btrfs
fsck from util-linux 2.20.1
If you wish to check the consistency of an BTRFS filesystem or
repair a damaged filesystem, see btrfsck(8).
Note the "p" and "a" switches when called with custom fs switches, but
not when called standalone.
On Mon, Apr 15, 2013 at 1:01 PM, Eric Sandeen wrote:
> On 4/15/13 11:45 AM, Dan McGrath wrote:
>> Jan,
>>
>> I got a chance to sit down and dig a little bit deeper into
>> `fsck.xfs`. Here is what I discovered.
>>
>> The "(a|A|y|p)" options in the XFS script appear to be nothing more
>> than the expected `fsck` options that imply automated checks (as is
>> clearly implied by the use of AUTO). While I have yet to specifically
>> test the capitalized "A", my guess is that it matches the "-A" options
>> from fsck(8) for when the system is going through the fstab. The
>> syntax itself appears to assume that the dev name is the last param
>> (as indicated by the argc/$#, which gets eval'd into the DEV
>> variable).
>>
>> After doing some tests with a hacked up version of the `fsck.xfs`
>> script, it would appear that the generic `fsck` script calls each
>> script in order and passes it some parameters to test, since if I pass
>> `fsck` some random/btrfsck switches:
>>
>> # fsck --repair /dev/storage/lv_btrfs
>>
>> I get an error back from `fsck.ext4`:
>>
>> fsck from util-linux 2.20.1
>> fsck.ext4: invalid option -- 'e'
>
> 2 things; from the fsck manpage:
>
>fsck [-sAVRTMNP] [-C [fd]] [-t fstype] [filesys...] [--]
> [fs-specific-options]
>
> so I think you need:
>
> fsck -- --repair /dev/storage/lv_btrfs
>
> But the other issues seems to be that fsck & blkid are autodetecting
> the device as ext4, not btrfs; a separate issue.
>
> -Eric
>
>
--
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
Re: [PATCH 2/2] Btrfs: introduce noextiref mount option
On Fri, Apr 12, 2013 at 12:01:19PM -0500, Eric Sandeen wrote: > On 4/11/13 5:35 AM, Miao Xie wrote: > > Now, we set incompat flag EXTEND_IREF when we actually need insert a > > extend inode reference, not when making a fs. But some users may hope > > that the fs still can be mounted on the old kernel, and don't hope we > > insert any extend inode references. So we introduce noextiref mount > > option to close this function. > > I'd really rather not have yet another work-around mount option. > > Wouldn't it be better to say: if you don't want extended irefs, turn > that feature off on the filesystem itself, either at mkfs time or via > btrfstune after the fact. I agree with this, and hope the inconsistency around extref is only temporary so the mount options is not required in the long term. The code reverting extref set by default in mkfs is in integration branch. The preferred solution is the -O option where we can put all the fs features in one go at mkfs time. david -- 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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On 4/15/13 11:45 AM, Dan McGrath wrote: > Jan, > > I got a chance to sit down and dig a little bit deeper into > `fsck.xfs`. Here is what I discovered. > > The "(a|A|y|p)" options in the XFS script appear to be nothing more > than the expected `fsck` options that imply automated checks (as is > clearly implied by the use of AUTO). While I have yet to specifically > test the capitalized "A", my guess is that it matches the "-A" options > from fsck(8) for when the system is going through the fstab. The > syntax itself appears to assume that the dev name is the last param > (as indicated by the argc/$#, which gets eval'd into the DEV > variable). > > After doing some tests with a hacked up version of the `fsck.xfs` > script, it would appear that the generic `fsck` script calls each > script in order and passes it some parameters to test, since if I pass > `fsck` some random/btrfsck switches: > > # fsck --repair /dev/storage/lv_btrfs > > I get an error back from `fsck.ext4`: > > fsck from util-linux 2.20.1 > fsck.ext4: invalid option -- 'e' 2 things; from the fsck manpage: fsck [-sAVRTMNP] [-C [fd]] [-t fstype] [filesys...] [--] [fs-specific-options] so I think you need: fsck -- --repair /dev/storage/lv_btrfs But the other issues seems to be that fsck & blkid are autodetecting the device as ext4, not btrfs; a separate issue. -Eric -- 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
Re: [PATCH 2/2] Btrfs: introduce noextiref mount option
On Fri, Apr 12, 2013 at 12:01:19PM -0500, Eric Sandeen wrote: > On 4/11/13 5:35 AM, Miao Xie wrote: > > Now, we set incompat flag EXTEND_IREF when we actually need insert a > > extend inode reference, not when making a fs. But some users may hope > > that the fs still can be mounted on the old kernel, and don't hope we > > insert any extend inode references. So we introduce noextiref mount > > option to close this function. > > I'd really rather not have yet another work-around mount option. > > Wouldn't it be better to say: if you don't want extended irefs, turn > that feature off on the filesystem itself, either at mkfs time or via > btrfstune after the fact. > > So rather than opportunistically turning it on, and then adding another > patch to disable that behavior with a mount option, why not just teach > btrfstune to turn off the flag, if it's not desired by the admin? > > It'd save a mount option, and 50 or so lines of new kernel code, > and make things simpler overall, IMHO. I don't like this so much either - in particular I don't like the fs to silently turn on incompat flags based on some heuristic or random number that the user won't likely know (in this case, the number of bytes that would fit in a standard btrfs hard link). Tunefs can already turn the flag on, I don't see why we don't add the reverse functionality. Also making it optional on mkfs time is easy enough... --Mark -- Mark Fasheh -- 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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
Jan,
I got a chance to sit down and dig a little bit deeper into
`fsck.xfs`. Here is what I discovered.
The "(a|A|y|p)" options in the XFS script appear to be nothing more
than the expected `fsck` options that imply automated checks (as is
clearly implied by the use of AUTO). While I have yet to specifically
test the capitalized "A", my guess is that it matches the "-A" options
from fsck(8) for when the system is going through the fstab. The
syntax itself appears to assume that the dev name is the last param
(as indicated by the argc/$#, which gets eval'd into the DEV
variable).
After doing some tests with a hacked up version of the `fsck.xfs`
script, it would appear that the generic `fsck` script calls each
script in order and passes it some parameters to test, since if I pass
`fsck` some random/btrfsck switches:
# fsck --repair /dev/storage/lv_btrfs
I get an error back from `fsck.ext4`:
fsck from util-linux 2.20.1
fsck.ext4: invalid option -- 'e'
Since the man page for fsck(8) hints that there are no real standards
for calling conventions, but most support (a|n|r|y), and as how
unknown options cause an error with fsck (thanks to ext4), perhaps it
would be a good idea for btrfsck to align itself with the standard
options for fsck (a/n/r/y/A)? If anything, the "A" option (for fstab
based) would appear to be the real target of a noop style exit(0) that
I had originally tested.
Also, thanks for the link Eric, just came in as I am typing this reply :)
Anyways, thought I would reply back with some insight on the matter
and see what others had to say, since I am in no position to dictate
the direction that brtfsck/fsck.btrfs should take as far as wrapper
script or no is concerned. Look forward to your replies! o/
Dan
On Mon, Apr 15, 2013 at 10:03 AM, Jan Alexander Steffens
wrote:
> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath wrote:
>> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
>>
>> Signed-off-by: Dan McGrath
>> ---
>> btrfs.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/btrfs.c b/btrfs.c
>> index 691adef..78161a9 100644
>> --- a/btrfs.c
>> +++ b/btrfs.c
>> @@ -272,6 +272,8 @@ int main(int argc, char **argv)
>>
>> if (!strcmp(bname, "btrfsck")) {
>> argv[0] = "check";
>> + } else if (!strcmp(bname, "fsck.btrfsck")) {
>> + exit(0);
>> } else {
>> argc--;
>> argv++;
>> --
>> 1.7.9.5
>>
>> --
>> 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
>
> Shouldn't it be fsck.btrfs, not fsck.btrfsck?
>
> Also, fsck.xfs does a bit more than just an exit(0), maybe there's
> some merit to what it does. It's a simple shellscript, so check it
> out.
--
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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On 4/15/13 9:03 AM, Jan Alexander Steffens wrote:
> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath wrote:
>> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
>>
>> Signed-off-by: Dan McGrath
>> ---
>> btrfs.c |2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/btrfs.c b/btrfs.c
>> index 691adef..78161a9 100644
>> --- a/btrfs.c
>> +++ b/btrfs.c
>> @@ -272,6 +272,8 @@ int main(int argc, char **argv)
>>
>> if (!strcmp(bname, "btrfsck")) {
>> argv[0] = "check";
>> + } else if (!strcmp(bname, "fsck.btrfsck")) {
>> + exit(0);
>> } else {
>> argc--;
>> argv++;
>> --
>> 1.7.9.5
>>
>> --
>> 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
>
> Shouldn't it be fsck.btrfs, not fsck.btrfsck?
>
> Also, fsck.xfs does a bit more than just an exit(0), maybe there's
> some merit to what it does. It's a simple shellscript, so check it
> out.
Yup I think the idea for xfs was that if called by initscripts w/ common
initscript options, be nice and quiet, but if it looks like it was invoked
by someone expecting something to happen, be more informative.
Git blame of the shell script is at
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=blame;f=fsck/xfs_fsck.sh;h=c5a96e688b994c36d9ab1b0206225f2f5e7b12e8;hb=HEAD
- it hasn't changed in forever but you might get some hints at why
it does what it does.
Expecting fsck.$FS in initscripts is just a leftover from pre-journaling-fs
days, I think.
-Eric
--
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
Re: [PATCH 02/11, RESEND] btrfs-progs: no pending balance is not an error
On Mon, Apr 15, 2013 at 02:38:08PM +0800, Anand Jain wrote: > +/* Checks the status of the balance if any > + * return codes: > + * -1 : Error failed to know if there is any pending balance > + * 1 : Successful to know status of a pending balance > + * 0 : When there is no pending balance or completed The error code will become the return code of the 'btrfs balance status' command in the end: btrfs.c:main() 295 exit(cmd->fn(argc, argv)); and that's why I've suggested to return 1 or 2, though -1 matches shell error code 255 but I'd rathe avoid using it. david -- 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
Re: [PATCH v2] Btrfs: allow file data clone within a file
On Mon, Apr 15, 2013 at 10:55:45AM +0800, Liu Bo wrote:
> @@ -2563,6 +2568,12 @@ static noinline long btrfs_ioctl_clone(struct file
> *file, unsigned long srcfd,
> !IS_ALIGNED(destoff, bs))
> goto out_unlock;
>
> + /* verify if ranges are overlapped within the same file */
> + if (same_inode) {
> + if (destoff + len > off && destoff < off + len)
> + goto out_unlock;
Although I find the condition hard to read, it's correct.
Reviewed-by: David Sterba
--
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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
My sincere apologies. It would appear that I was overly careful about
checking the binary functioned when called as a symlink, but not the
correct filename:
# ls -l `which fsck.btrfs`
lrwxrwxrwx 1 root root 7 Aug 25 2011 /sbin/fsck.btrfs -> btrfsck
So yes, the patch incorrectly assumed a symlink name of
'fsck.btrfsck', instead of 'fsck.btrfs'.
As for fsck.xfs, I will take a look, thanks!
On Mon, Apr 15, 2013 at 10:03 AM, Jan Alexander Steffens
wrote:
>
> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath wrote:
> > As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
> >
> > Signed-off-by: Dan McGrath
> > ---
> > btrfs.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/btrfs.c b/btrfs.c
> > index 691adef..78161a9 100644
> > --- a/btrfs.c
> > +++ b/btrfs.c
> > @@ -272,6 +272,8 @@ int main(int argc, char **argv)
> >
> > if (!strcmp(bname, "btrfsck")) {
> > argv[0] = "check";
> > + } else if (!strcmp(bname, "fsck.btrfsck")) {
> > + exit(0);
> > } else {
> > argc--;
> > argv++;
> > --
> > 1.7.9.5
> >
> > --
> > 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
>
> Shouldn't it be fsck.btrfs, not fsck.btrfsck?
>
> Also, fsck.xfs does a bit more than just an exit(0), maybe there's
> some merit to what it does. It's a simple shellscript, so check it
> out.
--
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
Re: [PATCH] btrfs-progs: No-op when called as fsck.btrfsck
On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath wrote:
> As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
>
> Signed-off-by: Dan McGrath
> ---
> btrfs.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/btrfs.c b/btrfs.c
> index 691adef..78161a9 100644
> --- a/btrfs.c
> +++ b/btrfs.c
> @@ -272,6 +272,8 @@ int main(int argc, char **argv)
>
> if (!strcmp(bname, "btrfsck")) {
> argv[0] = "check";
> + } else if (!strcmp(bname, "fsck.btrfsck")) {
> + exit(0);
> } else {
> argc--;
> argv++;
> --
> 1.7.9.5
>
> --
> 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
Shouldn't it be fsck.btrfs, not fsck.btrfsck?
Also, fsck.xfs does a bit more than just an exit(0), maybe there's
some merit to what it does. It's a simple shellscript, so check it
out.
--
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
[PATCH] btrfs-progs: No-op when called as fsck.btrfsck
As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
Signed-off-by: Dan McGrath
---
btrfs.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/btrfs.c b/btrfs.c
index 691adef..78161a9 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -272,6 +272,8 @@ int main(int argc, char **argv)
if (!strcmp(bname, "btrfsck")) {
argv[0] = "check";
+ } else if (!strcmp(bname, "fsck.btrfsck")) {
+ exit(0);
} else {
argc--;
argv++;
--
1.7.9.5
--
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
[PATCH] btrfs-progs: No-op when called as fsck.btrfsck
Hi, I thought that I would attempt a quick little patch that will make btrfsck into a No-op when called as fsck.btrfsck. The reasoning is that the FAQ states that it is recommended and safe to do so, and the current 12.04 version of Ubuntu just symlinks fsck.btrfsck to btrfsck instead of /bin/true. PS - Apologies if I mess this git send-email up! Dan McGrath (1): btrfs-progs: No-op when called as fsck.btrfsck btrfs.c |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- 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
How to rescue my data from raid1 metadata with raid0 data ?
Hi all, When I created my btrfs filesystem, I use the command: mkfs.btrfs -m raid1 -d raid0 /dev/sda5 /dev/sdb5 # btrfs fi df /srv/raid0/ Data, RAID0: total=1.92TB, used=1.46TB System, RAID1: total=32.00MB, used=164.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=39.26GB, used=8.84GB Today, my first disk broken, I want to copy all integrated files to /dev/sdb5 which not have data on /dev/sda5, then remove /dev/sda5 from this btrfs file system, is it possible ? # btrfs fi show Label: 'dre log files' uuid: d14f42ca-8784-463e-b85a-b94a5b9f70a2 Total devices 2 FS bytes used 1.46TB devid1 size 1.00TB used 1.00TB path /dev/sdb5 *** Some devices missing With the latest btrfs-progs v0.20-rc1 and kernel 3.7.5, I try to delete the missing device, but failed: # ./btrfs device delete missing /srv/raid0 ERROR: error removing the device 'missing' - Invalid argument [6191459.658962] btrfs: bdev /dev/sda5 errs: wr 96543, rd 1, flush 0, corrupt 0, gen 0 [6191459.665981] btrfs: bdev /dev/sda5 errs: wr 96544, rd 1, flush 0, corrupt 0, gen 0 [6191459.668319] btrfs: bdev /dev/sda5 errs: wr 96545, rd 1, flush 0, corrupt 0, gen 0 [6191459.682605] btrfs: bdev /dev/sda5 errs: wr 96546, rd 1, flush 0, corrupt 0, gen 0 [6191459.684672] btrfs: bdev /dev/sda5 errs: wr 96547, rd 1, flush 0, corrupt 0, gen 0 [6191459.699748] btrfs: bdev /dev/sda5 errs: wr 96548, rd 1, flush 0, corrupt 0, gen 0 [6191459.702150] btrfs: bdev /dev/sda5 errs: wr 96549, rd 1, flush 0, corrupt 0, gen 0 [6191459.704791] btrfs: bdev /dev/sda5 errs: wr 96550, rd 1, flush 0, corrupt 0, gen 0 [6191459.707257] btrfs: bdev /dev/sda5 errs: wr 96551, rd 1, flush 0, corrupt 0, gen 0 [6191459.749754] lost page write due to I/O error on /dev/sda5 [6191459.749763] btrfs: bdev /dev/sda5 errs: wr 96552, rd 1, flush 0, corrupt 0, gen 0 [6191459.751572] lost page write due to I/O error on /dev/sda5 [6191459.751585] lost page write due to I/O error on /dev/sda5 [6191468.705857] btrfs: unable to go below two devices on raid1 Thanks, Dongsheng -- 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
[PATCH V2 RESEND] Btrfs: fix confusing edquot happening case
From: Wang Shilong
Step to reproduce:
mkfs.btrfs
mount
dd if=/dev/zero of=//data bs=1M count=10
sync
btrfs quota enable
btrfs qgroup create 0/5
btrfs qgroup limit 5M 0/5
rm -f //data
sync
btrfs qgroup show
dd if=/dev/zero of=data bs=1M count=1
>From the perspective of users, qgroup's referenced or exclusive
is negative,but user can not continue to write data! a workaround
way is to cast u64 to s64 when doing qgroup reservation.
Signed-off-by: Wang Shilong
Reviewed-by: Arne Jansen
---
Changelog v1->v2:
-use s64 instead of signed long long
---
fs/btrfs/qgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index b44124d..ab364a2 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
num_bytes)
qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
- qg->reserved + qg->rfer + num_bytes >
+ qg->reserved + (s64)qg->rfer + num_bytes >
qg->max_rfer) {
ret = -EDQUOT;
goto out;
}
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
- qg->reserved + qg->excl + num_bytes >
+ qg->reserved + (s64)qg->excl + num_bytes >
qg->max_excl) {
ret = -EDQUOT;
goto out;
--
1.7.11.7
--
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
Re: [PATCH V2] Btrfs: fix confusing edquot happening case
I am sorry, please ignore this…I will resend it..
> From: Wang Shilong
>
> Step to reproduce:
> mkfs.btrfs
> mount
> dd if=/dev/zero of=//data bs=1M count=10
> sync
> btrfs quota enable
> btrfs qgroup create 0/5
> btrfs qgroup limit 5M 0/5
> rm -f //data
> sync
> btrfs qgroup show
> dd if=/dev/zero of=data bs=1M count=1
>
> From the perspective of users, qgroup's referenced or exclusive
> is negative,but user can not continue to write data! a workaround
> way is to cast u64 to s64 when doing qgroup reservation.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Arne Jansen
> ---
> Changelog v1->v2:
> -use s64 instead of signed long long
> ---
> fs/btrfs/qgroup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
> index b44124d..ab364a2 100644
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
> num_bytes)
> qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
>
> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
> - qg->reserved + qg->rfer + num_bytes >
> + qg->reserved + (s64)qg->rfer + num_bytes >
> qg->max_rfer) {
> ret = -EDQUOT;
> goto out;
> }
>
> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
> - qg->reserved + qg->excl + num_bytes >
> + qg->reserved + (s64)qg->excl + num_bytes >
> qg->max_excl) {
> ret = -EDQUOT;
> goto out;
> --
> 1.7.11.7
>
--
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
[PATCH V2] Btrfs: fix confusing edquot happening case
From: Wang Shilong
Step to reproduce:
mkfs.btrfs
mount
dd if=/dev/zero of=//data bs=1M count=10
sync
btrfs quota enable
btrfs qgroup create 0/5
btrfs qgroup limit 5M 0/5
rm -f //data
sync
btrfs qgroup show
dd if=/dev/zero of=data bs=1M count=1
>From the perspective of users, qgroup's referenced or exclusive
is negative,but user can not continue to write data! a workaround
way is to cast u64 to s64 when doing qgroup reservation.
Signed-off-by: Wang Shilong
Reviewed-by: Arne Jansen
---
Changelog v1->v2:
-use s64 instead of signed long long
---
fs/btrfs/qgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index b44124d..ab364a2 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
num_bytes)
qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
- qg->reserved + qg->rfer + num_bytes >
+ qg->reserved + (s64)qg->rfer + num_bytes >
qg->max_rfer) {
ret = -EDQUOT;
goto out;
}
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
- qg->reserved + qg->excl + num_bytes >
+ qg->reserved + (s64)qg->excl + num_bytes >
qg->max_excl) {
ret = -EDQUOT;
goto out;
--
1.7.11.7
--
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
Re: [PATCH] Btrfs-progs: add a free space cache checker to fsck V2
On Thu, 4 Apr 2013 09:57:50 -0400, Josef Bacik wrote: > In trying to track down a weird tree log problem I wanted to make sure that > the > free space cache was actually valid, which we currently have no way of doing. > So this patch adds a bunch of support for the free space cache code and then a > checker to fsck. Basically we go through and if we can actually load the free > space cache then we will walk the extent tree and verify that the free space > cache exactly matches what is in the extent tree. Hopefully this will always > be > correct, the only time it wouldn't is if the extent tree is corrupt or we have > some sort of awful bug in the free space cache. Thanks, > > Signed-off-by: Josef Bacik > --- > V1->V2: > - fix ret == 1 from btrfs_search_slot leaking out of verify_space_cache > - check the last bit of free space from the last extent to the end of the > block > group > - unlink any entries we find so we can check and make sure the free space > cache > tree is empty once we're done. > Josef, xfstests 013, 068 and 113 fail with your new fsck free space cache checker, see below. $TEST_DEV /dev/sdc is a 50GB SSD, $SCRATCH_DEV /dev/sds is a 100GB SSD. Default mount options. # mkfs.btrfs -f -n 16384 $SCRATCH_DEV # mkfs.btrfs -f -n 16384 $TEST_DEV # ./check 013 # btrfsck $TEST_DEV Checking filesystem on /dev/sdc UUID: 1c91dbb9-2495-4324-bb53-f96e15cff0dc checking extents checking free space cache Wanted bytes 606208, found 16384 for off 191184896 Wanted bytes 911917056, found 16384 for off 191184896 cache appears valid but isnt 29360128 btrfs: unable to add free space :-17 btrfsck: free-space-cache.c:815: btrfs_add_free_space: Assertion `!(ret == -17)' failed. Aborted # mkfs.btrfs -f -n 16384 $SCRATCH_DEV # mkfs.btrfs -f -n 16384 $TEST_DEV # ./check 013 # btrfsck $TEST_DEV Checking filesystem on /dev/sdc UUID: 18046b2a-9c98-4b34-9294-954d094049c2 checking extents checking free space cache Wanted bytes 16203776, found 9355264 for off 168624128 Wanted bytes 934477824, found 9355264 for off 168624128 cache appears valid but isnt 29360128 There is no free space entry for 1115480064-1115504640 There is no free space entry for 1115480064-2176843776 cache appears valid but isnt 1103101952 found 380784640 bytes used err is -22 total csum bytes: 87084 total tree bytes: 4833280 total fs tree bytes: 4390912 total extent tree bytes: 245760 btree space waste bytes: 952741 file data blocks allocated: 500023296 referenced 363667456 Btrfs v0.20-rc1-298-gf65141e # mkfs.btrfs -f -n 16384 $SCRATCH_DEV # mkfs.btrfs -f -n 16384 $TEST_DEV # ./check 068 _check_btrfs_filesystem: filesystem on /dev/sds is inconsistent *** fsck.btrfs output *** checking extents checking free space cache Wanted bytes 490909696, found 536870912 for off 1103101952 Wanted bytes 1073741824, found 536870912 for off 1103101952 cache appears valid but isnt 1103101952 Checking filesystem on /dev/sds UUID: d5340e2c-d1e5-4155-afc2-70afb6bbbe85 found 638976 bytes used err is -22 total csum bytes: 0 total tree bytes: 114688 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 107558 file data blocks allocated: 524288 referenced 524288 Btrfs v0.20-rc1-298-gf65141e *** end fsck.btrfs output # mkfs.btrfs -f -n 16384 $SCRATCH_DEV # mkfs.btrfs -f -n 16384 $TEST_DEV # ./check 113 _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent *** fsck.btrfs output *** checking extents checking free space cache btrfs: unable to add free space :-17 btrfsck: free-space-cache.c:815: btrfs_add_free_space: Assertion `!(ret == -17)' failed. Checking filesystem on /dev/sdc UUID: 9fef532c-2cf2-4bad-8b00-aa997403b415 *** end fsck.btrfs output -- 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
Re: [PATCH RFC] Btrfs: fix confusing edquot happening case
On 15.04.2013 13:43, Wang Shilong wrote:
> Hello Arne,
>
>> On 15.04.2013 12:37, Wang Shilong wrote:
>>> Step to reproduce:
>>> mkfs.btrfs
>>> mount
>>> dd if=/dev/zero of=//data bs=1M count=10
>>> sync
>>> btrfs quota enable
>>> btrfs qgroup create 0/5
>>> btrfs qgroup limit 5M 0/5
>>> rm -f //data
>>> sync
>>> btrfs qgroup show
>>> dd if=/dev/zero of=data bs=1M count=1
>>>
>>> From the perspective of users, qgroup's referenced or referenced
>>>
>>> is negative,But user can not continue to write data! a workaround
>>> way is to cast u64 to int64 when doing qgroup reservation.
>>>
>>> Signed-off-by: Wang Shilong
>>> ---
>>> This confusing edquot may also happen after Jan's qgroup
>>> rescan has been implemented.
>>> ---
>>> fs/btrfs/qgroup.c |4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>>> index b44124d..0178223 100644
>>> --- a/fs/btrfs/qgroup.c
>>> +++ b/fs/btrfs/qgroup.c
>>> @@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root,
>>> u64 num_bytes)
>>> qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
>>>
>>> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
>>> - qg->reserved + qg->rfer + num_bytes >
>>> + qg->reserved + (signed long long)qg->rfer + num_bytes >
>>
>> why not use s64 instead of signed long long? Otherwise this is the right way
>> to
>> solve this.
>
> Yeah,V2 is coming. By the way, do you mind that i add Acked-by: Arne Jasen
> ?
You can add a Reviewed-by: Arne Jansen
Thanks,
Arne
>
> Thanks,
> Wang
>>
>> Thanks,
>> Arne
>>
>>> qg->max_rfer) {
>>> ret = -EDQUOT;
>>> goto out;
>>> }
>>>
>>> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
>>> - qg->reserved + qg->excl + num_bytes >
>>> + qg->reserved + (signed long long)qg->excl + num_bytes >
>>> qg->max_excl) {
>>> ret = -EDQUOT;
>>> goto out;
>>
>> --
>> 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
>
> --
> 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
--
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
Re: [PATCH RFC] Btrfs: fix confusing edquot happening case
Hello Arne,
> On 15.04.2013 12:37, Wang Shilong wrote:
>> Step to reproduce:
>> mkfs.btrfs
>> mount
>> dd if=/dev/zero of=//data bs=1M count=10
>> sync
>> btrfs quota enable
>> btrfs qgroup create 0/5
>> btrfs qgroup limit 5M 0/5
>> rm -f //data
>> sync
>> btrfs qgroup show
>> dd if=/dev/zero of=data bs=1M count=1
>>
>> From the perspective of users, qgroup's referenced or referenced
>>
>> is negative,But user can not continue to write data! a workaround
>> way is to cast u64 to int64 when doing qgroup reservation.
>>
>> Signed-off-by: Wang Shilong
>> ---
>> This confusing edquot may also happen after Jan's qgroup
>> rescan has been implemented.
>> ---
>> fs/btrfs/qgroup.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>> index b44124d..0178223 100644
>> --- a/fs/btrfs/qgroup.c
>> +++ b/fs/btrfs/qgroup.c
>> @@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root,
>> u64 num_bytes)
>> qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
>>
>> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
>> -qg->reserved + qg->rfer + num_bytes >
>> +qg->reserved + (signed long long)qg->rfer + num_bytes >
>
> why not use s64 instead of signed long long? Otherwise this is the right way
> to
> solve this.
Yeah,V2 is coming. By the way, do you mind that i add Acked-by: Arne Jasen
?
Thanks,
Wang
>
> Thanks,
> Arne
>
>> qg->max_rfer) {
>> ret = -EDQUOT;
>> goto out;
>> }
>>
>> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
>> -qg->reserved + qg->excl + num_bytes >
>> +qg->reserved + (signed long long)qg->excl + num_bytes >
>> qg->max_excl) {
>> ret = -EDQUOT;
>> goto out;
>
> --
> 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
--
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
Re: [PATCH 1/2] Btrfs: rescan for qgroups
On 15.04.2013 09:19, Wang Shilong wrote: > Hello Jan, > >> On Mon, April 15, 2013 at 08:08 (+0200), Wang Shilong wrote: > >>> Hello Jan, >>> On Mon, April 15, 2013 at 07:44 (+0200), Jan Schmidt wrote: > Thanks, v2 to come. Uh, but not immediately. I didn't get tracking of "exclusive" right. That will need some time to fix and test. >>> >>> 'exclusive' adds the complexity of btrfs qgroup. >>> So if you send V2. I'd like you add more lines in changelog. >> >> Yes, the commit message will be longer as you requested previously. This does >> not include a complete description on how "exclusive" works. The qgroup pdf >> explains that. > > > Yeah, changelog really helps for newbies(like me ^_^) > >> >>> Besides, i have a question in my mind.(I have not seen you code).. >>> When qgroup rescan will happen? >>> >>> 1> when quota is enabled >> >> That's what the second patch does, yes. Your patches should be merged in a >> way >> that we first create the level 0 qgroups for all subvolumes and then start >> the >> rescan, obviously. >> >>> 2> if a new qgroup relations is created, rescan should happen? >> >> With your patches, there will be no subvolume qgroups missing. For the higher >> level groups, one needs expert knowledge anyway. I think it's best to leave >> that >> decision to the administrator configuring those qgroups. > > > IMO, it is better that qgroup rescan automatically if a qgroup relation > is added. I think we should leave it as it is, for several reasons: a) the administrator might want to add multiple configurations. Only after the last one a rescan makes sense. b) the config changes might not make a rescan necessary. For example, you could prepare a configuration for newly created or not-yet-existent qgroups. In this case, a rescan of the complete filesystem might be unnecessary. A rescan might even be harmful, as during the rescan the quota is wrong and users can go over quota. Also, a rescan adds significant load to the system. -Arne > > Thank, > Wang > >> >>> 2> user call qgroup rescan.. >> >> Of course, yes. >> >> -Jan >> -- >> 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 >> >> > > > > -- > 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 -- 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
Re: [PATCH RFC] Btrfs: fix confusing edquot happening case
On 15.04.2013 12:37, Wang Shilong wrote:
> Step to reproduce:
> mkfs.btrfs
> mount
> dd if=/dev/zero of=//data bs=1M count=10
> sync
> btrfs quota enable
> btrfs qgroup create 0/5
> btrfs qgroup limit 5M 0/5
> rm -f //data
> sync
> btrfs qgroup show
> dd if=/dev/zero of=data bs=1M count=1
>
> From the perspective of users, qgroup's referenced or referenced
>
> is negative,But user can not continue to write data! a workaround
> way is to cast u64 to int64 when doing qgroup reservation.
>
> Signed-off-by: Wang Shilong
> ---
> This confusing edquot may also happen after Jan's qgroup
> rescan has been implemented.
> ---
> fs/btrfs/qgroup.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
> index b44124d..0178223 100644
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
> num_bytes)
> qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
>
> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
> - qg->reserved + qg->rfer + num_bytes >
> + qg->reserved + (signed long long)qg->rfer + num_bytes >
why not use s64 instead of signed long long? Otherwise this is the right way to
solve this.
Thanks,
Arne
> qg->max_rfer) {
> ret = -EDQUOT;
> goto out;
> }
>
> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
> - qg->reserved + qg->excl + num_bytes >
> + qg->reserved + (signed long long)qg->excl + num_bytes >
> qg->max_excl) {
> ret = -EDQUOT;
> goto out;
--
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
[PATCH RFC] Btrfs: fix confusing edquot happening case
Step to reproduce:
mkfs.btrfs
mount
dd if=/dev/zero of=//data bs=1M count=10
sync
btrfs quota enable
btrfs qgroup create 0/5
btrfs qgroup limit 5M 0/5
rm -f //data
sync
btrfs qgroup show
dd if=/dev/zero of=data bs=1M count=1
>From the perspective of users, qgroup's referenced or referenced
is negative,But user can not continue to write data! a workaround
way is to cast u64 to int64 when doing qgroup reservation.
Signed-off-by: Wang Shilong
---
This confusing edquot may also happen after Jan's qgroup
rescan has been implemented.
---
fs/btrfs/qgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index b44124d..0178223 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1523,14 +1523,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
num_bytes)
qg = (struct btrfs_qgroup *)(uintptr_t)unode->aux;
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
- qg->reserved + qg->rfer + num_bytes >
+ qg->reserved + (signed long long)qg->rfer + num_bytes >
qg->max_rfer) {
ret = -EDQUOT;
goto out;
}
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
- qg->reserved + qg->excl + num_bytes >
+ qg->reserved + (signed long long)qg->excl + num_bytes >
qg->max_excl) {
ret = -EDQUOT;
goto out;
--
1.7.7.6
--
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
[PATCH] Btrfs: do not continue if out of memory happens
If out of memory happens, we should return -ENOMEM directly to the caller
rather than continue the work.
Signed-off-by: Wang Shilong
---
fs/btrfs/backref.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index bd605c8..2fd5703 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -352,6 +352,8 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
err = __resolve_indirect_ref(fs_info, search_commit_root,
time_seq, ref, parents,
extent_item_pos);
+ if (err == -ENOMEM)
+ goto out;
if (err)
continue;
@@ -367,7 +369,7 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
new_ref = kmalloc(sizeof(*new_ref), GFP_NOFS);
if (!new_ref) {
ret = -ENOMEM;
- break;
+ goto out;
}
memcpy(new_ref, ref, sizeof(*ref));
new_ref->parent = node->val;
@@ -377,7 +379,7 @@ static int __resolve_indirect_refs(struct btrfs_fs_info
*fs_info,
}
ulist_reinit(parents);
}
-
+out:
ulist_free(parents);
return ret;
}
-- 1.7.7.6
--
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
Re: [PATCH 1/2] Btrfs: rescan for qgroups
Hello Jan, > On Mon, April 15, 2013 at 08:08 (+0200), Wang Shilong wrote: >> Hello Jan, >> >>> On Mon, April 15, 2013 at 07:44 (+0200), Jan Schmidt wrote: Thanks, v2 to come. >>> Uh, but not immediately. I didn't get tracking of "exclusive" right. That >>> will >>> need some time to fix and test. >> >> 'exclusive' adds the complexity of btrfs qgroup. >> So if you send V2. I'd like you add more lines in changelog. > > Yes, the commit message will be longer as you requested previously. This does > not include a complete description on how "exclusive" works. The qgroup pdf > explains that. Yeah, changelog really helps for newbies(like me ^_^) > >> Besides, i have a question in my mind.(I have not seen you code).. >> When qgroup rescan will happen? >> >> 1> when quota is enabled > > That's what the second patch does, yes. Your patches should be merged in a way > that we first create the level 0 qgroups for all subvolumes and then start the > rescan, obviously. > >> 2> if a new qgroup relations is created, rescan should happen? > > With your patches, there will be no subvolume qgroups missing. For the higher > level groups, one needs expert knowledge anyway. I think it's best to leave > that > decision to the administrator configuring those qgroups. IMO, it is better that qgroup rescan automatically if a qgroup relation is added. Thank, Wang > >> 2> user call qgroup rescan.. > > Of course, yes. > > -Jan > -- > 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 > > -- 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
Re: [PATCH 4/9 v2] btrfs-progs: check if btrfs kernel module is loaded
On 04/13/2013 12:23 AM, David Sterba wrote:
On Wed, Apr 10, 2013 at 04:23:21PM +0800, Anand Jain wrote:
diff --git a/cmds-device.c b/cmds-device.c
index a90fb67..0e1e6de 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -185,9 +185,10 @@ static const char * const cmd_scan_dev_usage[] = {
static int cmd_scan_dev(int argc, char **argv)
{
- int i, fd, e;
+ int i, fd = -1, e, ret = 0;
int checklist = 1;
int devstart = 1;
+ u64 flag_reg = 0ull;
Do you need it to be u64? I see it's used only as a bool flag.
Yes. more below..
+ if (is_btrfs_kernel_loaded())
+ flag_reg = BTRFS_SCAN_REGISTER;
flag_reg = 1;
would work the same, so it should be fine with int.
actually no. The intention was to use it as the
parameter for btrfs_scan_block_devices, v2 fixes
this. Thanks for the catch.
---
- ret = btrfs_scan_block_devices(BTRFS_SCAN_REGISTER);
+ ret = btrfs_scan_block_devices(flag_reg);
---
}
+ printf("Scanning for Btrfs in\n");
...
- printf("Scanning for Btrfs filesystems in '%s'\n", argv[i]);
Please keep the word 'filesystem' in the message
got this in v3
@@ -261,6 +287,10 @@ static int cmd_ready_dev(int argc, char **argv)
if (check_argc_min(argc, 2))
usage(cmd_ready_dev_usage);
+ if (!is_btrfs_kernel_loaded()) {
+ fprintf(stderr, "btrfs kernel module is not loaded\n");
+ return 10;
return 1 or -1
got this into v3
--- a/mkfs.c
+++ b/mkfs.c
@@ -1420,6 +1420,7 @@ int main(int ac, char **av)
u64 flags;
int dev_cnt=0;
int saved_optind;
+ int flag_reg=1;
ah, here it is an 'int'
--- a/utils.c
+++ b/utils.c
@@ -1016,6 +1016,33 @@ struct pending_dir {
+/*
+ * return 1 if btrfs kernel is present
+ * return 0 for not
+ */
+int is_btrfs_kernel_loaded()
+{
+ FILE *pfs;
+ char fsname[100];
+ int ret = -1;
+ char line[100];
+
+ pfs = fopen("/proc/filesystems", "r");
+ if (pfs) {
+ ret = 0;
+ while (fgets(line, sizeof(line), pfs)) {
+ if (sscanf(line, "nodev %[^#\n]\n", fsname) == 1)
continue;
if (!strncmp("nodev", line, 5))
continue;
got this into v3
+ if (sscanf(line, " %[^# \n]\n", fsname) != 1) continue;
+ if (!strcmp(fsname, "btrfs")) {
+ ret = 1;
+ break;
+ }
+ }
+ fclose(pfs);
+ }
+ return ret;
+}
+
void btrfs_register_one_device(char *fname)
{
struct btrfs_ioctl_vol_args args;
@@ -1023,6 +1050,11 @@ void btrfs_register_one_device(char *fname)
int ret;
int e;
+ if (!is_btrfs_kernel_loaded()) {
+ fprintf(stderr, "btrfs kernel module is not loaded, "
+ "skipping device registration\n");
+ return;
+ }
fd = open("/dev/btrfs-control", O_RDONLY);
if (fd < 0) {
fprintf(stderr, "failed to open /dev/btrfs-control "
Otherwise ok.
david
--
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
--
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
[PATCH 06/11 v3] btrfs-progs: check if btrfs kernel module is loaded
when we have to report no such file error for
/dev/btrfs-control we could confirm if btrfs kernel
is present and report it and skip registration
where appropriate
v2->v3:
accept review comments from David
v1->v2: use /proc/filesystems to check if the btrfs
is present
Signed-off-by: Anand Jain
---
cmds-device.c | 62 ---
mkfs.c| 13 +++--
utils.c | 34
utils.h | 2 +-
4 files changed, 92 insertions(+), 19 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index a90fb67..f5dce8d 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -185,9 +185,10 @@ static const char * const cmd_scan_dev_usage[] = {
static int cmd_scan_dev(int argc, char **argv)
{
- int i, fd, e;
+ int i, fd = -1, e, ret = 0;
int checklist = 1;
int devstart = 1;
+ u64 flag_reg = 0ull;
if( argc > 1 && !strcmp(argv[1],"--all-devices")){
if (check_argc_max(argc, 2))
@@ -197,33 +198,57 @@ static int cmd_scan_dev(int argc, char **argv)
devstart += 1;
}
+ if (is_btrfs_kernel_loaded())
+ flag_reg = BTRFS_SCAN_REGISTER;
+ else
+ fprintf(stderr, "btrfs kernel module is not loaded\n");
+
if(argc<=devstart){
int ret;
- printf("Scanning for Btrfs filesystems\n");
+ printf("Scanning for Btrfs filesystems ");
if(checklist)
- ret = btrfs_scan_block_devices(BTRFS_SCAN_REGISTER);
+ ret = btrfs_scan_block_devices(flag_reg);
else
- ret = btrfs_scan_one_dir("/dev", BTRFS_SCAN_REGISTER);
+ ret = btrfs_scan_one_dir("/dev", flag_reg);
if (ret){
fprintf(stderr, "ERROR: error %d while scanning\n",
ret);
return 18;
}
+ printf("..done\n");
return 0;
}
- fd = open("/dev/btrfs-control", O_RDWR);
- if (fd < 0) {
- perror("failed to open /dev/btrfs-control");
- return 10;
+ if (!flag_reg)
+ return -1;
+
+ if ((fd = open("/dev/btrfs-control", O_RDWR)) < 0) {
+ fprintf(stderr, "ERROR: failed to open "\
+ "/dev/btrfs-control - %s\n", strerror(errno));
+ return -1;
}
+ printf("Scanning for Btrfs filesystem in\n");
for( i = devstart ; i < argc ; i++ ){
+ int fdt;
struct btrfs_ioctl_vol_args args;
- int ret;
+ printf(" %s ", argv[i]);
+ fflush(stdout);
- printf("Scanning for Btrfs filesystems in '%s'\n", argv[i]);
+ /*
+* If for a multipath (mp) disk user provides the
+* non-mp path then open with flag O_EXCL will fail,
+* (also ioctl opens with O_EXCL), So test it before
+* calling ioctl.
+*/
+ fdt = open(argv[i], O_RDONLY|O_EXCL);
+ if (fdt < 0) {
+ perror("ERROR");
+ ret = -1;
+ continue;
+ }
+ close(fdt);
strncpy_null(args.name, argv[i]);
/*
@@ -235,15 +260,16 @@ static int cmd_scan_dev(int argc, char **argv)
e = errno;
if( ret < 0 ){
- close(fd);
- fprintf(stderr, "ERROR: unable to scan the device '%s'
- %s\n",
- argv[i], strerror(e));
- return 11;
+ fprintf(stderr, "ERROR: unable to scan - %s\n",
+ strerror(e));
+ ret = -1;
+ } else {
+ printf("found\n");
}
}
close(fd);
- return 0;
+ return ret;
}
static const char * const cmd_ready_dev_usage[] = {
@@ -261,10 +287,14 @@ static int cmd_ready_dev(int argc, char **argv)
if (check_argc_min(argc, 2))
usage(cmd_ready_dev_usage);
+ if (!is_btrfs_kernel_loaded()) {
+ fprintf(stderr, "Error: btrfs kernel module is not loaded\n");
+ return -1;
+ }
fd = open("/dev/btrfs-control", O_RDWR);
if (fd < 0) {
perror("failed to open /dev/btrfs-control");
- return 10;
+ return -1;
}
strncpy(args.name, argv[argc - 1], BTRFS_PATH_NAME_MAX);
diff --git a/mkfs.c b/mkfs.c
index 2eb3087..e8b22cc 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -1301,6 +1301,7 @@ int main(int ac, char **av)
int dev_cnt = 0;
int saved_optind;
char estr[100];
+ int flag_reg = 1;
