compressed btrfs No space left on device
Hi, I'm using btrfs for my /usr/share/ partition and keep getting the following error while installing a debian package which should take no more than 228 MB: Unpacking texlive-fonts-extra (from .../texlive-fonts-extra_2009-10ubuntu1_all.deb) ... dpkg: error processing /var/cache/apt/archives/texlive-fonts-extra_2009-10ubuntu1_all.deb (--unpack): unable to install new version of `/usr/share/texmf-texlive/fonts/type1/public/allrunes/frutlt.pfb': No space left on device However df reports plenty of available space: /dev/mapper/vg0-usr_share 5.0G 1.5G 2.5G 37% /usr/share I already extended /dev/mapper/vg0-usr_share from 4G to 5G and ran defrag and balance on it with no luck. I'm using ubuntu 11.10 on amd64 with the ubuntu 3.0.0 kernel. btrfs reports to use zlib compression. Is this a known problem with compressed btrfs? Best regards Arnd -- 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: satisfy compiler and change printf modifier
One-liner which fixes the gcc warning:
warning: format '%u' expects argument of type 'unsigned int',
but argument 3 has type 'long unsigned int' [-Wformat]
Signed-off-by: Arnd Hannemann a...@arndnet.de
---
extent-tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/extent-tree.c b/extent-tree.c
index 5bed3c2..5211bee 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -1067,7 +1067,7 @@ static int lookup_inline_extent_backref(struct
btrfs_trans_handle *trans,
}
#endif
if (item_size sizeof(*ei)) {
- printf(Size is %u, needs to be %u, slot %d\n, item_size,
+ printf(Size is %u, needs to be %zu, slot %d\n, item_size,
sizeof(*ei), path-slots[0]);
btrfs_print_leaf(root, leaf);
return -EINVAL;
--
1.7.5.4
--
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: Relocate -lpthread in makefile
This patch fixes the following compile error when compiled with gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3): gcc -lpthread -g -O0 -o btrfs btrfs.o btrfs_cmds.o scrub.o \ ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o -luuid scrub.o: In function `scrub_start': /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1342: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1360: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1374: undefined reference to `pthread_join' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1430: undefined reference to `pthread_cancel' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1432: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [btrfs] Error 1 The gcc man page says: [...] the placement of the -l option is significant. so lets include -lpthread together with the usual $(LIBS) Signed-off-by: Arnd Hannemann a...@arndnet.de --- Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 96e2002..834be47 100644 --- a/Makefile +++ b/Makefile @@ -37,8 +37,8 @@ version: bash version.sh btrfs: $(objects) btrfs.o btrfs_cmds.o scrub.o - $(CC) -lpthread $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ - $(objects) $(LDFLAGS) $(LIBS) + $(CC) $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ + $(objects) $(LDFLAGS) $(LIBS) -lpthread calc-size: $(objects) calc-size.o gcc $(CFLAGS) -o calc-size calc-size.o $(objects) $(LDFLAGS) $(LIBS) -- 1.7.5.4 -- 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: satisfy compiler and change printf modifier
Am 14.11.2011 16:30, schrieb Christian Parpart: On Mon, Nov 14, 2011 at 4:24 PM, Arnd Hannemann a...@arndnet.de mailto:a...@arndnet.de wrote: One-liner which fixes the gcc warning: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat] [snip] - printf(Size is %u, needs to be %u, slot %d\n, item_size, + printf(Size is %u, needs to be %zu, slot %d\n, item_size, sizeof(*ei), path-slots[0]); shouldn't it be %lu then (instead of %zu) ? No, the return type of sizeof() is size_t which is of different size on different architectures (eg. amd64 versus i386) If %lu would be used, there would be a warning when compiled on an architecture where long is 32 bit. Best regards, Arnd -- 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: Relocate -lpthread in makefile
On 14.11.2011 16:47, Arnd Hannemann wrote: This patch fixes the following compile error when compiled with gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3): gcc -lpthread -g -O0 -o btrfs btrfs.o btrfs_cmds.o scrub.o \ ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o -luuid scrub.o: In function `scrub_start': /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1342: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1360: undefined reference to `pthread_create' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1374: undefined reference to `pthread_join' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1430: undefined reference to `pthread_cancel' /home/arnd/Projekte/kernel/btrfs-progs/scrub.c:1432: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [btrfs] Error 1 The gcc man page says: [...] the placement of the -l option is significant. so lets include -lpthread together with the usual $(LIBS) Signed-off-by: Arnd Hannemann a...@arndnet.de Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net Sergei also sent this patch a week ago. I agree with you. David, do you want to investigate the -pthread option? -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: WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0
On Thu, Nov 10, 2011 at 01:13:46PM +0100, Stefan Kleijkers wrote:
Hello Josef,
I have a workload running at the moment and I'm seeing a lot of
these (paste 1) messages in dmesg, this is the 3.1 kernel with your
patch applied.
At the end I see a couple of the old warnings (paste 2).
Futhermore it looks like after a while the speed of the filesystem
decreases. I have a workload with 20 rsyncs and a total of about
1.5T data. I don't make it to have a full run.
Hmm well thats interesting, and you'd think that would tell me what was wrong
but I'm still confused :). Give this debug patch a whirl (unapply the last one
I gave you and apply this one instead) and send me your dmesg if you get any of
the new warnings. Thanks,
Josef
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 634608d..395a746 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -74,6 +74,7 @@ struct btrfs_inode {
/* the space_info for where this inode's data allocations are done */
struct btrfs_space_info *space_info;
+ struct btrfs_block_rsv *rsv;
/* full 64 bit generation number, struct vfs_inode doesn't have a big
* enough field for this.
@@ -140,7 +141,7 @@ struct btrfs_inode {
*/
unsigned outstanding_extents;
unsigned reserved_extents;
-
+ unsigned orphan_count;
/*
* ordered_data_close is set by truncate when a file that used
* to have good data has been truncated to zero. When it is set
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index fa4f602..c73f4b1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3721,6 +3721,7 @@ static void block_rsv_release_bytes(struct
btrfs_block_rsv *block_rsv,
spin_lock(block_rsv-lock);
if (num_bytes == (u64)-1)
num_bytes = block_rsv-size;
+ BUG_ON(block_rsv-size num_bytes);
block_rsv-size -= num_bytes;
if (block_rsv-reserved = block_rsv-size) {
num_bytes = block_rsv-reserved - block_rsv-size;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index e16215f..f59231c 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2018,8 +2018,11 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans,
struct inode *inode)
if (!BTRFS_I(inode)-orphan_meta_reserved) {
BTRFS_I(inode)-orphan_meta_reserved = 1;
+ BTRFS_I(inode)-rsv = root-orphan_block_rsv;
reserve = 1;
}
+ WARN_ON(BTRFS_I(inode)-orphan_count);
+ BTRFS_I(inode)-orphan_count++;
spin_unlock(root-orphan_lock);
/* grab metadata reservation from transaction handle */
@@ -2061,9 +2064,12 @@ int btrfs_orphan_del(struct btrfs_trans_handle *trans,
struct inode *inode)
}
if (BTRFS_I(inode)-orphan_meta_reserved) {
+ WARN_ON(BTRFS_I(inode)-rsv != root-orphan_block_rsv);
BTRFS_I(inode)-orphan_meta_reserved = 0;
release_rsv = 1;
}
+ WARN_ON(!BTRFS_I(inode)-orphan_count);
+ BTRFS_I(inode)-orphan_count--;
spin_unlock(root-orphan_lock);
if (trans delete_item) {
@@ -6629,6 +6635,7 @@ struct inode *btrfs_alloc_inode(struct super_block *sb)
spin_lock_init(ei-lock);
ei-outstanding_extents = 0;
ei-reserved_extents = 0;
+ ei-orphan_count = 0;
ei-ordered_data_close = 0;
ei-orphan_meta_reserved = 0;
@@ -6638,6 +6645,7 @@ struct inode *btrfs_alloc_inode(struct super_block *sb)
ei-force_compress = BTRFS_COMPRESS_NONE;
ei-delayed_node = NULL;
+ ei-rsv = NULL;
inode = ei-vfs_inode;
extent_map_tree_init(ei-extent_tree);
--
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/inode.c:3037
Hello, I'm hitting following kernel bug when trying to rmdir empty directory from btrfs filesystem. I'm on Linux 3.1.1-1.fc16.i686.PAE. rmdir ends with segfault. I have found similar problem in this mailing list but not the same one so I'm reporting it. [ 281.284923] btrfs: could not do orphan cleanup -116 [ 433.019128] [ cut here ] [ 433.019155] WARNING: at fs/dcache.c:1270 d_set_d_op+0x2c/0x85() [ 433.019163] Hardware name: System Product Name [ 433.019169] Modules linked in: btrfs zlib_deflate libcrc32c sha256_generic dm_crypt bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 w83627ehf nf_defrag_ipv4 hwmon_vid xt_state nf_conntrack snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer eeepc_wmi snd asus_wmi soundcore r8169 mii sp5100_tco serio_raw i2c_piix4 uinput i2c_core k10temp snd_page_alloc sparse_keymap rfkill microcode firewire_ohci firewire_core crc_itu_t wmi [last unloaded: scsi_wait_scan] [ 433.019303] Pid: 2112, comm: autojump Not tainted 3.1.1-1.fc16.i686.PAE #1 [ 433.019311] Call Trace: [ 433.019327] [c082001f] ? printk+0x2d/0x2f [ 433.019342] [c0447951] warn_slowpath_common+0x7c/0x91 [ 433.019354] [c05068f5] ? d_set_d_op+0x2c/0x85 [ 433.019365] [c05068f5] ? d_set_d_op+0x2c/0x85 [ 433.019377] [c0447988] warn_slowpath_null+0x22/0x24 [ 433.019388] [c05068f5] d_set_d_op+0x2c/0x85 [ 433.019398] [c0510810] simple_lookup+0x25/0x3d [ 433.019409] [c04ffc2e] d_alloc_and_lookup+0x34/0x52 [ 433.019420] [c0500610] walk_component+0x1ec/0x383 [ 433.019431] [c0500ce4] link_path_walk+0x14e/0x3a1 [ 433.019441] [c0501116] ? path_init+0x16a/0x24e [ 433.019452] [c05027de] path_openat+0x8c/0x283 [ 433.019464] [c04d5a80] ? handle_pte_fault+0x34b/0x8ce [ 433.019474] [c0500229] ? putname+0x29/0x2c [ 433.019484] [c0502aae] do_filp_open+0x2b/0x6c [ 433.019496] [c04eb8f5] ? kmem_cache_alloc+0x26/0xe9 [ 433.019508] [c0434d74] ? should_resched+0xd/0x27 [ 433.019522] [c05d99de] ? strncpy_from_user+0x34/0x4e [ 433.019533] [c050ad3a] ? alloc_fd+0x53/0xbf [ 433.019546] [c04f7a1c] do_sys_open+0x5f/0xe5 [ 433.019558] [c0499349] ? call_rcu_sched+0x12/0x14 [ 433.019570] [c04f7ac8] sys_open+0x26/0x2c [ 433.019581] [c0827f14] syscall_call+0x7/0xb [ 433.019589] ---[ end trace 2d971029a7846877 ]--- [ 433.019596] [ cut here ] [ 433.019606] WARNING: at fs/dcache.c:1274 d_set_d_op+0x50/0x85() [ 433.019613] Hardware name: System Product Name [ 433.019618] Modules linked in: btrfs zlib_deflate libcrc32c sha256_generic dm_crypt bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 w83627ehf nf_defrag_ipv4 hwmon_vid xt_state nf_conntrack snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer eeepc_wmi snd asus_wmi soundcore r8169 mii sp5100_tco serio_raw i2c_piix4 uinput i2c_core k10temp snd_page_alloc sparse_keymap rfkill microcode firewire_ohci firewire_core crc_itu_t wmi [last unloaded: scsi_wait_scan] [ 433.019731] Pid: 2112, comm: autojump Tainted: GW 3.1.1-1.fc16.i686.PAE #1 [ 433.019738] Call Trace: [ 433.019748] [c082001f] ? printk+0x2d/0x2f [ 433.019760] [c0447951] warn_slowpath_common+0x7c/0x91 [ 433.019771] [c0506919] ? d_set_d_op+0x50/0x85 [ 433.019781] [c0506919] ? d_set_d_op+0x50/0x85 [ 433.019792] [c0447988] warn_slowpath_null+0x22/0x24 [ 433.019803] [c0506919] d_set_d_op+0x50/0x85 [ 433.019813] [c0510810] simple_lookup+0x25/0x3d [ 433.019822] [c04ffc2e] d_alloc_and_lookup+0x34/0x52 [ 433.019832] [c0500610] walk_component+0x1ec/0x383 [ 433.019843] [c0500ce4] link_path_walk+0x14e/0x3a1 [ 433.019854] [c0501116] ? path_init+0x16a/0x24e [ 433.019864] [c05027de] path_openat+0x8c/0x283 [ 433.019875] [c04d5a80] ? handle_pte_fault+0x34b/0x8ce [ 433.019885] [c0500229] ? putname+0x29/0x2ckernel BUG at fs/btrfs/inode.c:3037 [ 433.019894] [c0502aae] do_filp_open+0x2b/0x6c [ 433.019905] [c04eb8f5] ? kmem_cache_alloc+0x26/0xe9 [ 433.019917] [c0434d74] ? should_resched+0xd/0x27 [ 433.019929] [c05d99de] ? strncpy_from_user+0x34/0x4e [ 433.019940] [c050ad3a] ? alloc_fd+0x53/0xbf [ 433.019952] [c04f7a1c] do_sys_open+0x5f/0xe5 [ 433.019962] [c0499349] ? call_rcu_sched+0x12/0x14 [ 433.019974] [c04f7ac8] sys_open+0x26/0x2c [ 433.019984] [c0827f14] syscall_call+0x7/0xb [ 433.019992] ---[ end trace 2d971029a7846878 ]--- [ 460.693013] [ cut here ] [ 460.693013] kernel BUG at fs/btrfs/inode.c:3037! [ 460.693013] invalid opcode: [#1] SMP [ 460.693013] Modules linked in: btrfs zlib_deflate libcrc32c sha256_generic dm_crypt bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
Re: compressed btrfs No space left on device
Am 14.11.2011 15:57, schrieb Arnd Hannemann: I'm using btrfs for my /usr/share/ partition and keep getting the following error while installing a debian package which should take no more than 228 MB: Unpacking texlive-fonts-extra (from .../texlive-fonts-extra_2009-10ubuntu1_all.deb) ... dpkg: error processing /var/cache/apt/archives/texlive-fonts-extra_2009-10ubuntu1_all.deb (--unpack): unable to install new version of `/usr/share/texmf-texlive/fonts/type1/public/allrunes/frutlt.pfb': No space left on device However df reports plenty of available space: /dev/mapper/vg0-usr_share 5.0G 1.5G 2.5G 37% /usr/share I already extended /dev/mapper/vg0-usr_share from 4G to 5G and ran defrag and balance on it with no luck. I'm using ubuntu 11.10 on amd64 with the ubuntu 3.0.0 kernel. FYI: The problem is the same with mainline kernel v3.1.1. Best regards Arnd -- 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
Bird's eye view of relocation trees
Can someone give a bird's eye view of what relocation trees are and how they are used? I've been looking over the code all morning and can only see that it appears to be a normal root tree, but with a different objectid for some reason. -- 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
Reliability questions / me too for bugs
I have a couple of questions concerning btrfs reliability. I'm currently using btrfs in my internal drives (strong advantages) and have used it on external drives, but I've recently migrated the external ones to ext4, for reliability reasons. The kernel seems to be able to handle ext4 partition disconnections (drive error, cable gets eaten by rodent, or most commonly, unplugged too early on removable drives...) quite gracefully. This is not yet the case for btrfs partitions (deadlocks, various oopses, need to reboot). Any idea when this will be available ? How to handle bad blocks (sometimes, they are very localized on HDDs, and they will happen on old SSDs) ? Imagine the following use case: - get untrusted drive from dumpster - check that it runs, and has an acceptable amount of bad block clusters - add the drive to a btrfs pool, which guarantees that its data will be duplicated somewhere else - enjoy the drive while it lasts - ability to retrieve bad blocks map later on - ability to cleanly remove the drive from the pool if it becomes useless (found a better one) or dies (see first question) when that happens, data gets replicated to other locations... data replication could be done automatically by background scrubbing with some mount flag or ioctl How far are we from that ? Will we get there some day ? Since I'm here, a few random and useless notes, as I'm currently testing v3.2-rc1-284-g52e4c2a and I see a few bugs, deadlocks and weirdnesses. I don't know if it's normal for -rc1, maybe. My current workload is rsync 1.5TB from SATA to USB2+3 (500+1000GB in raid0) and vice versa. The load average can grow to 15. I've ran into BUG at fs/btrfs/inode.c:1795 (http://comments.gmane.org/gmane.comp.file-systems.btrfs/14128). I've ran into WARNING: at fs/btrfs/free-space-cache.c:1847 btrfs_remove_free_space+0x1a3/0x287() [1] I've also ran into INFO: task btrfs-transacti:1465 blocked for more than 120 seconds. [2] Sometimes linux is writing I don't know what for a looong time on drives, and there's nothing in cache. Sometimes rsync stops, doing nothing. It will somehow restart after I do a echo 3 /proc/sys/vm/drop_caches... I see that a lot of features will be added for 3.2 but I hope they will be well tested ! -- cJ [1] 2011-11-13_18:34:29 [2.906392] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) 2011-11-13_18:34:29 [2.987133] device fsid 539bca9b-2e64-4997-9335-ffc648c2ebe5 devid 1 transid 71489 /dev/root 2011-11-13_18:34:29 [3.049089] Btrfs detected SSD devices, enabling SSD mode 2011-11-13_18:34:29 [3.049346] [ cut here ] 2011-11-13_18:34:29 [3.049450] WARNING: at fs/btrfs/free-space-cache.c:1847 btrfs_remove_free_space+0x1a3/0x287() 2011-11-13_18:34:29 [3.049622] Hardware name: To be filled by O.E.M. 2011-11-13_18:34:29 [3.049720] Modules linked in: 2011-11-13_18:34:29 [3.049843] Pid: 1, comm: swapper Not tainted 3.2.0-rc1-Bidule-00284-g52e4c2a #60 2011-11-13_18:34:29 [3.050017] Call Trace: 2011-11-13_18:34:29 [3.050117] [8104dff7] warn_slowpath_common+0x83/0x9b 2011-11-13_18:34:29 [3.050217] [8104e029] warn_slowpath_null+0x1a/0x1c 2011-11-13_18:34:29 [3.050317] [8125dae8] btrfs_remove_free_space+0x1a3/0x287 2011-11-13_18:34:29 [3.050420] [81224a40] btrfs_pin_extent_for_log_replay+0x72/0x89 2011-11-13_18:34:29 [3.050522] [8125a4c5] process_one_buffer+0x3a/0x74 2011-11-13_18:34:29 [3.050622] [812592fd] walk_up_log_tree+0xed/0x1c2 2011-11-13_18:34:29 [3.050722] [81259d46] walk_log_tree+0x9e/0x1a6 2011-11-13_18:34:29 [3.050822] [8125b464] btrfs_recover_log_trees+0x94/0x298 2011-11-13_18:34:29 [3.050922] [8125a48b] ? replay_one_buffer+0x223/0x223 2011-11-13_18:34:29 [3.051026] [812306b1] open_ctree+0x1189/0x14c4 2011-11-13_18:34:29 [3.051128] [81216697] btrfs_mount+0x41e/0x58d 2011-11-13_18:34:29 [3.051228] [810e2b38] ? pcpu_next_pop+0x3d/0x4a 2011-11-13_18:34:29 [3.051329] [8110fe38] mount_fs+0x69/0x155 2011-11-13_18:34:29 [3.051428] [810e3c2c] ? __alloc_percpu+0x10/0x12 2011-11-13_18:34:29 [3.051528] [81124c8f] vfs_kern_mount+0x63/0x9d 2011-11-13_18:34:29 [3.051628] [81124fed] do_kern_mount+0x4d/0xdf 2011-11-13_18:34:29 [3.051727] [81126726] do_mount+0x656/0x6b9 2011-11-13_18:34:29 [3.051827] [810df983] ? memdup_user+0x3d/0x65 2011-11-13_18:34:29 [3.051927] [810df9e6] ? strndup_user+0x3b/0x51 2011-11-13_18:34:29 [3.052029] [81126a5c] sys_mount+0x88/0xc2 2011-11-13_18:34:29 [3.052130] [81a9bc2a] mount_block_root+0xdd/0x1ee 2011-11-13_18:34:29 [3.052230] [81a9befe] mount_root+0xb9/0xc0 2011-11-13_18:34:29 [3.052328] [81a9ca3a] ? initrd_load+0x2e0/0x2e7 2011-11-13_18:34:29 [3.052428] [81a9c072] prepare_namespace+0x16d/0x1a6 2011-11-13_18:34:29 [3.052527] [81a9ba1a] kernel_init+0x13e/0x143
Re: [PATCH 00/21] [RFC] Btrfs: restriper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a fs that started with the default policy of metadata=dup. I added a second device and rebalanced, and so the metadata chunks were converted to raid1. Now I can not remove the second device because raid1 requires at least two devices. If I understand this patch series correctly, I can use it to manually convert those raid1 chunks back to dup, and then remove the second device. It occurs to me though, that in the restripe process, the newly created dup chunks can be allocated from either disk still, and any that are allocated on the second disk will then need to be relocated in order to remove that disk. This seems inefficient, so I was wondering if there is a way to make sure that during the restripe, only the disk I intend to keep is allocated from to create the dup chunks, and thus avoid the need to relocate when I remove the second disk? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7Bq0wACgkQJ4UciIs+XuLoUACeMkb4Pd0zshDDKmVzibYtxmvX GewAnAwKcsCaCaAX2XK6oMWxK6FvZQFc =UxDl -END PGP SIGNATURE- -- 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: Fix up 32/64-bit compatibility for new ioctls
Commit 740c3d22 (Btrfs: fix the new inspection ioctls for 32 bit compat)
uses 64-bit values instead of pointers but the casting throws cast to
integer of different size warnings when built on 32-bit machines.
This patch casts to unsigned long before casting to a pointer and fixes
the following warnings:
fs/btrfs/extent_io.c:2289:20: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
fs/btrfs/ioctl.c:2933:37: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
fs/btrfs/ioctl.c:2937:21: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
fs/btrfs/ioctl.c:3020:21: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
fs/btrfs/scrub.c:275:4: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
fs/btrfs/backref.c:686:27: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/backref.c |2 +-
fs/btrfs/extent_io.c |2 +-
fs/btrfs/ioctl.c |9 ++---
fs/btrfs/scrub.c |2 +-
4 files changed, 9 insertions(+), 6 deletions(-)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -683,7 +683,7 @@ static int inode_to_path(u64 inum, struc
return PTR_ERR(fspath);
if (fspath fspath_min) {
- ipath-fspath-val[i] = (u64)fspath;
+ ipath-fspath-val[i] = (u64)(unsigned long)fspath;
++ipath-fspath-elem_cnt;
ipath-fspath-bytes_left = fspath - fspath_min;
} else {
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2343,7 +2343,7 @@ static void end_bio_extent_readpage(stru
}
if (!uptodate) {
u64 failed_mirror;
- failed_mirror = (u64)bio-bi_bdev;
+ failed_mirror = (unsigned long)bio-bi_bdev;
if (tree-ops tree-ops-readpage_io_failed_hook)
ret = tree-ops-readpage_io_failed_hook(
bio, page, start, end,
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2954,11 +2954,13 @@ static long btrfs_ioctl_ino_to_path(stru
goto out;
for (i = 0; i ipath-fspath-elem_cnt; ++i) {
- rel_ptr = ipath-fspath-val[i] - (u64)ipath-fspath-val;
+ rel_ptr = ipath-fspath-val[i] -
+ (u64)(unsigned long)ipath-fspath-val;
ipath-fspath-val[i] = rel_ptr;
}
- ret = copy_to_user((void *)ipa-fspath, (void *)ipath-fspath, size);
+ ret = copy_to_user((void *)(unsigned long)ipa-fspath,
+ (void *)(unsigned long)ipath-fspath, size);
if (ret) {
ret = -EFAULT;
goto out;
@@ -3041,7 +3043,8 @@ static long btrfs_ioctl_logical_to_ino(s
if (ret 0)
goto out;
- ret = copy_to_user((void *)loi-inodes, (void *)inodes, size);
+ ret = copy_to_user((void *)(unsigned long)loi-inodes,
+ (void *)(unsigned long)inodes, size);
if (ret)
ret = -EFAULT;
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -272,7 +272,7 @@ static int scrub_print_warning_inode(u64
swarn-logical, swarn-dev-name,
(unsigned long long)swarn-sector, root, inum, offset,
min(isize - offset, (u64)PAGE_SIZE), nlink,
- (char *)ipath-fspath-val[i]);
+ (char *)(unsigned long)ipath-fspath-val[i]);
free_ipath(ipath);
return 0;
--
Jeff Mahoney
SUSE Labs
--
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
Reliability questions / me too for bugs
I have a couple of questions concerning btrfs reliability. I'm currently using btrfs in my internal drives (strong advantages) and have used it on external drives, but I've recently migrated the external ones to ext4, for reliability reasons. The kernel seems to be able to handle ext4 partition disconnections (drive error, cable gets eaten by rodent, or most commonly, unplugged too early on removable drives...) quite gracefully. This is not yet the case for btrfs partitions (deadlocks, various oopses, need to reboot). Any idea when this will be available ? How to handle bad blocks (sometimes, they are very localized on HDDs, and they will happen on old SSDs) ? Imagine the following use case: - get untrusted drive from dumpster - check that it runs, and has an acceptable amount of bad block clusters - add the drive to a btrfs pool, which guarantees that its data will be duplicated somewhere else - enjoy the drive while it lasts - ability to retrieve bad blocks map later on - ability to cleanly remove the drive from the pool if it becomes useless (found a better one) or dies (see first question) when that happens, data gets replicated to other locations... data replication could be done automatically by background scrubbing with some mount flag or ioctl How far are we from that ? Will we get there some day ? Since I'm here, a few random and useless notes, as I'm currently testing v3.2-rc1-284-g52e4c2a and I see a few bugs, deadlocks and weirdnesses. I don't know if it's normal for -rc1, maybe. My current workload is rsync 1.5TB from SATA to USB2+3 (500+1000GB in raid0) and vice versa. The load average can grow to 15. I've ran into BUG at fs/btrfs/inode.c:1795 (http://comments.gmane.org/gmane.comp.file-systems.btrfs/14128). I've ran into WARNING: at fs/btrfs/free-space-cache.c:1847 btrfs_remove_free_space+0x1a3/0x287() [1] I've also ran into INFO: task btrfs-transacti:1465 blocked for more than 120 seconds. [2] Sometimes linux is writing I don't know what for a looong time on drives, and there's nothing in cache. Sometimes rsync stops, doing nothing. It will somehow restart after I do a echo 3 /proc/sys/vm/drop_caches... I see that a lot of features will be added for 3.2 but I hope they will be well tested ! -- cJ [1] 2011-11-13_18:34:29 [2.906392] md: Skipping autodetection of RAID arrays. (raid=autodetect will force) 2011-11-13_18:34:29 [2.987133] device fsid 539bca9b-2e64-4997-9335-ffc648c2ebe5 devid 1 transid 71489 /dev/root 2011-11-13_18:34:29 [3.049089] Btrfs detected SSD devices, enabling SSD mode 2011-11-13_18:34:29 [3.049346] [ cut here ] 2011-11-13_18:34:29 [3.049450] WARNING: at fs/btrfs/free-space-cache.c:1847 btrfs_remove_free_space+0x1a3/0x287() 2011-11-13_18:34:29 [3.049622] Hardware name: To be filled by O.E.M. 2011-11-13_18:34:29 [3.049720] Modules linked in: 2011-11-13_18:34:29 [3.049843] Pid: 1, comm: swapper Not tainted 3.2.0-rc1-Bidule-00284-g52e4c2a #60 2011-11-13_18:34:29 [3.050017] Call Trace: 2011-11-13_18:34:29 [3.050117] [8104dff7] warn_slowpath_common+0x83/0x9b 2011-11-13_18:34:29 [3.050217] [8104e029] warn_slowpath_null+0x1a/0x1c 2011-11-13_18:34:29 [3.050317] [8125dae8] btrfs_remove_free_space+0x1a3/0x287 2011-11-13_18:34:29 [3.050420] [81224a40] btrfs_pin_extent_for_log_replay+0x72/0x89 2011-11-13_18:34:29 [3.050522] [8125a4c5] process_one_buffer+0x3a/0x74 2011-11-13_18:34:29 [3.050622] [812592fd] walk_up_log_tree+0xed/0x1c2 2011-11-13_18:34:29 [3.050722] [81259d46] walk_log_tree+0x9e/0x1a6 2011-11-13_18:34:29 [3.050822] [8125b464] btrfs_recover_log_trees+0x94/0x298 2011-11-13_18:34:29 [3.050922] [8125a48b] ? replay_one_buffer+0x223/0x223 2011-11-13_18:34:29 [3.051026] [812306b1] open_ctree+0x1189/0x14c4 2011-11-13_18:34:29 [3.051128] [81216697] btrfs_mount+0x41e/0x58d 2011-11-13_18:34:29 [3.051228] [810e2b38] ? pcpu_next_pop+0x3d/0x4a 2011-11-13_18:34:29 [3.051329] [8110fe38] mount_fs+0x69/0x155 2011-11-13_18:34:29 [3.051428] [810e3c2c] ? __alloc_percpu+0x10/0x12 2011-11-13_18:34:29 [3.051528] [81124c8f] vfs_kern_mount+0x63/0x9d 2011-11-13_18:34:29 [3.051628] [81124fed] do_kern_mount+0x4d/0xdf 2011-11-13_18:34:29 [3.051727] [81126726] do_mount+0x656/0x6b9 2011-11-13_18:34:29 [3.051827] [810df983] ? memdup_user+0x3d/0x65 2011-11-13_18:34:29 [3.051927] [810df9e6] ? strndup_user+0x3b/0x51 2011-11-13_18:34:29 [3.052029] [81126a5c] sys_mount+0x88/0xc2 2011-11-13_18:34:29 [3.052130] [81a9bc2a] mount_block_root+0xdd/0x1ee 2011-11-13_18:34:29 [3.052230] [81a9befe] mount_root+0xb9/0xc0 2011-11-13_18:34:29 [3.052328] [81a9ca3a] ? initrd_load+0x2e0/0x2e7 2011-11-13_18:34:29 [3.052428] [81a9c072] prepare_namespace+0x16d/0x1a6 2011-11-13_18:34:29 [3.052527] [81a9ba1a] kernel_init+0x13e/0x143
