Re: [3.0-rc1] kernel BUG at fs/btrfs/relocation.c:4285!
(2011/05/31 15:13), liubo wrote: On 05/31/2011 12:31 PM, Tsutomu Itoh wrote: (2011/05/31 10:13), Chris Mason wrote: Excerpts from Tsutomu Itoh's message of 2011-05-30 20:27:51 -0400: The panic occurred when 'btrfs fi bal /test5' was executed. /test5 is as follows: # mount -o space_cache,compress=lzo /dev/sdc3 /test5 # # btrfs fi sh /dev/sdc3 Label: none uuid: 38ec48b2-a64b-4225-8cc6-5eb08024dc64 Total devices 5 FS bytes used 7.87MB devid1 size 10.00GB used 2.02GB path /dev/sdc3 devid2 size 15.01GB used 3.00GB path /dev/sdc5 devid3 size 15.01GB used 3.00GB path /dev/sdc6 devid4 size 20.01GB used 2.01GB path /dev/sdc7 devid5 size 10.00GB used 2.01GB path /dev/sdc8 Btrfs v0.19-50-ge6bd18d # btrfs fi df /test5 Data, RAID0: total=10.00GB, used=3.52MB Data: total=8.00MB, used=1.60MB System, RAID1: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=216.00KB Metadata: total=8.00MB, used=0.00 The oops is happening as we write inode cache during a commit during thekk balance. I did run a number of balances on the inode cache code, do you have a test script that sets up the filesystem to recreate this? Yes, I have. In my test, the panic is done at frequency once every about ten times. I attached the test script to this mail. (though it is a dirty test script that scrapes up script...) I'm getting it to run, hope we can get something valuable. ;) I executed again, the write error occurred though the panic have not occurred. See below: = ... + sleep 30 + ./fsync3.sh Tue May 31 13:50:57 JST 2011 + btrfs fi bal /test5 + wait write error: Inappropriate ioctl for device cmp: EOF on /test5/_de100.t ... ... $ ls -l /test5/_de100* -rw-r--r-- 1 root root 30 May 31 13:56 /test5/_de100.f -rw-r--r-- 1 root root 607789056 May 31 13:56 /test5/_de100.t write error occurred by writing in /test5/_de100.t or mistake of error number? (it should be ENOSPC??) (operation: copy from /test5/_de100.f to /test5/_de100.t) = And, in my environment, it seems to be easy for the script attached to this mail to do the panic. thanks, liubo Thanks, Tsutomu -chris RT2.tar.gz Description: application/gzip
btrfs hang on brd
Hi I seem to be able to get btrfs reproducibly to produce warnings and finally hang when running a stress test on a ramdisk. Testing was done using the integration-test branch of btrfs-unstable. Note that I also tested v2.6.39 and integration-test took much longer to hang i.e. it is an improvement The test script and stack dumps are below. Is this a valid test? Is it worth me investigating these? Regards Adrian Test #!/bin/sh sudo modprobe brd rd_size=262144 sudo umount /mnt/test/ 2 /dev/null echo 'mkfs.btrfs /dev/ram0' sudo mkfs.btrfs /dev/ram0 sudo mkdir -p /mnt/test echo 'mount -t btrfs /dev/ram0 /mnt/test' sudo mount -t btrfs /dev/ram0 /mnt/test sudo mkdir -p /mnt/test/test sudo chown $USER /mnt/test/test sudo chgrp $USER /mnt/test/test sudo umount /mnt/test full=0 i=0 while true; do sudo mount -t btrfs /dev/ram0 /mnt/test if df | grep ram0 | grep 100% /dev/null; then full=`expr $full \+ 1` if test $full -gt 6;then rm -rf /mnt/test/test/* full=0 fi else full=0 fi fsstress -c -r -d /mnt/test/test -p 3 -n 1000 -l 10 sudo umount /mnt/test i=`expr $i \+ 1` echo $i done Stack dumps for warnings [ 7481.520750] WARNING: at fs/btrfs/extent-tree.c:5648 btrfs_alloc_free_block+0x14e/0x357 [btrfs]() [ 7481.520753] Hardware name: XPS 8300 [ 7481.520754] Modules linked in: tcp_lp tun btrfs zlib_deflate libcrc32c brd fuse cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec broadcom tg3 snd_hwdep snd_seq snd_seq_device snd_pcm joydev pcspkr iTCO_wdt iTCO_vendor_support dcdbas serio_raw i2c_i801 snd_timer snd microcode soundcore snd_page_alloc usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 7481.520805] Pid: 3980, comm: btrfs-endio-wri Not tainted 2.6.39-integration-test-20110526-01+ #2 [ 7481.520808] Call Trace: [ 7481.520818] [8104df7a] warn_slowpath_common+0x85/0x9d [ 7481.520824] [8104dfac] warn_slowpath_null+0x1a/0x1c [ 7481.520838] [a02dfca8] btrfs_alloc_free_block+0x14e/0x357 [btrfs] [ 7481.520865] [a030a073] ? map_private_extent_buffer+0xb1/0xd5 [btrfs] [ 7481.520875] [a02d2987] __btrfs_cow_block+0x102/0x31e [btrfs] [ 7481.520883] [a02d1300] ? btrfs_set_item_key+0x3/0x20 [btrfs] [ 7481.520892] [a02d2ca7] btrfs_cow_block+0x104/0x14d [btrfs] [ 7481.520910] [a02d5a87] btrfs_search_slot+0x162/0x502 [btrfs] [ 7481.520925] [a02e3e66] btrfs_lookup_file_extent+0x3c/0x3e [btrfs] [ 7481.520936] [a02d2124] ? btrfs_alloc_path+0x1a/0x2b [btrfs] [ 7481.520955] [a02f9319] btrfs_drop_extents+0x10e/0x731 [btrfs] [ 7481.520960] [8103cc9e] ? need_resched+0x23/0x2d [ 7481.520966] [81474da6] ? _cond_resched+0xe/0x22 [ 7481.520972] [8110d58c] ? slab_pre_alloc_hook.clone.32+0x2d/0x31 [ 7481.520977] [8110e0c7] ? kmem_cache_alloc+0x29/0xf7 [ 7481.521002] [a02f09fa] insert_reserved_file_extent.clone.34+0x70/0x1fc [btrfs] [ 7481.521027] [a03071c9] ? lock_extent_bits+0x5e/0xa8 [btrfs] [ 7481.521044] [a02f362c] btrfs_endio_direct_write+0x171/0x29a [btrfs] [ 7481.521060] [a02e6afc] ? end_workqueue_fn+0xf6/0x10e [btrfs] [ 7481.521065] [81141934] bio_endio+0x2d/0x2f [ 7481.521087] [a02e6b07] end_workqueue_fn+0x101/0x10e [btrfs] [ 7481.521101] [a0310951] worker_loop+0x193/0x4ca [btrfs] [ 7481.521116] [a03107be] ? btrfs_queue_worker+0x214/0x214 [btrfs] [ 7481.521119] [81068dce] kthread+0x82/0x8a [ 7481.521124] [8147db64] kernel_thread_helper+0x4/0x10 [ 7481.521136] [81068d4c] ? kthread_worker_fn+0x14b/0x14b [ 7481.521141] [8147db60] ? gs_change+0x13/0x13 [ 7481.521144] ---[ end trace abb147a5624a0a24 ]--- [ 7481.521161] [ cut here ] [ 7481.521176] WARNING: at fs/btrfs/extent-tree.c:5648 btrfs_alloc_free_block+0x14e/0x357 [btrfs]() [ 7481.521178] Hardware name: XPS 8300 [ 7481.521180] Modules linked in: tcp_lp tun btrfs zlib_deflate libcrc32c brd fuse cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec broadcom tg3 snd_hwdep snd_seq snd_seq_device snd_pcm joydev pcspkr iTCO_wdt iTCO_vendor_support dcdbas serio_raw i2c_i801 snd_timer snd microcode soundcore snd_page_alloc usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 7481.521237] Pid: 3980, comm: btrfs-endio-wri Tainted: GW 2.6.39-integration-test-20110526-01+ #2 [
WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: Removing old temporary files. Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10. Now in my /var/log/messages, I found the following warning - and because it happens when removing temporary/old files, that might be why the computer has so much trouble: May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: May 30 23:25:17 localhost kernel: [17117.213598] [8104daeb] ? warn_slowpath_common+0x7b/0xc0 May 30 23:25:17 localhost kernel: [17117.213625] [a01b650c] ? btrfs_alloc_free_block+0x22c/0x370 [btrfs] May 30 23:25:17 localhost kernel: [17117.213636] [8139cc4c] ? schedule+0x53c/0xd70 May 30 23:25:17 localhost kernel: [17117.213643] [8139ccbc] ? schedule+0x5ac/0xd70 May 30 23:25:17 localhost kernel: [17117.213672] [a01e8a1f] ? read_extent_buffer+0xcf/0x1e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213698] [a01a2853] ? __btrfs_cow_block+0x163/0x8d0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213727] [a01bfc69] ? btrfs_buffer_uptodate+0x49/0x70 [btrfs] May 30 23:25:17 localhost kernel: [17117.213753] [a01a30d9] ? btrfs_cow_block+0x119/0x2b0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213778] [a01a8b5c] ? btrfs_search_slot+0x1dc/0x9b0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213807] [a01bb493] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs] May 30 23:25:17 localhost kernel: [17117.213837] [a01d32b0] ? btrfs_drop_extents+0xc0/0x960 [btrfs] May 30 23:25:17 localhost kernel: [17117.213847] [810096a5] ? __switch_to+0xc5/0x300 May 30 23:25:17 localhost kernel: [17117.213854] [811f2861] ? rb_insert_color+0x101/0x140 May 30 23:25:17 localhost kernel: [17117.213863] [8111ffdc] ? kmem_cache_alloc+0x15c/0x180 May 30 23:25:17 localhost kernel: [17117.213894] [a01c93a9] ? insert_reserved_file_extent.constprop.48+0x69/0x230 [btrfs] May 30 23:25:17 localhost kernel: [17117.213926] [a01ca272] ? btrfs_finish_ordered_io+0x2f2/0x330 [btrfs] May 30 23:25:17 localhost kernel: [17117.213935] [8105d93a] ? del_timer_sync+0x2a/0x50 May 30 23:25:17 localhost kernel: [17117.213965] [a01e4372] ? end_bio_extent_writepage+0x122/0x160 [btrfs] May 30 23:25:17 localhost kernel: [17117.213994] [a01be2c9] ? end_workqueue_fn+0x39/0x120 [btrfs] May 30 23:25:17 localhost kernel: [17117.214020] [a01f118e] ? worker_loop+0x14e/0x4e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.214047] [a01f1040] ? worker_loop+0x0/0x4e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.214054] [8106eb3e] ? kthread+0x7e/0x90 May 30 23:25:17 localhost kernel: [17117.214061] [8100bc24] ? kernel_thread_helper+0x4/0x10 May 30 23:25:17 localhost kernel: [17117.214068] [8106eac0] ? kthread+0x0/0x90 May 30 23:25:17 localhost kernel: [17117.214075] [8100bc20] ? kernel_thread_helper+0x0/0x10 May 30 23:25:17 localhost kernel: [17117.214080] ---[ end trace 6e2121230335769a ]--- May 30 23:25:17 localhost kernel: [17117.214109] [ cut here ] May 30 23:25:17 localhost kernel: [17117.214135] WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]() May 30 23:25:17 localhost kernel: [17117.214140] Hardware name: Presario CQ56 Notebook PC -- 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/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400: Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: Removing old temporary files. Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10. Now in my /var/log/messages, I found the following warning - and because it happens when removing temporary/old files, that might be why the computer has so much trouble: May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: Do you have the very first full oops? This has the call trace, but not the beginning text that describes why we've crashed. -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: WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Am 31.05.2011 10:18, schrieb Chris Mason: Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400: Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: Removing old temporary files. Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10. Now in my /var/log/messages, I found the following warning - and because it happens when removing temporary/old files, that might be why the computer has so much trouble: May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: Do you have the very first full oops? This has the call trace, but not the beginning text that describes why we've crashed. -chris Hi Chris, the log starts here - before May 30 21:40:52 there is for 6 hours nothing. It's the beginning of the logging. I'm sorry to say so, but I'm absolutely unable to boot into 3.0rc1 I used a complete with luks encrypted btrfs partition, there is only another /boot partition with ext4 - and this system is running since march 2010. On other kernels (2.6.38 or 2.6.39) - the logging starts much more early - but like I said - the load was unbelieveable high the whole time, the hard disks reached maximum temperature (so it was very hard to lay the hands on the computer) - and my only explanation are these entries. May 30 21:40:52 localhost -- MARK -- May 30 21:41:22 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Amunet8'. Retrying on a new circuit. May 30 21:41:37 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Wallnut'. Retrying on a new circuit. May 30 21:41:52 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Amunet6'. Retrying on a new circuit. May 30 21:42:07 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'politkovskaja'. Retrying on a new circuit. May 30 21:42:22 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'BostonUCompSci'. Retrying on a new circuit. May 30 21:42:37 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'rainbowwarrior'. Retrying on a new circuit. May 30 21:42:52 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'ada'. Retrying on a new circuit. May 30 21:42:52 localhost Tor[1422]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up. May 30 21:51:10 localhost kernel: [11470.581905] [ cut here ] May 30 21:51:10 localhost kernel: [11470.581965] WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]() May 30 21:51:10 localhost kernel: [11470.581972] Hardware name: Presario CQ56 Notebook PC May 30 21:51:10 localhost kernel: [11470.581976] Modules linked in: cryptd aes_x86_64 aes_generic ipt_REJECT ipt_LOG xt_limit xt_tcpudp ipt_addrtype xt_state ip6table_filter ip6_tables nf_nat_irc nf_conntrack_irc nf_nat_ftp nf _nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables ipv6 fuse cpufreq_conservative cpufreq_powersave cpufreq_ondemand fglrx(P) snd_hda_codec_realtek powernow_k8 freq_table mper f snd_hda_intel snd_hda_codec radeon ttm snd_pcm_oss snd_hwdep joydev snd_pcm drm_kms_helper drm uvcvideo hp_wmi snd_mixer_oss snd_timer i2c_algo_bit videodev snd i2c_piix4 soundcore v4l2_compat_ioctl32 sparse_keymap wmi arc4 edac_core evdev snd_page_alloc ecb sp5100_tco battery shpchp processor sg edac_mce_amd psmouse i2c_core video thermal k10temp pci_hotplug pcspkr serio_raw button ac brcm80211(C) mac80211 cfg80211 rfkill r8169 mii uvesafb cn sh a256_generic twofish_generic twofish_x86_64 twofish_common cbc usbhid hid dm_crypt dm_mod btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 ohci_hcd ehci_hcd sr_mod cdrom usbcore sd_mod ahci libahci libata scsi_mod -- 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: Damaged super block / fs root
Hello Chris On 30.05.2011 21:03, Chris Mason wrote: How big is the FS? About 100 G on a 500 G partition. I would only like to recover some plain text files from it (source code), I don't need the partition to be mountable again. What command did you use to overwrite the super block? Please try to tell us exactly which commands were run. I had to install FreeBSD on that disk (with Linux, a btrfs partition, and several free partitions on it). When using the FreeBSD partition tool, I didn't create or delete any partitions. I only assigned a free partition to FreeBSD. When I booted later in Linux the Btrfs partition did not mount anymore. There are other ways we can try to pull things off, but you should try btrfsck -s 2 as well. btrfcsk -s 2 exits with: using SB copy 2, bytenr 274877906944 No valid Btrfs found on /dev/sda10 -- 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: strange btrfs sub list output
2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path data while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional data volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. -- Stephane -- 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 v1 0/3] btrfs: cleanup: pass fs_info instead of root where possible
This series aims to clean up passing of struct btrfs_root and struct
btrfs_fs_info. It first removes the root pointer from functions and macros
where it's not needed, afterwards it passes fs_info instead of root to
functions which only need root-fs_info.
It is based on 3.0-rc1.
These patches are based on the following two Coccinelle-scripts, but also
involve some hand editing.
a) Remove root parameter where it's completely unneeded. Fix up callers.
@r@
identifier fn != btrfs_inc_extent_ref;
identifier root;
parameter list[n] P;
@@
fn(P
-, struct btrfs_root *root
,...)
{
... when != root
}
@@
identifier r.fn;
expression list[r.n] E;
identifier x;
@@
fn(E
-,x
,...)
b) Change root parameter to fs_info where only root-fs_info is needed. Fix up
callers.
@ s exists @
identifier fn;
identifier root, sf;
identifier member != fs_info;
position p;
expression E;
parameter list[n] P;
@@
fn@p(P,struct btrfs_root *root,...)
{
...
(
root-member
|
sf(...,root,...)
|
(root ...)
|
(root == ...)
|
E = root
)
... when any
}
@ t @
identifier fn != {process_one_buffer,btrfs_inc_extent_ref,btrfs_free_extent};
identifier root;
parameter list[n] P;
position p != s.p;
@@
fn@p(P,
-struct btrfs_root *root
+struct btrfs_fs_info *fs_info
,...)
{
...
- root-fs_info
+ fs_info
...
}
@@
identifier t.fn;
expression list[t.n] E;
expression x;
@@
fn(E,
-x
+x-fs_info
,...)
@@
function fn;
identifier fs_info;
identifier x;
parameter list[n] P;
@@
fn(P, struct btrfs_fs_info *fs_info, ... ) {
...
- struct btrfs_fs_info *x = fs_info;
...
- x
+ fs_info
...
}
Thanks to Julia Lawall for helping to build the scripts.
Arne Jansen (3):
btrfs: remove struct btrfs_root parameter where unused
btrfs: pass fs_info to btrfs_test_opt instead of root
btrfs: cleanup: pass fs_info instead of root where possible
fs/btrfs/compression.c | 11 +-
fs/btrfs/ctree.c| 76 +
fs/btrfs/ctree.h| 66
fs/btrfs/delayed-inode.c| 43 +++---
fs/btrfs/disk-io.c | 281 +++---
fs/btrfs/disk-io.h | 24 ++--
fs/btrfs/extent-tree.c | 409 ++-
fs/btrfs/file-item.c|5 +-
fs/btrfs/file.c | 16 +-
fs/btrfs/free-space-cache.c | 12 +-
fs/btrfs/free-space-cache.h |2 +-
fs/btrfs/inode.c| 108 ++--
fs/btrfs/ioctl.c| 57 +++---
fs/btrfs/ordered-data.c | 48 +++---
fs/btrfs/ordered-data.h |6 +-
fs/btrfs/print-tree.c |2 +-
fs/btrfs/relocation.c | 40 +++--
fs/btrfs/scrub.c| 68 +++-
fs/btrfs/super.c| 34 ++--
fs/btrfs/transaction.c | 183 ++--
fs/btrfs/transaction.h | 12 +-
fs/btrfs/tree-defrag.c |2 +-
fs/btrfs/tree-log.c | 40 +++--
fs/btrfs/volumes.c | 246 +-
fs/btrfs/volumes.h | 10 +-
25 files changed, 912 insertions(+), 889 deletions(-)
--
1.7.3.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 v1 1/3] btrfs: remove struct btrfs_root parameter where unused
The following functions had a struct btrfs_root * parameter which went
unused:
btrfs_set_block_group_rw
btrfs_destroy_delayed_refs
btrfs_csum_data
extent_data_ref_count
copy_to_sk
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/compression.c |3 +--
fs/btrfs/ctree.c| 20 ++--
fs/btrfs/ctree.h|5 +
fs/btrfs/disk-io.c | 14 ++
fs/btrfs/disk-io.h |2 +-
fs/btrfs/extent-tree.c | 16 ++--
fs/btrfs/file-item.c|3 +--
fs/btrfs/free-space-cache.c |6 +++---
fs/btrfs/inode.c|7 +++
fs/btrfs/ioctl.c|5 ++---
fs/btrfs/relocation.c |2 +-
fs/btrfs/scrub.c|7 +++
12 files changed, 38 insertions(+), 52 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index bfe42b0..2182cc5 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -105,7 +105,6 @@ static int check_compressed_csum(struct inode *inode,
u64 disk_start)
{
int ret;
- struct btrfs_root *root = BTRFS_I(inode)-root;
struct page *page;
unsigned long i;
char *kaddr;
@@ -120,7 +119,7 @@ static int check_compressed_csum(struct inode *inode,
csum = ~(u32)0;
kaddr = kmap_atomic(page, KM_USER0);
- csum = btrfs_csum_data(root, kaddr, csum, PAGE_CACHE_SIZE);
+ csum = btrfs_csum_data(kaddr, csum, PAGE_CACHE_SIZE);
btrfs_csum_final(csum, (char *)csum);
kunmap_atomic(kaddr, KM_USER0);
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index b0e18d9..670bed7 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -339,7 +339,7 @@ static noinline int update_ref_for_cow(struct
btrfs_trans_handle *trans,
BUG_ON(ret);
}
if (new_flags != 0) {
- ret = btrfs_set_disk_extent_flags(trans, root,
+ ret = btrfs_set_disk_extent_flags(trans,
buf-start,
buf-len,
new_flags, 0);
@@ -1763,7 +1763,7 @@ done:
* fixing up the blocks in ram so the tree is consistent.
*/
static int fixup_low_keys(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+ struct btrfs_path *path,
struct btrfs_disk_key *key, int level)
{
int i;
@@ -1814,7 +1814,7 @@ int 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(trans, path, disk_key, 1);
return 0;
}
@@ -2579,7 +2579,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);
- wret = fixup_low_keys(trans, root, path, disk_key, 1);
+ wret = fixup_low_keys(trans, path, disk_key, 1);
if (wret)
ret = wret;
@@ -2966,7 +2966,7 @@ again:
path-nodes[0] = right;
path-slots[0] = 0;
if (path-slots[1] == 0) {
- wret = fixup_low_keys(trans, root,
+ wret = fixup_low_keys(trans,
path, disk_key, 1);
if (wret)
ret = wret;
@@ -3301,7 +3301,7 @@ int 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(trans, path, disk_key, 1);
}
item = btrfs_item_nr(leaf, slot);
@@ -3532,7 +3532,7 @@ int btrfs_insert_some_items(struct btrfs_trans_handle
*trans,
ret = 0;
if (slot == 0) {
btrfs_cpu_key_to_disk(disk_key, cpu_key);
- ret = fixup_low_keys(trans, root, path, disk_key, 1);
+ ret = fixup_low_keys(trans, path, disk_key, 1);
}
if (btrfs_leaf_free_space(root, leaf) 0) {
@@ -3638,7 +3638,7 @@ int setup_items_for_insert(struct btrfs_trans_handle
*trans,
ret = 0;
if (slot == 0) {
btrfs_cpu_key_to_disk(disk_key, cpu_key);
- ret = fixup_low_keys(trans, root, path, disk_key, 1);
+ ret = fixup_low_keys(trans, path, disk_key, 1);
}
[PATCH v1 2/3] btrfs: pass fs_info to btrfs_test_opt instead of root
btrfs_test_opt only needs fs_info from the root passed. So just pass
the fs_info directly.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/ctree.h|2 +-
fs/btrfs/disk-io.c |8 +++---
fs/btrfs/extent-tree.c | 55 ++-
fs/btrfs/file.c |2 +-
fs/btrfs/free-space-cache.c |2 +-
fs/btrfs/inode.c| 10
fs/btrfs/ioctl.c|2 +-
fs/btrfs/super.c| 30 +++---
fs/btrfs/transaction.c |5 ++-
fs/btrfs/tree-defrag.c |2 +-
fs/btrfs/tree-log.c |2 +-
fs/btrfs/volumes.c |9 ---
12 files changed, 66 insertions(+), 63 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index b51a06c..b2fdcca 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1343,7 +1343,7 @@ struct btrfs_ioctl_defrag_range_args {
#define btrfs_clear_opt(o, opt)((o) = ~BTRFS_MOUNT_##opt)
#define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt)
-#define btrfs_test_opt(root, opt) ((root)-fs_info-mount_opt \
+#define btrfs_test_opt(fs_info, opt) ((fs_info)-mount_opt \
BTRFS_MOUNT_##opt)
/*
* Inode flags
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index c67a1e6..4d28eaf 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1990,8 +1990,8 @@ struct btrfs_root *open_ctree(struct super_block *sb,
if (IS_ERR(fs_info-transaction_kthread))
goto fail_cleaner;
- if (!btrfs_test_opt(tree_root, SSD)
- !btrfs_test_opt(tree_root, NOSSD)
+ if (!btrfs_test_opt(fs_info, SSD)
+ !btrfs_test_opt(fs_info, NOSSD)
!fs_info-fs_devices-rotating) {
printk(KERN_INFO Btrfs detected SSD devices, enabling SSD
mode\n);
@@ -2304,7 +2304,7 @@ int write_all_supers(struct btrfs_root *root, int
max_mirrors)
u64 flags;
max_errors = btrfs_super_num_devices(root-fs_info-super_copy) - 1;
- do_barriers = !btrfs_test_opt(root, NOBARRIER);
+ do_barriers = !btrfs_test_opt(root-fs_info, NOBARRIER);
sb = root-fs_info-super_for_commit;
dev_item = sb-dev_item;
@@ -3002,7 +3002,7 @@ static int btrfs_destroy_pinned_extent(struct btrfs_root
*root,
break;
/* opt_discard */
- if (btrfs_test_opt(root, DISCARD))
+ if (btrfs_test_opt(root-fs_info, DISCARD))
ret = btrfs_error_discard_extent(root, start,
end + 1 - start,
NULL);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 2236c77..27cc348 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4298,7 +4298,7 @@ int btrfs_finish_extent_commit(struct btrfs_trans_handle
*trans,
if (ret)
break;
- if (btrfs_test_opt(root, DISCARD))
+ if (btrfs_test_opt(fs_info, DISCARD))
ret = btrfs_discard_extent(root, start,
end + 1 - start, NULL);
@@ -4811,7 +4811,8 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
int data)
{
int ret = 0;
- struct btrfs_root *root = orig_root-fs_info-extent_root;
+ struct btrfs_fs_info *fs_info = orig_root-fs_info;
+ struct btrfs_root *root = fs_info-extent_root;
struct btrfs_free_cluster *last_ptr = NULL;
struct btrfs_block_group_cache *block_group = NULL;
int empty_cluster = 2 * 1024 * 1024;
@@ -4833,7 +4834,7 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
ins-objectid = 0;
ins-offset = 0;
- space_info = __find_space_info(root-fs_info, data);
+ space_info = __find_space_info(fs_info, data);
if (!space_info) {
printk(KERN_ERR No space info for %d\n, data);
return -ENOSPC;
@@ -4850,14 +4851,14 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
allowed_chunk_alloc = 1;
if (data BTRFS_BLOCK_GROUP_METADATA use_cluster) {
- last_ptr = root-fs_info-meta_alloc_cluster;
- if (!btrfs_test_opt(root, SSD))
+ last_ptr = fs_info-meta_alloc_cluster;
+ if (!btrfs_test_opt(fs_info, SSD))
empty_cluster = 64 * 1024;
}
if ((data BTRFS_BLOCK_GROUP_DATA) use_cluster
- btrfs_test_opt(root, SSD)) {
- last_ptr = root-fs_info-data_alloc_cluster;
+ btrfs_test_opt(fs_info, SSD)) {
+ last_ptr = fs_info-data_alloc_cluster;
}
if (last_ptr) {
@@ -4875,8 +4876,7 @@ static noinline int
Re: [PATCH v1 0/3] btrfs: cleanup: pass fs_info instead of root where possible
3/3 doesn't seem to arrive anymore, possibly due to a mail size
restriction on vger (yes, it is big). So I pushed it out to:
git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
root-eliminate
Thanks,
Arne
On 31.05.2011 12:16, Arne Jansen wrote:
This series aims to clean up passing of struct btrfs_root and struct
btrfs_fs_info. It first removes the root pointer from functions and macros
where it's not needed, afterwards it passes fs_info instead of root to
functions which only need root-fs_info.
It is based on 3.0-rc1.
These patches are based on the following two Coccinelle-scripts, but also
involve some hand editing.
a) Remove root parameter where it's completely unneeded. Fix up callers.
@r@
identifier fn != btrfs_inc_extent_ref;
identifier root;
parameter list[n] P;
@@
fn(P
-, struct btrfs_root *root
,...)
{
... when != root
}
@@
identifier r.fn;
expression list[r.n] E;
identifier x;
@@
fn(E
-,x
,...)
b) Change root parameter to fs_info where only root-fs_info is needed. Fix up
callers.
@ s exists @
identifier fn;
identifier root, sf;
identifier member != fs_info;
position p;
expression E;
parameter list[n] P;
@@
fn@p(P,struct btrfs_root *root,...)
{
...
(
root-member
|
sf(...,root,...)
|
(root ...)
|
(root == ...)
|
E = root
)
... when any
}
@ t @
identifier fn != {process_one_buffer,btrfs_inc_extent_ref,btrfs_free_extent};
identifier root;
parameter list[n] P;
position p != s.p;
@@
fn@p(P,
-struct btrfs_root *root
+struct btrfs_fs_info *fs_info
,...)
{
...
- root-fs_info
+ fs_info
...
}
@@
identifier t.fn;
expression list[t.n] E;
expression x;
@@
fn(E,
-x
+x-fs_info
,...)
@@
function fn;
identifier fs_info;
identifier x;
parameter list[n] P;
@@
fn(P, struct btrfs_fs_info *fs_info, ... ) {
...
- struct btrfs_fs_info *x = fs_info;
...
- x
+ fs_info
...
}
Thanks to Julia Lawall for helping to build the scripts.
Arne Jansen (3):
btrfs: remove struct btrfs_root parameter where unused
btrfs: pass fs_info to btrfs_test_opt instead of root
btrfs: cleanup: pass fs_info instead of root where possible
fs/btrfs/compression.c | 11 +-
fs/btrfs/ctree.c| 76 +
fs/btrfs/ctree.h| 66
fs/btrfs/delayed-inode.c| 43 +++---
fs/btrfs/disk-io.c | 281 +++---
fs/btrfs/disk-io.h | 24 ++--
fs/btrfs/extent-tree.c | 409
++-
fs/btrfs/file-item.c|5 +-
fs/btrfs/file.c | 16 +-
fs/btrfs/free-space-cache.c | 12 +-
fs/btrfs/free-space-cache.h |2 +-
fs/btrfs/inode.c| 108 ++--
fs/btrfs/ioctl.c| 57 +++---
fs/btrfs/ordered-data.c | 48 +++---
fs/btrfs/ordered-data.h |6 +-
fs/btrfs/print-tree.c |2 +-
fs/btrfs/relocation.c | 40 +++--
fs/btrfs/scrub.c| 68 +++-
fs/btrfs/super.c| 34 ++--
fs/btrfs/transaction.c | 183 ++--
fs/btrfs/transaction.h | 12 +-
fs/btrfs/tree-defrag.c |2 +-
fs/btrfs/tree-log.c | 40 +++--
fs/btrfs/volumes.c | 246 +-
fs/btrfs/volumes.h | 10 +-
25 files changed, 912 insertions(+), 889 deletions(-)
--
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/inode.c:149!
On 05/30/2011 07:12 AM, Elric Milon wrote: On Monday 23 May 2011 21:51:57 Josef Bacik wrote: On 05/23/2011 07:57 AM, Elric Milon wrote: On Monday 16 May 2011 18:28:49 you wrote: On 05/16/2011 11:01 AM, Whirm wrote: On Monday 16 May 2011 16:11:19 Josef Bacik wrote: Sorry yes, I meant this is how I managed to get the corrupted filesystem. Ill try to break it again. Oh ok perfect, yeah I will try and do the same sort of things and see if I can get it to happen as well. Thanks, Great, btw, I tried to see if I can mount the corrupted filesystem with the patch you told me about applied, and it fails, here's the log: http://pastebin.com/raw.php?i=4Kfv927B That happens using 2.6.39-rc7+ from git with the following patch applied (its the debug patch and the possible fix you told me about): Ok so this is a different kind of corruption, wooo! Can you apply this debug patch and get me the output so we can try and fix this bit? Thanks, Josef Sorry for the delay, here's the log: http://pastebin.com/raw.php?i=zNqJVpA1 Ok so you have a corrupt extent entry in your tree. I will come up with something so we deal with this case better than panicing. Thanks for running these debug patches, 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
[3.0-rc1] insert_dir_item hitting assertion during log replay
On 10 April 2011 16:29, Daniel J Blueman daniel.blue...@gmail.com wrote: When rebooting from a crash, thus during log replay on 2.6.29-rc2, btrfs_insert_dir_item caused an assertion failure [1]. The fs was being mounted clear_cache on an SSD. On 3.0-rc1 with a fresh filesystem, after a few crashes with other bugs, I tripped the assert at inode.c:4582 during log replay at mount time, ie btrfs_insert_dir_item() is returning non-zero. I have a metadata image captured from when this occurred in 2.6.29-rc2 and have instrumented the upstream functions to locate where we're failing if it happens in my debug session soon. Anything else we can do? Thanks, Daniel --- [1] 2.6.29-rc2 trace kernel BUG at fs/btrfs/inode.c:4665! invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/virtual/wmi/A80593CE-A997-11DA-B012-B622A1EF5492/uevent CPU 3 Modules linked in: video sdhci_pci sdhci mmc_core Pid: 328, comm: mount Not tainted 2.6.39-rc2-350cd+ #1 Dell Inc. Latitude E5420/0H5TG2 RIP: 0010:[812a2962] [812a2962] btrfs_add_link+0x132/0x190 RSP: 0018:88021e1097d8 EFLAGS: 00010282 RAX: ffef RBX: 88021d965f70 RCX: 0006 RDX: ffef RSI: 88021efe4710 RDI: 88021efe4020 RBP: 88021e109848 R08: R09: 88022d7c03f0 R10: 0001 R11: 0001 R12: 88021d966720 R13: 88021e0261b0 R14: 000f R15: 88021d959000 FS: 7fcee7b3d800() GS:88022ec6() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7f5e5700 CR3: 00021e6ef000 CR4: 000406e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process mount (pid: 328, threadinfo 88021e108000, task 88021efe4020) Stack: 88020001 0016 88021e109978 0016 0010555e 0001 1000 88021e03a000 00b0 88021e109ae8 Call Trace: [812ccb45] add_inode_ref+0x2f5/0x3b0 [81058e61] ? get_parent_ip+0x11/0x50 [812cdff6] replay_one_buffer+0x2c6/0x3a0 [81099fd0] ? mark_held_locks+0x70/0xa0 [81058e61] ? get_parent_ip+0x11/0x50 [812ca978] walk_up_log_tree+0x168/0x320 [812cdd30] ? replay_one_dir_item+0xe0/0xe0 [812cb188] walk_log_tree+0xe8/0x290 [8109a18d] ? trace_hardirqs_on+0xd/0x10 [812d] btrfs_recover_log_trees+0x220/0x320 [812cdd30] ? replay_one_dir_item+0xe0/0xe0 [81295521] open_ctree+0x1301/0x16b0 [81331ab4] ? snprintf+0x34/0x40 [812701e3] btrfs_fill_super.clone.14+0x73/0x130 [811a4aaf] ? disk_name+0x5f/0xc0 [8132ef77] ? strlcpy+0x47/0x60 [812705e0] btrfs_mount+0x340/0x3e0 [81143e9b] mount_fs+0x1b/0xd0 [8115fece] vfs_kern_mount+0x5e/0xd0 [8116045f] do_kern_mount+0x4f/0x100 [81161ea4] do_mount+0x1e4/0x220 [8116228b] sys_mount+0x8b/0xe0 [8170adfb] system_call_fastpath+0x16/0x1b Code: 4c 89 d2 44 89 f1 4c 89 ee 4c 89 1c 24 4c 89 55 a8 4c 89 5d a0 e8 5f c6 fe ff 4c 8b 5d a0 4c 8b 55 a8 85 c0 75 bc e9 31 ff ff ff 0f 0b 48 8b b2 d0 fc ff ff 48 8d 7d b0 b9 11 00 00 00 4d 89 d9 RIP [812a2962] btrfs_add_link+0x132/0x190 RSP 88021e1097d8 -- Daniel J Blueman -- 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: add helper for fs_info-closing
wrap checking of filesystem 'closing' flag and fix a few missing memory
barriers.
Signed-off-by: David Sterba dste...@suse.cz
---
based on 'for-linus' branch of mason/btrfs-unstable.git
fs/btrfs/ctree.h|9 +
fs/btrfs/extent-tree.c |3 +--
fs/btrfs/file.c |4 ++--
fs/btrfs/free-space-cache.c | 10 --
fs/btrfs/inode-map.c|3 +--
fs/btrfs/inode.c|3 +--
fs/btrfs/scrub.c|2 +-
fs/btrfs/transaction.c |2 +-
8 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 332323e..07482a47 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2350,6 +2350,15 @@ int btrfs_drop_subtree(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
struct extent_buffer *node,
struct extent_buffer *parent);
+static inline int btrfs_fs_closing(struct btrfs_fs_info *fs_info)
+{
+ /*
+* Get synced with close_ctree()
+*/
+ smp_mb();
+ return fs_info-closing;
+}
+
/* root-item.c */
int btrfs_find_root_ref(struct btrfs_root *tree_root,
struct btrfs_path *path,
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 169bd62..ce466da 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -366,8 +366,7 @@ again:
nritems = btrfs_header_nritems(leaf);
while (1) {
- smp_mb();
- if (fs_info-closing 1) {
+ if (btrfs_fs_closing(fs_info) 1) {
last = (u64)-1;
break;
}
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index c6a22d7..3ba6d19 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -129,7 +129,7 @@ int btrfs_add_inode_defrag(struct btrfs_trans_handle *trans,
if (!btrfs_test_opt(root, AUTO_DEFRAG))
return 0;
- if (root-fs_info-closing)
+ if (btrfs_fs_closing(root-fs_info))
return 0;
if (BTRFS_I(inode)-in_defrag)
@@ -229,7 +229,7 @@ int btrfs_run_defrag_inodes(struct btrfs_fs_info *fs_info)
first_ino = defrag-ino + 1;
rb_erase(defrag-rb_node, fs_info-defrag_inodes);
- if (fs_info-closing)
+ if (btrfs_fs_closing(fs_info))
goto next_free;
spin_unlock(fs_info-defrag_inodes_lock);
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 70d4579..e65a8b0 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -98,7 +98,7 @@ struct inode *lookup_free_space_inode(struct btrfs_root *root,
return inode;
spin_lock(block_group-lock);
- if (!root-fs_info-closing) {
+ if (!btrfs_fs_closing(root-fs_info)) {
block_group-inode = igrab(inode);
block_group-iref = 1;
}
@@ -478,8 +478,7 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
* 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.
*/
- smp_mb();
- if (fs_info-closing)
+ if (btrfs_fs_closing(fs_info))
return 0;
/*
@@ -2481,7 +2480,7 @@ struct inode *lookup_free_ino_inode(struct btrfs_root
*root,
return inode;
spin_lock(root-cache_lock);
- if (!root-fs_info-closing)
+ if (!btrfs_fs_closing(root-fs_info))
root-cache_inode = igrab(inode);
spin_unlock(root-cache_lock);
@@ -2508,8 +2507,7 @@ int load_free_ino_cache(struct btrfs_fs_info *fs_info,
struct btrfs_root *root)
* 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.
*/
- smp_mb();
- if (fs_info-closing)
+ if (btrfs_fs_closing(fs_info))
return 0;
path = btrfs_alloc_path();
diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c
index 3262cd1..41359bd 100644
--- a/fs/btrfs/inode-map.c
+++ b/fs/btrfs/inode-map.c
@@ -59,8 +59,7 @@ again:
goto out;
while (1) {
- smp_mb();
- if (fs_info-closing)
+ if (btrfs_fs_closing(fs_info))
goto out;
leaf = path-nodes[0];
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index bb51bb1..66c1446 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4268,8 +4268,7 @@ int btrfs_write_inode(struct inode *inode, struct
writeback_control *wbc)
if (BTRFS_I(inode)-dummy_inode)
return 0;
- smp_mb();
- if (root-fs_info-closing is_free_space_inode(root, inode))
+ if (btrfs_fs_closing(root-fs_info) is_free_space_inode(root, inode))
nolock = true;
if
[PATCH] btrfs: use btrfs_ino to access inode number
commit 4cb5300bc (Btrfs: add mount -o auto_defrag) accesses inode number directly while it should use the helper with the new inode number allocator. Signed-off-by: David Sterba dste...@suse.cz --- fs/btrfs/file.c |2 +- fs/btrfs/ioctl.c |7 --- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 3ba6d19..dd4cb3e 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -144,7 +144,7 @@ int btrfs_add_inode_defrag(struct btrfs_trans_handle *trans, if (!defrag) return -ENOMEM; - defrag-ino = inode-i_ino; + defrag-ino = btrfs_ino(inode); defrag-transid = transid; defrag-root = root-root_key.objectid; diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 85e818c..1a7deca 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -707,16 +707,17 @@ static int find_new_extents(struct btrfs_root *root, struct btrfs_file_extent_item *extent; int type; int ret; + u64 ino = btrfs_ino(inode); path = btrfs_alloc_path(); if (!path) return -ENOMEM; - min_key.objectid = inode-i_ino; + min_key.objectid = ino; min_key.type = BTRFS_EXTENT_DATA_KEY; min_key.offset = *off; - max_key.objectid = inode-i_ino; + max_key.objectid = ino; max_key.type = (u8)-1; max_key.offset = (u64)-1; @@ -727,7 +728,7 @@ static int find_new_extents(struct btrfs_root *root, path, 0, newer_than); if (ret != 0) goto none; - if (min_key.objectid != inode-i_ino) + if (min_key.objectid != ino) goto none; if (min_key.type != BTRFS_EXTENT_DATA_KEY) goto none; -- 1.7.5.2.353.g5df3e -- 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: strange btrfs sub list output
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas stephane_chaze...@yahoo.fr wrote: 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path data while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional data volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ... i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of `5`. ... so, is there any known way to _purposefully_ create parented subvols with the current tools? -- C Anthony -- 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: use btrfs_ino to access inode number
both patches are pushed to git://repo.or.cz/linux-2.6/btrfs-unstable.git #fixes david On Tue, May 31, 2011 at 07:08:14PM +0200, David Sterba wrote: commit 4cb5300bc (Btrfs: add mount -o auto_defrag) accesses inode number directly while it should use the helper with the new inode number allocator. Signed-off-by: David Sterba dste...@suse.cz -- 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: linux-next: build warninga in Linus' tree
Hi, On Mon, May 30, 2011 at 11:36:53AM +1000, Stephen Rothwell wrote: After merging the Linus' tree, today's linux-next build (powerpc ppc64_defconfig) produced these warnings: fs/btrfs/sysfs.c:76:26: warning: 'btrfs_root_attrs' defined but not used fs/btrfs/sysfs.c:97:26: warning: 'btrfs_super_attrs' defined but not used fs/btrfs/sysfs.c:153:13: warning: 'btrfs_super_release' defined but not used fs/btrfs/sysfs.c:160:13: warning: 'btrfs_root_release' defined but not used I have started using gcc v4.5.2 (instead of v4.4.4) if that makes a difference. the warning probably started to show up after one of my cleanup patches, removing unused functions (f2a97a9dbd86eb1ef956bdf20e05c507b32beb96). The sysfs interface is not being used right now, but there's a unmerged patchset which adds the interesting bits like info about available btrfs filesystems and devices. I don't know what are the intentions regarding sysfs. 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: Problem with latest for-linus branch
2011/5/30 Chris Mason chris.ma...@oracle.com: Ok, so I think we're blowing past the end of the page we've kmap'd. But I don't think that can happen without something like the patch below triggering: Quick update: after rm of ~10 GB of data, I rebooted with Linus' latest git tree, and it works (after some minutes of btrfs-ino-cache). Ciao, Andrea -- 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: strange btrfs sub list output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.05.2011 19:40, C Anthony Risinger wrote: On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas stephane_chaze...@yahoo.fr wrote: 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path data while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional data volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ... i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of `5`. ... so, is there any known way to _purposefully_ create parented subvols with the current tools? Hopefully, I can help clarify this a little bit. In fact, this is the 'usual' case. With the attached patch to the master branch of btrfs-progs-unstable you can 'watch' how the btrfs subvolume list command builds the full path of the listed subvolumes. Additionally, it gives you the IDs of the parent subvolumes. See the following example. ID 256 top level 5 path test1 ID 257 top level 256 path test1.1 ID 257 top level 5 path test1/test1.1 ID 258 top level 5 path test2 ID 259 top level 258 path test2.1 ID 259 top level 5 path test2/test2.1 - From the second line you see that subvolume ID 256 really is ID 257's parent. Additionally, only test1 and test2 have parent ID 5 or in your terminology are in the btrfs root. diff --git a/btrfs-list.c b/btrfs-list.c index 93766a8..e75d6cf 100644 - --- a/btrfs-list.c +++ b/btrfs-list.c @@ -248,6 +248,9 @@ static int resolve_root(struct root_lookup *rl, struct root_info *ri) top_id = next; break; } + + printf(ID %llu top level %llu path %s\n, ri-root_id, next, + full_path); } printf(ID %llu top level %llu path %s\n, ri-root_id, top_id, full_path); -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5Th6AAoJEJIcBJ3+XkgiWNQP/jsWQymukrgESfqndQvrJwl6 QZOe5y9IMmV8jBDPot4EAVAQhLrG2twA1ALVvj+DfD0Ks9VATpmnP4QB39XIWlNz /cRxoUev/Z8a0zNnXXneUsbJ1rYx5vX6R0yzRWiZ6Yd0EZ9GCRp+HvPRs5NNGGIc 0NZCQk1BOe+MAovSQpUbRtyfd4JcxdPEYkt29VySu2wrD02MdXVyzohegCzmUZWv ou8COpWvquPmNvYHfudVir6r4BSEfqpIEkkGY61yts00rnnPXuOh1uZQKGyDuK/S 2o6EOAN3SIONEWts7nx95/IjfAbVa/XUmj+bhr2xJspH4Q93tr8rDns0XCCN/GYY xTfMMUFajZHOhv5qjbUF9BFLAU62eKdw4zCPAmed4f/klBcXZ/Ri1pIBwaJv3CTp J3camkJBwmTiSwTIIl1qTOMypv0xT602uiiegnBe/UAzz59+cSLDyWFXBc2QQoTV jhJiLd281kjPqEqALMNJOOZ0pQ6hDxOoBqg7cA5VEY9619coQE93H6UXgtd0E4YX U32bO7WypGbgd3HuNDWd44p4gVYR/Mzu8symvjJDKg5iChLkBEmYyN8hAGryYhtO mZBWntTxYPm+Twkf+ovAtVpLGV5Gr1kfGln5lsmsIn1bPW8ZnVbWIDhulD1lQSVw Th5rDp6lY0ZBe4+mbOXy =M8dp -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
Re: [PATCH 0/9] some fixes for bugs spotted by valgrind
Some clarifications:
Patchset based on 'tmp' branch e6bd18d8938986c997c45f0ea95b221d4edec095.
All patches are against btrfs-progs.
The rest of rambling is about kernel code, which handles supers.
I have read what I've wrote last night (braindump of insane!)
and will try to elaborate a bit:
Poking at valgrind warnings I have noticed very worrying problem.
When we (over)write superblock we take 4096 continuous bytes in memory.
The common pattern in disk-io.c is the following:
struct btrfs_super_block *sb = root-fs_info-sb // or -sb_for_commit
memcpy(dest, sb, BTRFS_SUPER_INFO_SIZE /* 4096 */);
With a memcpy we go out of sizeof(*sb) (~2.5K) and pick more fields from
fs_info struct.
Let's look at them:
struct btrfs_fs_info {
...
struct btrfs_super_block super_copy;
struct btrfs_super_block super_for_commit;
struct block_device *__bdev;
struct super_block *sb;
struct inode *btree_inode;
struct backing_dev_info bdi;
struct mutex trans_mutex;
struct mutex tree_log_mutex;
struct mutex transaction_kthread_mutex;
struct mutex cleaner_mutex;
struct mutex chunk_mutex;
struct mutex volume_mutex;
struct mutex ordered_operations_mutex;
struct rw_semaphore extent_commit_sem;
struct rw_semaphore cleanup_work_sem;
struct rw_semaphore subvol_sem;
struct srcu_struct subvol_srcu;
struct list_head trans_list;
struct list_head hashers;
struct list_head dead_roots;
struct list_head caching_block_groups;
spinlock_t delayed_iput_lock;
struct list_head delayed_iputs;
atomic_t nr_async_submits;
...
So we copyout (and even checksum!) atomic counters and other volatile stuff
(I haven't looked at mutexes and semaphores, but i'm sure there is yet some
volatile stuff)
In kernel the structures reside in btrfs_fs_info structure, so we compute
CRC for:
struct btrfs_super_block super_copy;
struct btrfs_super_block super_for_commit;
and then write it to disk. [H]ere we have 2 issues:
1. kernel pointers and other random stuff leaks out to kernel.
It's nondeterministic and leaks out data (not too bad,
as it should be accessible only for root, but still)
2. more serious: is there guarantee, that noone will kick-in
between CRC computation and superblock outwrite?
What if some of mutexes, semaphores or lists will change
it's internal state? Some async thread will kick it
an we will end-up writing superblock with invalid CRC!
This might well be the cause of recend superblock
corruptions under heavy load + hangup retorted to the list.
Consider the following call chain:
[somewhere in write_dev_supers ...]
bh-b_end_io = btrfs_end_buffer_write_sync;
crc = ~(u32)0;
crc = btrfs_csum_data(NULL, (char *)sb +
BTRFS_CSUM_SIZE, crc,
BTRFS_SUPER_INFO_SIZE -
BTRFS_CSUM_SIZE);
btrfs_csum_final(crc, sb-csum);
Now the problem should be a bit more clear: sb is a thing pointing to the middle
of fs_info. We checksum it with data after it in fs_info.
bh = __getblk(device-bdev, bytenr / 4096,
BTRFS_SUPER_INFO_SIZE);
memcpy(bh-b_data, sb, BTRFS_SUPER_INFO_SIZE);
and here we write all the checksummed contents. Is there guard, which
prevents things from updating fs_info?
/* one reference for submit_bh */
get_bh(bh);
set_buffer_uptodate(bh);
lock_buffer(bh);
bh-b_end_io = btrfs_end_buffer_write_sync;
Am I too paranoid about the issue?
Thanks!
--
Sergei
signature.asc
Description: PGP signature
[PATCH] Btrfs: don't save the inode cache if we are deleting this root
With xfstest 254 I can panic the box every time with the inode number caching stuff on. This is because we clean the inodes out when we delete the subvolume, but then we write out the inode cache which adds an inode to the subvolume inode tree, and then when it gets evicted again the root gets added back on the dead roots list and is deleted again, so we have a double free. To stop this from happening just return 0 if refs is 0 (and we're not the tree root since tree root always has refs of 0). With this fix 254 no longer panics. Thanks, Signed-off-by: Josef Bacik jo...@redhat.com --- fs/btrfs/inode-map.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c index 3262cd1..2835375 100644 --- a/fs/btrfs/inode-map.c +++ b/fs/btrfs/inode-map.c @@ -388,6 +388,11 @@ int btrfs_save_ino_cache(struct btrfs_root *root, int prealloc; bool retry = false; + /* Don't save inode cache if we are deleting this root */ + if (btrfs_root_refs(root-root_item) == 0 + root != root-fs_info-tree_root) + return 0; + path = btrfs_alloc_path(); if (!path) return -ENOMEM; -- 1.7.2.3 -- 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 v1 1/3] btrfs: remove struct btrfs_root parameter where unused
Hi,
(2011/05/31 19:16), Arne Jansen wrote:
The following functions had a struct btrfs_root * parameter which went
unused:
btrfs_set_block_group_rw
btrfs_destroy_delayed_refs
btrfs_csum_data
extent_data_ref_count
copy_to_sk
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/compression.c |3 +--
fs/btrfs/ctree.c| 20 ++--
fs/btrfs/ctree.h|5 +
fs/btrfs/disk-io.c | 14 ++
fs/btrfs/disk-io.h |2 +-
fs/btrfs/extent-tree.c | 16 ++--
fs/btrfs/file-item.c|3 +--
fs/btrfs/free-space-cache.c |6 +++---
fs/btrfs/inode.c|7 +++
fs/btrfs/ioctl.c|5 ++---
fs/btrfs/relocation.c |2 +-
fs/btrfs/scrub.c|7 +++
12 files changed, 38 insertions(+), 52 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index bfe42b0..2182cc5 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -105,7 +105,6 @@ static int check_compressed_csum(struct inode *inode,
u64 disk_start)
{
int ret;
- struct btrfs_root *root = BTRFS_I(inode)-root;
struct page *page;
unsigned long i;
char *kaddr;
@@ -120,7 +119,7 @@ static int check_compressed_csum(struct inode *inode,
csum = ~(u32)0;
kaddr = kmap_atomic(page, KM_USER0);
- csum = btrfs_csum_data(root, kaddr, csum, PAGE_CACHE_SIZE);
+ csum = btrfs_csum_data(kaddr, csum, PAGE_CACHE_SIZE);
btrfs_csum_final(csum, (char *)csum);
kunmap_atomic(kaddr, KM_USER0);
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index b0e18d9..670bed7 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -339,7 +339,7 @@ static noinline int update_ref_for_cow(struct
btrfs_trans_handle *trans,
BUG_ON(ret);
}
if (new_flags != 0) {
- ret = btrfs_set_disk_extent_flags(trans, root,
+ ret = btrfs_set_disk_extent_flags(trans,
buf-start,
buf-len,
new_flags, 0);
@@ -1763,7 +1763,7 @@ done:
* fixing up the blocks in ram so the tree is consistent.
*/
static int fixup_low_keys(struct btrfs_trans_handle *trans,
- struct btrfs_root *root, struct btrfs_path *path,
+ struct btrfs_path *path,
struct btrfs_disk_key *key, int level)
'trans' is also unnecessary in fixup_low_keys().
(http://marc.info/?l=linux-btrfsm=130337980625475w=2)
Thanks,
Tsutomu
{
int i;
@@ -1814,7 +1814,7 @@ int 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(trans, path, disk_key, 1);
return 0;
}
@@ -2579,7 +2579,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);
- wret = fixup_low_keys(trans, root, path, disk_key, 1);
+ wret = fixup_low_keys(trans, path, disk_key, 1);
if (wret)
ret = wret;
@@ -2966,7 +2966,7 @@ again:
path-nodes[0] = right;
path-slots[0] = 0;
if (path-slots[1] == 0) {
- wret = fixup_low_keys(trans, root,
+ wret = fixup_low_keys(trans,
path, disk_key, 1);
if (wret)
ret = wret;
@@ -3301,7 +3301,7 @@ int 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(trans, path, disk_key, 1);
}
item = btrfs_item_nr(leaf, slot);
@@ -3532,7 +3532,7 @@ int btrfs_insert_some_items(struct btrfs_trans_handle
*trans,
ret = 0;
if (slot == 0) {
btrfs_cpu_key_to_disk(disk_key, cpu_key);
- ret = fixup_low_keys(trans, root, path, disk_key, 1);
+ ret = fixup_low_keys(trans, path, disk_key, 1);
}
if (btrfs_leaf_free_space(root, leaf) 0) {
@@ -3638,7 +3638,7 @@ int setup_items_for_insert(struct btrfs_trans_handle
*trans,
ret = 0;
if (slot == 0) {
btrfs_cpu_key_to_disk(disk_key, cpu_key);
