storing metadata on a dedicated device
Hello, I just wanted to ask if storing metadata on a dedicated device is implemented at the moment ? It's listed under Project ideas and there is supposed to be a patch but I can't find it anywhere. Greetings Jan Killius -- 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: storing metadata on a dedicated device
On 04/10/2012 02:57 PM, Jan Killius wrote: Hello, I just wanted to ask if storing metadata on a dedicated device is implemented at the moment ? It's listed under Project ideas and there is supposed to be a patch but I can't find it anywhere. AFAIK, not yet, but it is on plan :) -- liubo -- 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: storing metadata on a dedicated device
On Tue, Apr 10, 2012 at 03:06:28PM +0800, Liu Bo wrote: I just wanted to ask if storing metadata on a dedicated device is implemented at the moment ? It's listed under Project ideas and there is supposed to be a patch but I can't find it anywhere. AFAIK, not yet, but it is on plan :) There was a proposed patchset called 'Speed profiles' by Arne Jan, (c) 2011, not merged http://thread.gmane.org/gmane.comp.file-systems.btrfs/8980 http://thread.gmane.org/gmane.comp.file-systems.btrfs/9017 (progs) 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: [RFC] [PATCH 2/2] Btrfs: move over to use -update_time
On Mon, Apr 09, 2012 at 11:16:05AM -0400, J. Bruce Fields wrote: Nobody yet, I'm going to send a patch shortly that will support this. Thanks, Great. It would also be far preferable if it was just always on (at least by default) rather than requiring a mount option. [looks into Josef's patch] it is, no mount option needed. 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
Snapper packages for Ubuntu
Hi, I've created snapper packages for Ubuntu, available on https://launchpad.net/~snapper/+archive/stable. For those new to snapper, it's a tool for managing btrfs snapshots (http://en.opensuse.org/Portal:Snapper). It depends on libblocxx available from https://launchpad.net/~bjoern-esser-n/+archive/blocxx , and currently uses git source up to commit 50dec40. I've done some limited testing and it seems to to work correctly so far. There's a small, distro-independent patch needed for it to work correctly though. I'm sending it as a separate mail. @Arvin, @MGE, I don't know the correct list for snapper development so I'm cc-ing you both. If there's a dedicated list for snapper please let me know and I'll post further updates there. -- Fajar -- 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] Snapper: Always create .snapshot dir unconditonally
Current version of snapper (commit 50dec40) bails out with this error if .snapshots directory doesn't exist (as is the case on new snapper install): 2012-04-10 16:15:30,241 ERROR libsnapper(17784) Snapshot.cc(nextNumber):362 - mkdir failed errno:2 (No such file or directory) This patch tries to create .snapshots dir unconditionally. Signed-off-by: Fajar A. Nugraha git...@fajar.net --- snapper/Snapshot.cc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/snapper/Snapshot.cc b/snapper/Snapshot.cc index 8e9cc37..277fad7 100644 --- a/snapper/Snapshot.cc +++ b/snapper/Snapshot.cc @@ -353,6 +353,9 @@ namespace snapper if (snapper-getFilesystem()-checkSnapshot(num)) continue; + // try to create .snapshots dir unconditionally + mkdir(snapper-infosDir().c_str(), 0711); + if (mkdir((snapper-infosDir() + / + decString(num)).c_str(), 0777) == 0) break; -- 1.7.9.1 -- 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: snapper for Ubuntu? (WAS: btrfs auto snapshot)
On Mon, Apr 09, 2012 at 08:18:45AM +0700, Fajar A. Nugraha wrote: On Thu, Mar 1, 2012 at 8:48 PM, Arvin Schnell aschn...@suse.de wrote: We have now created a project in the openSUSE buildservice were we provide snapper packages for various distributions, e.g. RHEL6 and Fedora 16. Please find the downloads at: http://download.opensuse.org/repositories/filesystems:/snapper/ I'll also add a link from the snapper home page: http://en.opensuse.org/Portal:Snapper. I have tested snapper on Fedora 16 and found no problems. Hi Arvin, I noticed that openSUSE buildservice now provides debs for ubuntu as well. I can't seem to find a way to add it to apt source list though, using the usual line deb uri distribution [component1] You can use these commands: echo 'deb http://download.opensuse.org/repositories/filesystems:/snapper/Debian_6.0/ /' /etc/apt/sources.list apt-get update apt-get install snapper Regards, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- 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: Snapper packages for Ubuntu
On Tue, Apr 10, 2012 at 05:37:38PM +0700, Fajar A. Nugraha wrote: Hi, I've created snapper packages for Ubuntu, available on https://launchpad.net/~snapper/+archive/stable. For those new to snapper, it's a tool for managing btrfs snapshots (http://en.opensuse.org/Portal:Snapper). It depends on libblocxx available from https://launchpad.net/~bjoern-esser-n/+archive/blocxx , and currently uses git source up to commit 50dec40. I've done some limited testing and it seems to to work correctly so far. libblocxx is not required for snapper anymore since about a month. It's checked during configure. Regards, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- 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: Snapper packages for Ubuntu
On Tue, Apr 10, 2012 at 6:50 PM, Arvin Schnell aschn...@suse.de wrote: On Tue, Apr 10, 2012 at 05:37:38PM +0700, Fajar A. Nugraha wrote: Hi, I've created snapper packages for Ubuntu, available on https://launchpad.net/~snapper/+archive/stable. For those new to snapper, it's a tool for managing btrfs snapshots (http://en.opensuse.org/Portal:Snapper). It depends on libblocxx libblocxx is not required for snapper anymore since about a month. It's checked during configure. You're right. I just tested it, and not having libblocxx during compilation results in less dependencies (namely libblocxx itself, plus libssl, libcrypto, and libpcre). What functionality, if any, is not available when not using libblocxx? Since it's still used when present during configure, I assume it's good for something. Thanks. Fajar -- 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: Boot speed/mount time regression with 3.4.0-rc2
On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote: On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote: On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote: On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote: Hi, I have a system that's using a dracut-generated initramfs to mount a btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've noticed that the process of mounting the root filesystem takes much longer with 3.4.0-rc2 than it did with 3.3.1 - nearly 30 seconds slower! And the bisect results are in: 285ff5af6ce358e73f53b55c9efadd4335f4c2ff is the first bad commit commit 285ff5af6ce358e73f53b55c9efadd4335f4c2ff Author: Josef Bacik jo...@redhat.com Date: Fri Jan 13 15:27:45 2012 -0500 Btrfs: remove the ideal caching code Ok can you give this a whirl? You are going to have to boot/reboot a few times to let the cache get re-generated again to make sure it's taken effect, but hopefully this will help out. Thanks, Unfortunately, it doesn't seem to help. Even after 3 or 4 reboots with this patch applied I'm still seeing the same delay. Alright my laptop is on btrfs, I'll build my tree and see if I can see the same thing and then narrow down whats going on. If not you will be seeing many more patches from me ;). 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: Snapper packages for Ubuntu
On Tue, Apr 10, 2012 at 08:08:15PM +0700, Fajar A. Nugraha wrote: On Tue, Apr 10, 2012 at 6:50 PM, Arvin Schnell aschn...@suse.de wrote: libblocxx is not required for snapper anymore since about a month. It's checked during configure. You're right. I just tested it, and not having libblocxx during compilation results in less dependencies (namely libblocxx itself, plus libssl, libcrypto, and libpcre). What functionality, if any, is not available when not using libblocxx? Since it's still used when present during configure, I assume it's good for something. It's just used for logging. With blocxx an application linking libsnapper can use blocxx functions to control and redirect logging. Regards, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- 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: snapper for Ubuntu? (WAS: btrfs auto snapshot)
On Tue, Apr 10, 2012 at 6:46 PM, Arvin Schnell aschn...@suse.de wrote: On Mon, Apr 09, 2012 at 08:18:45AM +0700, Fajar A. Nugraha wrote: I noticed that openSUSE buildservice now provides debs for ubuntu as well. I can't seem to find a way to add it to apt source list though, using the usual line deb uri distribution [component1] You can use these commands: echo 'deb http://download.opensuse.org/repositories/filesystems:/snapper/Debian_6.0/ /' /etc/apt/sources.list I didn't know you could use that format :D Just tested it, and it works, although the command I use is echo 'deb http://download.opensuse.org/repositories/filesystems:/snapper/Debian_6.0/ /' | sudo tee /etc/apt/sources.list.d/opensuse-snapper.list apt-get update That got me the error W: GPG error: http://download.opensuse.org Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2DA6FAF4175BFA4E easily fixed though, using $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 2DA6FAF4175BFA4E ... and then another apt-get update after that. apt-get install snapper That result in a warning WARNING: The following packages cannot be authenticated! libsnapper snapper Install these packages without verification [y/N]? Did the package creation process somehow ommit signing process, perhaps? Or is there something else I missed? Anyway, I got snapper-0.0.10-0 installed now, but having a small problem. I use different subvolumes for multiple directories. For example, /home and /data. Creating the config for both results in an error $ sudo snapper list-configs Config | Subvolume ---+-- $ sudo snapper create-config /home $ sudo snapper create-config /data Creating config failed (config already exists). $ sudo snapper list-configs Config | Subvolume ---+-- root | /home How can I create config for /data or other directories (other than manually creating the config file and .snapshots directory)? -- Fajar -- 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: storing metadata on a dedicated device
Please, don't reply above full quote. On 10.04.2012 10:34, Jan Killius wrote: Any plans to merge/develop further ? Yes, but not high in priority. The old patch set was basically working (as far as I remember), but there's no chance you can just happily apply it to the current btrfs code without substantial rewrite. -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
Re: snapper for Ubuntu? (WAS: btrfs auto snapshot)
On 2012-04-10 T 20:48 +0700 Fajar A. Nugraha wrote: Anyway, I got snapper-0.0.10-0 installed now, but having a small problem. I use different subvolumes for multiple directories. For example, /home and /data. Creating the config for both results in an error $ sudo snapper list-configs Config | Subvolume ---+-- $ sudo snapper create-config /home $ sudo snapper create-config /data Creating config failed (config already exists). $ sudo snapper list-configs Config | Subvolume ---+-- root | /home How can I create config for /data or other directories (other than manually creating the config file and .snapshots directory)? This should do it: sudo snapper -c home create-config /home sudo snapper -c data create-config /data The reasons for the extra -c name is that you have to tell snapper, which name to choose for the configuration you want to create. This name is the one you can reference in future actions such as create/modify/delete. HTH so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE® Linux Enterprise SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- 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: snapper for Ubuntu? (WAS: btrfs auto snapshot)
On Tue, Apr 10, 2012 at 9:35 PM, Matthias G. Eckermann m...@suse.com wrote: On 2012-04-10 T 20:48 +0700 Fajar A. Nugraha wrote: How can I create config for /data or other directories (other than manually creating the config file and .snapshots directory)? This should do it: sudo snapper -c home create-config /home sudo snapper -c data create-config /data The reasons for the extra -c name is that you have to tell snapper, which name to choose for the configuration you want to create. This name is the one you can reference in future actions such as create/modify/delete. Great! That works, thanks. Is there an oposite of create-config, i.e. delete for just one subvolume? delete-config seems to delete everything (configs for all subvolume and all snapshots). Also, one minor detail, I noticed that the cron configuration file is /etc/sysconfig/snapper. It should be /etc/default/snapper in ubuntu/debian. -- Fajar -- 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: Boot speed/mount time regression with 3.4.0-rc2
On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote:
On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote:
On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
Hi,
I have a system that's using a dracut-generated initramfs to mount a
btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
noticed that the process of mounting the root filesystem takes much
longer with 3.4.0-rc2 than it did with 3.3.1 - nearly 30 seconds slower!
And the bisect results are in:
285ff5af6ce358e73f53b55c9efadd4335f4c2ff is the first bad commit
commit 285ff5af6ce358e73f53b55c9efadd4335f4c2ff
Author: Josef Bacik jo...@redhat.com
Date: Fri Jan 13 15:27:45 2012 -0500
Btrfs: remove the ideal caching code
Ok can you give this a whirl? You are going to have to boot/reboot a few
times
to let the cache get re-generated again to make sure it's taken effect, but
hopefully this will help out. Thanks,
Unfortunately, it doesn't seem to help. Even after 3 or 4 reboots with
this patch applied I'm still seeing the same delay.
Ok drop that previous patch and give this one a whirl, it helped on my laptop.
This is only half of the problem AFAICS, but it's the easier half to fix, in
the meantime I need to lock down why we're not writing out cache for a bunch of
block groups, but thats trickier since the messages I need are spit out while
I'm shutting down, so I need to get creative. Let me know if/how much this
helps. Thanks,
Josef
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a844204..4a871f0 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -529,9 +529,7 @@ static int cache_block_group(struct btrfs_block_group_cache
*cache,
* allocate blocks for the tree root we can't do the fast caching since
* we likely hold important locks.
*/
- if (trans (!trans-transaction-in_commit)
- (root root != root-fs_info-tree_root)
- btrfs_test_opt(root, SPACE_CACHE)) {
+ if (fs_info-mount_opt BTRFS_MOUNT_SPACE_CACHE) {
ret = load_free_space_cache(fs_info, cache);
spin_lock(cache-lock);
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 054707e..baaa518 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -748,13 +748,6 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
u64 used = btrfs_block_group_used(block_group-item);
/*
-* If we're unmounting then just return, since this does a search on the
-* normal root and not the commit root and we could deadlock.
-*/
- if (btrfs_fs_closing(fs_info))
- return 0;
-
- /*
* If this block group has been marked to be cleared for one reason or
* another then we can't trust the on disk cache, so just return.
*/
@@ -768,6 +761,8 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
path = btrfs_alloc_path();
if (!path)
return 0;
+ path-search_commit_root = 1;
+ path-skip_locking = 1;
inode = lookup_free_space_inode(root, block_group, path);
if (IS_ERR(inode)) {
--
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] Revert Btrfs: increase the global block reserve estimates
On Tue, Apr 10, 2012 at 12:40:08AM +0200, David Sterba wrote: On Mon, Apr 09, 2012 at 09:37:08AM +0800, Liu Bo wrote: The whole thing is about our overcommit stuff, that is, since we are not able to get _precise_ number of reservation right now, we usually reserve more than what we need. For this, we've done overcommit dance (thanks for Josef's work!) but it's still not enough for our reservation when we still have some disk space. I'm ok with this revert, but since we don't use up all the reserved space in most time, I assume the following can be an alternative, thanks, Unfortunatelly the situation looks not good for 3.3 btrfs users, I'm looking for something we know that somehow (ie like in 3.2) works and are able to submit to the stable tree very soon. I'll definitelly test your alternative and if Chris applies it during the -rc phase we'll have more time to verify it or you/Josef fix it in another way. Lets do the alternative of reverting the patch and dropping the warning. I've been trying to find a small and simple patch for that but I don't think that's going to happen for a stable commit. -chris -- 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: btrfs 3.2.2 - 3.3.1 upgrade finally ate babies, some advice?
On 10.04.2012 12:07, Ilya Dryomov wrote: On Tue, Apr 10, 2012 at 01:19:54AM +0200, David Sterba wrote: IIRC somebody reported similar problem recently. It basically means there's an inconsistent balance state. Adding Ilya to CC. Leho, so you just mount with discard patch and run 'btrfs fi balance mnt', correct ? The problem is that you have balance state on disk (from trying to run balance earlier w/o discard patch) but we are failing to pick it up on mount. Could you please post the entire dmesg and the output of 'btrfs-debug-tree -ddev' somewhere ? Could you also apply the debug patch below, mount your fs and send me dmesg output (no need to run balance, just mount) ? Your understanding of situation based on above is correct. Yes I can do all the stuff, but it's going to take until next week, since I'm travelling and I can't risk BUG-ing my server remotely. -- 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: Boot speed/mount time regression with 3.4.0-rc2
On Tue, 2012-04-10 at 11:16 -0400, Josef Bacik wrote: On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote: On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote: On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote: On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote: Hi, I have a system that's using a dracut-generated initramfs to mount a btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've noticed that the process of mounting the root filesystem takes much longer with 3.4.0-rc2 than it did with 3.3.1 - nearly 30 seconds slower! Ok drop that previous patch and give this one a whirl, it helped on my laptop. This is only half of the problem AFAICS, but it's the easier half to fix, in the meantime I need to lock down why we're not writing out cache for a bunch of block groups, but thats trickier since the messages I need are spit out while I'm shutting down, so I need to get creative. Let me know if/how much this helps. Thanks, This one brings the mount time right down on my laptop, it's back to around 0.5 seconds, same as 3.3.x. Tested-by: Calvin Walton calvin.wal...@kepstin.ca I'll keep following this email thread; let me know if you have any other patches that you want me to try out. -- 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: kernel BUG at fs/btrfs/volumes.c:2733
On Fri, Mar 30, 2012 at 10:44:05PM +0200, Sander wrote:
Ilya Dryomov wrote (ao):
On Fri, Mar 30, 2012 at 07:49:56PM +0200, Sander wrote:
Thanks. btrfs-debug-tree confirms that you've got a balance item on
media.
After that mount it back and see if there is btrfs: continuing
balance line in dmesg (and if btrfs-balance kthread shows up)?
There is no such line in dmesg, and currently no btrfs-balance kthread
is running. I've pulled Chris Masons for-linus and booted with the
resulting kernel.
And given the above it's weird. We are failing to locate the item
during mount for some reason and I would like to find out why. So if
you are up for running debugging patches (really just compiling btrfs
module and sending me dmesg output) I would appreciate that.
Sure, please send me patches.
I'm sorry this took a week, I was backed up. If you still have that fs
around in that state, could you please apply the patch below, mount it
and send me dmesg output ? (no need to run balance or anything, just
mount)
Thanks,
Ilya
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 20196f4..86fa082 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1867,6 +1867,7 @@ int open_ctree(struct super_block *sb,
csum_root = fs_info-csum_root = btrfs_alloc_root(fs_info);
chunk_root = fs_info-chunk_root = btrfs_alloc_root(fs_info);
dev_root = fs_info-dev_root = btrfs_alloc_root(fs_info);
+printk(open_ctree\n);
if (!tree_root || !extent_root || !csum_root ||
!chunk_root || !dev_root) {
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index a872b48..2e39348 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2834,6 +2834,7 @@ static int balance_kthread(void *data)
mutex_lock(fs_info-balance_mutex);
set_balance_control(bctl);
+printk(balance_kthread: flags %llu\n, (unsigned long long)bctl-flags);
if (btrfs_test_opt(fs_info-tree_root, SKIP_BALANCE)) {
printk(KERN_INFO btrfs: force skipping balance\n);
@@ -2858,6 +2859,7 @@ int btrfs_recover_balance(struct btrfs_root *tree_root)
struct btrfs_key key;
int ret;
+printk(recover_balance\n);
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
@@ -2872,7 +2874,11 @@ int btrfs_recover_balance(struct btrfs_root *tree_root)
key.type = BTRFS_BALANCE_ITEM_KEY;
key.offset = 0;
+printk(key.obj %llu\n, (unsigned long long)key.objectid);
+printk(key.type %d\n, key.type);
+printk(key.off %llu\n, (unsigned long long)key.offset);
ret = btrfs_search_slot(NULL, tree_root, key, path, 0, 0);
+printk(search ret %d\n, ret);
if (ret 0)
goto out_bctl;
if (ret 0) { /* ret = -ENOENT; */
--
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: Boot speed/mount time regression with 3.4.0-rc2
On Tue, Apr 10, 2012 at 12:04:00PM -0400, Calvin Walton wrote: On Tue, 2012-04-10 at 11:16 -0400, Josef Bacik wrote: This one brings the mount time right down on my laptop, it's back to around 0.5 seconds, same as 3.3.x. Did you notice any change during umount? 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: Boot speed/mount time regression with 3.4.0-rc2
On Tue, 2012-04-10 at 18:29 +0200, David Sterba wrote: On Tue, Apr 10, 2012 at 12:04:00PM -0400, Calvin Walton wrote: On Tue, 2012-04-10 at 11:16 -0400, Josef Bacik wrote: This one brings the mount time right down on my laptop, it's back to around 0.5 seconds, same as 3.3.x. Did you notice any change during umount? That's hard to tell, given that it's the root filesystem on my laptop (and the only btrfs filesystem on the computer). I don't think it added very much, if any time to rebooting my computer - but that's a remount read-only, not an unmount. -- 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
[PATCH] Btrfs: use commit root when loading free space cache
A user reported that booting his box up with btrfs root on 3.4 was way
slower than on 3.3 because I removed the ideal caching code. It turns out
that we don't load the free space cache if we're in a commit for deadlock
reasons, but since we're reading the cache and it hasn't changed yet we are
safe reading the inode and free space item from the commit root, so do that
and remove all of the deadlock checks so we don't unnecessarily skip loading
the free space cache. The user reported this fixed the slowness. Thanks,
Tested-by: Calvin Walton calvin.wal...@kepstin.ca
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/extent-tree.c |4 +---
fs/btrfs/free-space-cache.c |9 ++---
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a844204..4a871f0 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -529,9 +529,7 @@ static int cache_block_group(struct btrfs_block_group_cache
*cache,
* allocate blocks for the tree root we can't do the fast caching since
* we likely hold important locks.
*/
- if (trans (!trans-transaction-in_commit)
- (root root != root-fs_info-tree_root)
- btrfs_test_opt(root, SPACE_CACHE)) {
+ if (fs_info-mount_opt BTRFS_MOUNT_SPACE_CACHE) {
ret = load_free_space_cache(fs_info, cache);
spin_lock(cache-lock);
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 054707e..baaa518 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -748,13 +748,6 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
u64 used = btrfs_block_group_used(block_group-item);
/*
-* If we're unmounting then just return, since this does a search on the
-* normal root and not the commit root and we could deadlock.
-*/
- if (btrfs_fs_closing(fs_info))
- return 0;
-
- /*
* If this block group has been marked to be cleared for one reason or
* another then we can't trust the on disk cache, so just return.
*/
@@ -768,6 +761,8 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
path = btrfs_alloc_path();
if (!path)
return 0;
+ path-search_commit_root = 1;
+ path-skip_locking = 1;
inode = lookup_free_space_inode(root, block_group, path);
if (IS_ERR(inode)) {
--
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
Introducing btrfs-next
Hello, In an effort to be a little bit better about reviewing patches sent to the mailinglist I've created a btrfs-next git tree kernel.org. You can get it here git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git I'm going to be scraping the mailinglist every day for patches that are sent and applying them to this tree in order to get some better testing throughout the development cycle and possibly stop being such a lazy bum about reviewing. If you are looking to get patches into the next merge window and you notice I haven't included them in this tree please let me know so I can pull them in, I did a very casual look through the list to find stuff so I probably missed something. Thanks much, 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: Bulk discard doesn't work after add/delete of devices
Hi, the issue I raised in this thread is still not fixed. Please, could someone look into it? A fix should be simple, especially as the issue is easily reproducable. (In case the information in this thread so far is not sufficient for that I will happily provide a recipe; just ask.) Also, I believe so far not even a regression test has been added for this issue. Here's the state of affairs again, as I mailed previously: I have seen that in the meantime a patch for this issue has found its way into 3.3-rc5. Unfortunately with this kernel my filesystem still says 0 bytes were trimmed, so the bug is not fixed for me. Now that might just have been caused by the fact that the patch that went into 3.3-rc5 (as commit 2cac13e41bf5b99ffc426bd28dfd2248df1dfa67) is the one from Liu Bo's mail 4f3386d8.6010...@cn.fujitsu.com, which I already responded to by saying it didn't help my issue. But the next patch Liu sent (in the mail 4f34795b.2020...@cn.fujitsu.com) also does not help. At first I responded to that mail: Thanks for providing the new patch. I think it will work in the case that fstrim is called without specifying a range to trim (that is, defaulting to the whole filesystem), but I didn't test that yet, sorry. I was too optimistic. I have now tested this second patch and still get 0 bytes were trimmed. Thanks for providing btrfs! Greetings, Lutz -- 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
kernel BUG at fs/btrfs/extent_io.c:3982!
Hi, I hit this BUG today. I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4, i.e. 3.3.1 + commit bc3f116fec194 Btrfs: update the checks for mixed block groups with big metadata blocks commit c01a935b9 rbd: move snap_rwsem to the device, rename to header_rwsem The btrfs filesystem in question is backing a Ceph OSD under a heavy write load. Here's the bug: [510342.517157] [ cut here ] [510342.521855] kernel BUG at fs/btrfs/extent_io.c:3982! [510342.526894] invalid opcode: [#1] SMP [510342.531102] CPU 4 [510342.533028] Modules linked in: btrfs zlib_deflate ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr ipv6 ib_sa iw_cxgb4 dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath scsi_dh vhost_net macvtap macvlan tun kvm uinput sg sd_mod joydev ata_piix libata button microcode mpt2sas scsi_transport_sas raid_class scsi_mod serio_raw pcspkr mlx4_ib ib_mad ib_core mlx4_en mlx4_core cxgb4 i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support ehci_hcd uhci_hcd ioatdma dm_mod i7core_edac edac_core nfs nfs_acl auth_rpcgss fscache lockd sunrpc tg3 bnx2 igb dca e1000 [last unloaded: scsi_wait_scan] [510342.587836] [510342.589412] Pid: 16609, comm: kworker/4:2 Not tainted 3.3.1-00162-gd8b2857 #15 Supermicro X8DTH-i/6/iF/6F/X8DTH [510342.599601] RIP: 0010:[a057924c] [a057924c] btrfs_release_extent_buffer_page.clone.0+0x2c/0x130 [btrfs] [510342.610893] RSP: 0018:88015fb6ba10 EFLAGS: 00010202 [510342.616277] RAX: 0004 RBX: 880ab81865a0 RCX: 880174bc0230 [510342.623476] RDX: 8801335bf9b1 RSI: 000d0fb8 RDI: 880ab81865a0 [510342.630675] RBP: 88015fb6ba40 R08: 0038 R09: 0003 [510342.637874] R10: 0008 R11: 8804658c9e40 R12: 88015fb6a000 [510342.645069] R13: 880ab81865a0 R14: 000e R15: 88015fb6bc10 [510342.652268] FS: () GS:880627c8() knlGS: [510342.660418] CS: 0010 DS: ES: CR0: 8005003b [510342.666234] CR2: ff600400 CR3: 01a05000 CR4: 06e0 [510342.673427] DR0: DR1: DR2: [510342.680627] DR3: DR6: 0ff0 DR7: 0400 [510342.687827] Process kworker/4:2 (pid: 16609, threadinfo 88015fb6a000, task 880102ca4410) [510342.696669] Stack: [510342.698769] 8801 880ab81865a0 88015fb6a000 8806057d2eb0 [510342.706297] 000e 88015fb6bc10 88015fb6ba70 a05793f2 [510342.713825] 88015fb6bb80 880ab81865a0 88015fb6bb50 0008 [510342.721362] Call Trace: [510342.723912] [a05793f2] release_extent_buffer+0xa2/0xe0 [btrfs] [510342.730790] [a05795b4] free_extent_buffer+0x34/0x80 [btrfs] [510342.737407] [a057a126] btree_write_cache_pages+0x246/0x410 [btrfs] [510342.744637] [a054e96a] btree_writepages+0x3a/0x50 [btrfs] [510342.751060] [810fc421] do_writepages+0x21/0x40 [510342.756537] [810f0b0b] __filemap_fdatawrite_range+0x5b/0x60 [510342.763136] [810f0de3] filemap_fdatawrite_range+0x13/0x20 [510342.769568] [a0554ecf] btrfs_write_marked_extents+0x7f/0xe0 [btrfs] [510342.776867] [a0554f5e] btrfs_write_and_wait_marked_extents+0x2e/0x60 [btrfs] [510342.784951] [a0554fbb] btrfs_write_and_wait_transaction+0x2b/0x50 [btrfs] [510342.792768] [a055604c] btrfs_commit_transaction+0x7ac/0xa10 [btrfs] [510342.800060] [81079540] ? set_next_entity+0x90/0xa0 [510342.805875] [8105f5d0] ? wake_up_bit+0x40/0x40 [510342.811365] [a0556590] ? btrfs_end_transaction+0x20/0x20 [btrfs] [510342.818403] [a05565af] do_async_commit+0x1f/0x30 [btrfs] [510342.824748] [a0556590] ? btrfs_end_transaction+0x20/0x20 [btrfs] [510342.831774] [81058680] process_one_work+0x140/0x490 [510342.837673] [8105a417] worker_thread+0x187/0x3f0 [510342.843319] [8105a290] ? manage_workers+0x120/0x120 [510342.849225] [8105f02e] kthread+0x9e/0xb0 [510342.854176] [81486c64] kernel_thread_helper+0x4/0x10 [510342.860168] [8147d84a] ? retint_restore_args+0xe/0xe [510342.866161] [8105ef90] ? kthread_freezable_should_stop+0x80/0x80 [510342.873198] [81486c60] ? gs_change+0xb/0xb [510342.878322] Code: 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 66 66 66 66 90 8b 47 38 49 89 fd 85 c0 75 0c 48 8b 47 20 4c 8d 7f 20 84 c0 79 04 0f 0b eb fe 48 8b 47 20 a8 04 75 f4 48 8b 07 49 89 c4 4c 03 67 [510342.898331] RIP [a057924c] btrfs_release_extent_buffer_page.clone.0+0x2c/0x130 [btrfs] [510342.907294] RSP 88015fb6ba10 [510342.911241] ---[ end trace 62013c6b6e2e5135 ]--- Please let me know if there is anything I can do to help track this down. Thanks -- Jim -- To unsubscribe from this list: send the
Re: kernel BUG at fs/btrfs/extent_io.c:3982!
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote: Hi, I hit this BUG today. I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4, i.e. 3.3.1 + commit bc3f116fec194 Btrfs: update the checks for mixed block groups with big metadata blocks commit c01a935b9 rbd: move snap_rwsem to the device, rename to header_rwsem The btrfs filesystem in question is backing a Ceph OSD under a heavy write load. Here's the bug: [510342.517157] [ cut here ] [510342.521855] kernel BUG at fs/btrfs/extent_io.c:3982! Could you please confirm that line number is this BUG_ON() BUG_ON(extent_buffer_under_io(eb)); Josef has a theory on this one, but I want to make sure we're chasing the right thing. -chris -- 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: kernel BUG at fs/btrfs/extent_io.c:3982!
On 04/10/2012 02:24 PM, Chris Mason wrote: On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote: Hi, I hit this BUG today. I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4, i.e. 3.3.1 + commit bc3f116fec194 Btrfs: update the checks for mixed block groups with big metadata blocks commit c01a935b9 rbd: move snap_rwsem to the device, rename to header_rwsem The btrfs filesystem in question is backing a Ceph OSD under a heavy write load. Here's the bug: [510342.517157] [ cut here ] [510342.521855] kernel BUG at fs/btrfs/extent_io.c:3982! Could you please confirm that line number is this BUG_ON() BUG_ON(extent_buffer_under_io(eb)); Yep, that's definitely it: git blame fs/btrfs/extent_io.c | grep -w 3982 0b32f4bb (Josef Bacik2012-03-13 09:38:00 -0400 3982) BUG_ON(extent_buffer_under_io(eb)); Josef has a theory on this one, but I want to make sure we're chasing the right thing. Great, thanks. I'll be happy to test any patches, if needed. -- Jim -chris -- 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
