Re: Balancing takes forever
On Fri, Jul 1, 2011 at 4:32 PM, Christian cdys...@gmail.com wrote: I tried to balance my home folder. The disk spins and after an hour it hasn't completed. This is a 300 GB home directory about half full. I know balance takes while, but how long should it take? This is a 7200 rpm disk on a dual 2 ghz processor laptop running Linux Mint 11 and btrfs 0.19. It has an ext2 /boot, a btrfs / and btrfs /home partitions. The btrfs partitions have compression enabled. Balance currently rewrites everything, and does it in a not-terribly-efficient way. It's probably done by now (8 hours since your message), which isn't unusual. There's some improvements in the pipeline, but they're not in a released kernel yet. -- 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] print parent ID in btrfs suvolume list
On 07/01/2011 12:21 PM, Andreas Philipp wrote:
There was some discussion on where subvolumes live in. Why do we not
simply print the parent ID for each subvolume in btrfs subvolume list?
This patch adds this functionality when called with parameter -p.
Can I ask you to update the man page too ?
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
V1-V2: do not change the default behavior but rather add the switch -p.
btrfs-list.c | 24 ++--
btrfs.c |6 --
btrfs_cmds.c | 17 +++--
btrfs_cmds.h |2 +-
4 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index f804dfc..be20c91 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -200,9 +200,10 @@ static int add_root(struct root_lookup *root_lookup,
* This can't be called until all the root_info-path fields are filled
* in by lookup_ino_path
*/
-static int resolve_root(struct root_lookup *rl, struct root_info *ri)
+static int resolve_root(struct root_lookup *rl, struct root_info *ri, int
print_parent)
{
u64 top_id;
+ u64 parent_id = 0;
char *full_path = NULL;
int len = 0;
struct root_info *found;
@@ -233,6 +234,11 @@ static int resolve_root(struct root_lookup *rl, struct
root_info *ri)
}
next = found-ref_tree;
+ /* record the first parent */
+ if ( parent_id == 0 ) {
+ parent_id = next;
+ }
+
/* if the ref_tree refers to ourselves, we're at the top */
if (next == found-root_id) {
top_id = next;
@@ -249,9 +255,15 @@ static int resolve_root(struct root_lookup *rl, struct
root_info *ri)
break;
}
}
- printf(ID %llu top level %llu path %s\n,
-(unsigned long long)ri-root_id, (unsigned long long)top_id,
-full_path);
+ if (print_parent) {
+ printf(ID %llu parent %llu top level %llu path %s\n,
+(unsigned long long)ri-root_id, (unsigned long
long)parent_id, (unsigned long long)top_id,
+ full_path);
+ } else {
+ printf(ID %llu top level %llu path %s\n,
+(unsigned long long)ri-root_id, (unsigned long
long)top_id,
+ full_path);
+ }
free(full_path);
return 0;
}
@@ -549,7 +561,7 @@ build:
return full;
}
-int list_subvols(int fd)
+int list_subvols(int fd, int print_parent)
{
struct root_lookup root_lookup;
struct rb_node *n;
@@ -666,7 +678,7 @@ int list_subvols(int fd)
while (n) {
struct root_info *entry;
entry = rb_entry(n, struct root_info, rb_node);
- resolve_root(root_lookup, entry);
+ resolve_root(root_lookup, entry, print_parent);
n = rb_prev(n);
}
diff --git a/btrfs.c b/btrfs.c
index 87cc680..d09823a 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -66,9 +66,11 @@ static struct Command commands[] = {
not passed).,
NULL
},
- { do_subvol_list, 1, subvolume list, path\n
+ { do_subvol_list, -1, subvolume list, [-p] path\n
List the snapshot/subvolume of a filesystem.,
- NULL
+ [-p] path\n
+ List the snapshot/subvolume of a filesystem.\n
+ -pprint parent ID
},
{ do_set_default_subvol, 2,
subvolume set-default, id path\n
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 062e7d7..9e0c9bc 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -303,9 +303,22 @@ int do_subvol_list(int argc, char **argv)
{
int fd;
int ret;
+ int print_parent = 0;
char *subvol;
+int optind = 1;
- subvol = argv[1];
+ while(1) {
+ int c = getopt(argc, argv, p);
+ if (c 0) break;
+ switch(c) {
+ case 'p':
+ print_parent = 1;
+ optind++;
+ break;
+ }
+ }
+
+ subvol = argv[optind];
ret = test_issubvolume(subvol);
if (ret 0) {
@@ -322,7 +335,7 @@ int do_subvol_list(int argc, char **argv)
fprintf(stderr, ERROR: can't access '%s'\n, subvol);
return 12;
}
- ret = list_subvols(fd);
+ ret = list_subvols(fd, print_parent);
if (ret)
return 19;
return 0;
diff --git a/btrfs_cmds.h b/btrfs_cmds.h
index 61456fa..83faa5b 100644
--- a/btrfs_cmds.h
+++ b/btrfs_cmds.h
@@ -34,7 +34,7 @@ int do_scan(int nargs, char **argv);
int do_resize(int nargs, char **argv);
int do_subvol_list(int nargs, char **argv);
int do_set_default_subvol(int nargs, char **argv);
-int list_subvols(int fd);
+int list_subvols(int fd, int print_parent);
int do_df_filesystem(int nargs,
Re: [PATCH] Btrfs: initial online fsck support
On Friday 01 of July 2011 19:48:36 Andi Kleen wrote: Li Zefan l...@cn.fujitsu.com writes: This is an initial version of online fsck. What it does is: - check the dir item and dir index pointing to a file. - check the structure of extents of a file. As furthur work, we should consider: - fix but not only check the structure of a file. - verify the extent allocation tree on the fly. It's scary to have a fsck in kernel space. Is there no way to do this from user space? -Andi There will be a userspace fsck (Chris Mason is working on it ATM). The two big features of btrfs are self-healing and online fsck, those have to be implemented in kernel space. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- 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: initial online fsck support
The two big features of btrfs are self-healing and online fsck, those have to Are they? be implemented in kernel space. Why? There have been online fscks in user space in the past, e.g. the various schemes using LVM snapshots for ext* and other related work on the BSD FFS. I don't see any principal reason why it couldn't be done for btrfs either. A good fsck is quite complex and you are unlikely to want all that code in kernel space. -Andi -- 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
TRIM support
Hello, I just installed an archlinux with btrfs root partition and would like to set the correct mount properties Following this: https://wiki.archlinux.org/index.php/Solid_State_Drives it says there that I should use the discard mount parameter to enable TRIM. I would like to ask by using ssd mount parameter would TRIM be enabled? The SSD is Intel 320 Series 120Gb Thanks Leonidas -- Caution: breathing may be hazardous to your health. -- 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: initial online fsck support
On Saturday 02 of July 2011 19:04:43 Andi Kleen wrote: The two big features of btrfs are self-healing and online fsck, those have to Are they? they are scheduled to be, just like RAID5/6, mixed RAID in single FS... be implemented in kernel space. Why? There have been online fscks in user space in the past, e.g. the various schemes using LVM snapshots for ext* and other related work on the BSD FFS. I don't see any principal reason why it couldn't be done for btrfs either. Doing a fsck on LVM snapshot of btrfs: 1. is impossible (UUIDs) 2. won't fix errors I have to note that I don't know how FFS fsck is implemented. A good fsck is quite complex and you are unlikely to want all that code in kernel space. complete one, yes, but it's not quite pointless, ZFS does it like this and admins rather like it -- Hubert Kario QBS - Quality Business Software ul. Ksawerów 30/85 02-656 Warszawa POLAND tel. +48 (22) 646-61-51, 646-74-24 fax +48 (22) 646-61-50 -- 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: TRIM support
On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: Hello, I just installed an archlinux with btrfs root partition and would like to set the correct mount properties Following this: https://wiki.archlinux.org/index.php/Solid_State_Drives it says there that I should use the discard mount parameter to enable TRIM. I would like to ask by using ssd mount parameter would TRIM be enabled? The SSD is Intel 320 Series 120Gb No, the ssd mount parameter has nothing to do with TRIM. The ssd mount parameter adjusts a couple of tuning parameters where the default setting is designed to improve performance on spinning HDD, and instead tunes for the random-access ability of an SSD. The ssd option is automatically enabled if the kernel detects that your drive is an SSD (you can check with 'cat /proc/mounts'). The discard option is not currently automatically enabled; I think there may have been some performance issues in certain cases with drives that have slow trim implementations. But feel free to give it a try. -- Calvin Walton calvin.wal...@kepstin.ca -- 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: Balancing takes forever
On 07/02/2011 01:47 AM, cwillu wrote: Balance currently rewrites everything, and does it in a not-terribly-efficient way. It's probably done by now (8 hours since your message), which isn't unusual. There's some improvements in the pipeline, but they're not in a released kernel yet. Thanks. That explains time used on this. It ended up taking around two hours. It also raises another question: Since I enabled compression after having used the file system for a while will all files that aren't compressed be compressed during the full balance process? -- 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 -- //Christian -- 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: don't panic if we get an error while balancing V2
A user reported an error where if we try to balance an fs after a device has been removed it will blow up. This is because we get an EIO back and this is where BUG_ON(ret) bites us in the ass. To fix we just exit. Thanks, Reported-by: Anand Jain anand.j...@oracle.com Signed-off-by: Josef Bacik jo...@redhat.com --- V1-V2: only break if ret is actually set, I always screw this up. fs/btrfs/volumes.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 1efa56e..19450bc 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -2098,7 +2098,8 @@ int btrfs_balance(struct btrfs_root *dev_root) chunk_root-root_key.objectid, found_key.objectid, found_key.offset); - BUG_ON(ret ret != -ENOSPC); + if (ret ret != -ENOSPC) + goto error; key.offset = found_key.offset - 1; } ret = 0; -- 1.7.5.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: [GIT PULL] Btrfs updates for 3.1
On 07/01/2011 04:39 PM, Josef Bacik wrote: Hey Chris, Since I'm going on vacation next week I wanted to get everything ready for you in case you get bored with fsck and want to put together a 3.1 tree :). If you can pull git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git for-chris It is based on your for-linus branch. Here is the shortlog and diffstat Ugh sorry I had to update the don't panic patch because I'm an idiot. Thanks, Josef -- 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: TRIM support
On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos artafi...@gmail.com wrote: On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton calvin.wal...@kepstin.ca wrote: On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: Hello, I just installed an archlinux with btrfs root partition and would like to set the correct mount properties Following this: https://wiki.archlinux.org/index.php/Solid_State_Drives it says there that I should use the discard mount parameter to enable TRIM. I would like to ask by using ssd mount parameter would TRIM be enabled? The SSD is Intel 320 Series 120Gb No, the ssd mount parameter has nothing to do with TRIM. The ssd mount parameter adjusts a couple of tuning parameters where the default setting is designed to improve performance on spinning HDD, and instead tunes for the random-access ability of an SSD. The ssd option is automatically enabled if the kernel detects that your drive is an SSD (you can check with 'cat /proc/mounts'). The discard option is not currently automatically enabled; I think there may have been some performance issues in certain cases with drives that have slow trim implementations. But feel free to give it a try. -- Calvin Walton calvin.wal...@kepstin.ca On the same system when I try to compile the btrfs-tools I get an error. Since on the wiki you mention only the packages for Fedora and Debian, Which are the requirements for the btrfs tools? PS: AUR package is broken as well. -- Caution: breathing may be hazardous to your health. -- 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
