Re: btrfs: Error removing orphan entry, stopping orphan cleanup. could not do orphan cleanup -22
On Wed, Feb 6, 2013 at 4:45 AM, Josef Bacik jba...@fusionio.com wrote: Ok so I think we've fixed this already, can you build btrfs-next and try mounting with that and see if it fixes the problem? Thanks, Hi, Josef, Is there any btrfs git compatible with kernel 3.7 and absorbs this fix? So I can dkms it, I'm using openSUSE 12.3 Beta1 with kernel 3.7, I can update to 3.8, but next time I do system update to RC1 it will fallback to 3.7 again. #btrfs-next seems to move forward to 3.8. /uapi/linux/btrfs.h doesn't exist in kernel 3.7, it still use the old ioctl.h, I tried to revert the ioctl.h btrfs.h patch, but there's still errors about: /usr/src/linux-3.7.1-1/include/trace/events/btrfs.h: In function ‘ftrace_raw_event_btrfs_transaction_commit’: /usr/src/linux-3.7.1-1/include/trace/events/btrfs.h:61:1: error: incompatible types when assigning to type ‘u64’ from type ‘atomic64_t’ Thanks Marguerite -- 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: Error removing orphan entry, stopping orphan cleanup. could not do orphan cleanup -22
On Wed, Feb 6, 2013 at 3:35 AM, Josef Bacik jba...@fusionio.com wrote: Eesh can you fpaste this, it got wrapped by your mailer and I can't read it. Thanks, Hi, Josef, Of course, http://paste.opensuse.org/80508108 I at first thought pasting here may help archive. but Gmail sucks...sorry! Marguerite -- 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
unrecognized mount option 'compression=lzo' and defragment -c errors
Hi, I planned to boost my btrfs performance today. here some errors I met: my 'btrfs filesystem show' result: ~ # btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 9b9aa9d9-760e-445c-a0ab-68e102d9f02e Total devices 1 FS bytes used 36.59GB devid1 size 49.52GB used 49.52GB path /dev/sda6 Label: none uuid: 559dec06-4fd0-47c1-97b8-cc4fa6153fa0 Total devices 1 FS bytes used 135.48GB devid1 size 293.56GB used 293.56GB path /dev/sda5 Btrfs v0.19+ my btrfs packages: * kernel moudule: btrfs-git from mason's repo, 20121010 * btrfsprogs: 0.19 and my /etc/fstab: UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e /btrfs defaults,compression=lzo,space_cache,io_cache,comment=systemd.automount 1 0 UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /homebtrfs defaults,space_cache,comment=systemd.automount 1 0 my btrfs partitions are made in 2011.11, before kernel 3.2 is released.( is that related? like the previous space_cache issue?) 1. I also added mount option 'compression=lzo' and 'io_cache' to /home at first. then cannot enter home directory. using ./ in KDE it shows the kdm login(I used autologin, which should boot directly into the desktop) and call to lnusetemp failed.(temporary directories full?) check your installtion when I clicked okay. I checked dmesg log, found it didn't recogonized my compression=lzo option: [7.726768] device fsid 9b9aa9d9-760e-445c-a0ab-68e102d9f02e devid 1 transid 359535 /dev/sda6 [7.727555] btrfs: disk space caching is enabled [9.260024] btrfs: unrecognized mount option 'compression=lzo' and multiple: [ 232.314220] device fsid 559dec06-4fd0-47c1-97b8-cc4fa6153fa0 devid 1 transid 523509 /dev/sda5 [ 232.314744] btrfs: unrecognized mount option 'compression=lzo' [ 232.314816] btrfs: open_ctree failed outputs. so I removed them from /home. now I can boot. but it still complains: btrfs: unrecognized mount option 'io_cache' for /. 2. After I logged in, I switched to root: ~# umount -o remount,compression=lzo /dev/sda5 /home I thought it was mounted with compression enabled, (but actually its not, before I reported here. I checked dmesg, there's an entry 4800.x which should be my second home mount, with unrecognized compression=lzo either) so I wanted to make all my existing files compressed. I googled, and found a post on Ocale.com said: ~# btrfs filesystem -c The defragment command has an option -c that lets you specify zlib or lzo. but it was not true according to: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07563.html Mason said -c only force compression. so how can I specify compression method? what's more, defragment tool always returns: ~ # btrfs filesystem defragment -c /dev/sda5 ERROR: defrag range ioctl not supported in this kernel, please try without any options. total 1 failures ~ # btrfs filesystem defragment -c /home failed to open /home open:: No such device total 1 failures I'm confused. no solution found through google for the first message. and if we can defragment a file like /home/marguerite/100m.zip, why /home failed to open? Thanks for help Marguerite -- 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: unrecognized mount option 'compression=lzo' and defragment -c errors
On Sun, Oct 21, 2012 at 8:44 AM, cwillu cwi...@cwillu.com wrote: Neither io_cache nor compression=lzo are options that exist. You probably meant compress=lzo for the first, but I really don't know what you wanted for io_cache (inode_cache? that's not really a performance thing) You need to check what the actual parameters are before you change things. Making stuff up simply doesn't work. Hi, cwillu, I'm glad you show up immediately. yes, you're true. I was making up options. that's why I got those errors. I checked: /dev/mapper/vgCASRV0104-data /mnt/btrfs btrfs rw,relatime,compress=lzo,space_cache,inode_cache 0 0 http://www.spinics.net/lists/linux-btrfs/msg19804.html these are the right options. thanks Marguerite -- 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: unrecognized mount option 'compression=lzo' and defragment -c errors
Hi, cwillu, I have my filesystems mounted with compress=lzo and inode_cache. now the only problem is, I can't btrfs filesystem defragment -c /dev/sda5 which says: earth:/home/marguerite # btrfs filesystem defragment -clzo /dev/sda5 ERROR: defrag range ioctl not supported in this kernel, please try without any options. total 1 failures Thanks Marguerite -- 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: initramfs take a long time to load[135s]
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason chris.ma...@fusionio.com wrote: If it isn't the free space cache, it'll be a fragmentation problem. The easiest way to tell the difference is to get a few sysrq-w snapshots during the boot. Hi, Chris, with some help from openSUSE community, I learnt what's sysrq snapshots(alt+printscreen+w in tty1)... and here's my log: http://paste.opensuse.org/31094916 can you help look through this? Many thanks! Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 11:41 PM, cwillu cwi...@cwillu.com wrote: You need to hit alt-sysrq-w during the slowness you're trying to instrument; the pastebin is from an hour later. Also, next time just put the output directly in the email, that way it's permanently around to look at and search for. Thanks for teaching me the rules, cwillu! I'll do it right now! Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 11:41 PM, cwillu cwi...@cwillu.com wrote: Also, next time just put the output directly in the email, that way it's permanently around to look at and search for. Hi, I did it. here's my dmesg: [ 25.623660] SysRq : Show Blocked State [ 25.623667] taskPC stack pid father [ 25.623682] btrfs-cache-1 D 81608240 0 223 2 0x [ 25.623687] 880036b09a70 0046 00d7 880036b09fd8 [ 25.623691] 0008 880036b09fd8 880036b09fd8 880036b09fd8 [ 25.623695] 81c13420 880036a56840 8800bec13b20 [ 25.623699] Call Trace: [ 25.623713] [815cb2ea] io_schedule+0x8a/0xd0 [ 25.623720] [81110669] sleep_on_page+0x9/0x10 [ 25.623725] [815c9c9f] __wait_on_bit+0x4f/0x80 [ 25.623730] [8111079f] wait_on_page_bit+0x6f/0x80 [ 25.623757] [a0067455] read_extent_buffer_pages+0x265/0x340 [btrfs] [ 25.623844] [a00418fe] btree_read_extent_buffer_pages.constprop.119+0xae/0x110 [btrfs] [ 25.623889] [a0043453] read_tree_block+0x33/0x50 [btrfs] [ 25.623932] [a0026665] read_block_for_search.isra.48+0x165/0x420 [btrfs] [ 25.623957] [a002c47d] btrfs_next_old_leaf+0x29d/0x4a0 [btrfs] [ 25.623984] [a0030e02] caching_thread+0x1f2/0x3c0 [btrfs] [ 25.624018] [a0071f03] worker_loop+0x153/0x560 [btrfs] [ 25.624087] [810688d5] kthread+0x85/0x90 [ 25.624093] [815d47b4] kernel_thread_helper+0x4/0x10 [ 25.624097] mount D 81608240 0 232 1 0x [ 25.624100] 880036ff37a0 0086 81077798 880036ff3fd8 [ 25.624104] 81080557 880036ff3fd8 880036ff3fd8 880036ff3fd8 [ 25.624107] 81c13420 8800b6f4e600 8107380b 8800b6f4e600 [ 25.624111] Call Trace: [ 25.624116] [815cbfc5] rwsem_down_failed_common+0xc5/0x160 [ 25.624122] [812f38a3] call_rwsem_down_write_failed+0x13/0x20 [ 25.624126] [815ca53c] down_write+0x1c/0x1d [ 25.624138] [a002ec61] cache_block_group.isra.44+0x241/0x380 [btrfs] [ 25.624167] [a0033f4a] find_free_extent+0xaea/0xbb0 [btrfs] [ 25.624200] [a00378f7] btrfs_reserve_extent+0x97/0x1d0 [btrfs] [ 25.624235] [a0037ea2] btrfs_alloc_free_block+0xe2/0x3c0 [btrfs] [ 25.624269] [a0024327] __btrfs_cow_block+0x137/0x570 [btrfs] [ 25.624291] [a002485f] btrfs_cow_block+0xff/0x250 [btrfs] [ 25.624313] [a0028e59] btrfs_search_slot+0x429/0x990 [btrfs] [ 25.624340] [a003fc55] btrfs_lookup_inode+0x25/0xa0 [btrfs] [ 25.624384] [a0092286] btrfs_update_delayed_inode+0x76/0x160 [btrfs] [ 25.624484] [a009341e] __btrfs_run_delayed_items+0x13e/0x1a0 [btrfs] [ 25.624584] [a00496e7] btrfs_commit_transaction+0x3b7/0xb40 [btrfs] [ 25.624625] [8119f9a0] __sync_filesystem+0x30/0x60 [ 25.624631] [81172d2b] __do_remount_sb+0x5b/0x1a0 [ 25.624636] [8118e87a] do_remount+0xfa/0x160 [ 25.624641] [811917aa] do_mount+0x20a/0x260 [ 25.624646] [8119189a] sys_mount+0x9a/0xf0 [ 25.624649] [815d36b9] system_call_fastpath+0x16/0x1b [ 25.624649] [7f91f7141a3a] 0x7f91f7141a39 [ 25.624649] Sched Debug Version: v0.10, 3.6.2-2-desktop #1 [ 25.624649] ktime : 25624.659099 [ 25.624649] sched_clk : 7064.337499 [ 25.624649] cpu_clk : 25624.649041 [ 25.624649] jiffies : 4294692919 [ 25.624649] sched_clock_stable : 0 [ 25.624649] [ 25.624649] sysctl_sched [ 25.624649] .sysctl_sched_latency: 12.00 [ 25.624649] .sysctl_sched_min_granularity: 1.50 [ 25.624649] .sysctl_sched_wakeup_granularity : 2.00 [ 25.624649] .sysctl_sched_child_runs_first : 0 [ 25.624649] .sysctl_sched_features : 24119 [ 25.624649] .sysctl_sched_tunable_scaling: 1 (logaritmic) [ 25.624649] [ 25.624649] cpu#0, 1795.416 MHz [ 25.624649] .nr_running: 0 [ 25.624649] .load : 0 [ 25.624649] .nr_switches : 15640 [ 25.624649] .nr_load_updates : 6257 [ 25.624649] .nr_uninterruptible: -3 [ 25.624649] .next_balance : 4294.692918 [ 25.624649] .curr-pid : 0 [ 25.624649] .clock : 25618.786824 [ 25.624649] .cpu_load[0] : 0 [ 25.624649] .cpu_load[1] : 0 [ 25.624649] .cpu_load[2] : 0 [ 25.624649] .cpu_load[3] : 0 [ 25.624649] .cpu_load[4] : 0
Re: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 12:55 AM, cwillu cwi...@cwillu.com wrote: It appears space_cache isn't enabled on your rootfs; can you do a mount / -o remount,space_cache, sync a couple times, make some coffee, and then reboot, and see if it's better? You should see two instances of btrfs: disk space caching is enabled in your dmesg, one for / and the second for /home. Also, make sure to reply-all so that others interested can still follow along. like this UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e /btrfs defaults,space_cache,comment=systemd.automount 1 0 UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /homebtrfs defaults,space_cache,comment=systemd.automount 1 0 in /etc/fstab? Marguerite -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 12:55 AM, cwillu cwi...@cwillu.com wrote: It appears space_cache isn't enabled on your rootfs; can you do a mount / -o remount,space_cache, sync a couple times, make some coffee, and then reboot, and see if it's better? You should see two instances of btrfs: disk space caching is enabled in your dmesg, one for / and the second for /home. Also, make sure to reply-all so that others interested can still follow along. Marvelous! cwillu, you're the most brilliant man I've ever seen in this world! I can't find a most suitable word to say thank you! You saved my life! I mean, 1 year and a half's struggling now comes to an end! Hu! Can you tell me what my problem actually is? do you or do I need a patch of something added to the code base? I mean, I'm an openSUSE Memeber, our distro didn't have my: default,space_cache,comment=systemd.automount and 0 1 set by default, actually it was: default 0 2 so is there anything I can do to make this happiness come to everyone in my distribution? Hug againnn! Marguerite -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 2:26 AM, cwillu cwi...@cwillu.com wrote: That would work, but it's only necessary to mount with it once (and it's probably been done already with /home), hence the -o remount,space_cache Now my kernel loads in 10s, another 4s for userspace...then -.mount and all the systemd services. It boots like an animal! -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 2:35 AM, cwillu cwi...@cwillu.com wrote: Without space_cache (once), btrfs has to repopulate that information the slow way every mount; with it, it can just load the data from the last unmount (modulo some consistency checks). The setting is sticky, so you don't actually need it in fstab any more (although it won't hurt anything either). Thanks, cwillu! I transfer the message to openSUSE bugzilla and ask them help making that happen by default in openSUSE. Marguerite -- 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
initramfs take a long time to load[135s]
Hi, all, I ran into a situation that no useful information can be found over the internet... I'm using 3.6.2 + btrfs git compiled using dkms, and I have a 300GB btrfs /home and 50GB btrfs /: Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = 扇区 of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0004746f 设备 Boot Start End Blocks Id System /dev/sda12048 4208639 2103296 82 Linux swap / Solaris /dev/sda2 * 4209030 5237189 514080 83 Linux /dev/sda3 5237190 1748723444 871743127+ 5 Extended /dev/sda4 1748723712 1953523711 102407 HPFS/NTFS/exFAT /dev/sda5 109081413 724724279 307821433+ 83 Linux /dev/sda6 5237316 10908134951922017 83 Linux /dev/sda7 808615936 1748721663 470052864 83 Linux At first, it was NetworkManager that took 8ms to load( a btrfs only problem), after some debugging. I added comment=systemd.automount to my btrfs partition. then the only problem left is that kernel+userspace took 135s to initialize then -.mount and all other systemd service can continue: /dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2R8J9BB808817-part1 swap swap defaults 0 0 UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e /btrfs defaults,comment=systemd.automount 1 1 /dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2R8J9BB808817-part2 /boot ext4 acl,user_xattr1 2 UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /homebtrfs defaults,comment=systemd.automount 1 2 /dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2R8J9BB808817-part4 /windows/C ntfs-3g users,gid=users,comment=systemd.automount,fmask=133,dmask=022,locale=zh_TW.UTF-8 0 0 proc /procproc defaults 0 0 sysfs/sys sysfs noauto0 0 debugfs /sys/kernel/debugdebugfsnoauto0 0 usbfs/proc/bus/usbusbfs noauto0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 systemd-analyze blame | head 44638ms systemd-logind.service 40928ms syslog.service 14567ms network.service 13093ms network-remotefs.service 13022ms NetworkManager.service 9809ms systemd-modules-load.service 3835ms systemd-vconsole-setup.service 3450ms localnet.service 2977ms udev-root-symlink.service 2443ms sys-kernel-security.mount plot: http://paste.opensuse.org/84499659 And Frederic said it seemed to be a known bug that need to clear_cache for 3.4+ kernel. I did. but the problem still exist. The original bug report is here: https://bugzilla.novell.com/show_bug.cgi?id=776563 So anyone can help me debugging this? Thanks Marguerite -- 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: initramfs take a long time to load[135s]
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason chris.ma...@fusionio.com wrote: Usually when btrfs is slow to mount, or slow right after a mount it is because we're regenerating the free space cache. This is slow enough that you should be able to see the free space cache threads active even after the initial boot is done. The good news is that you should be able to just let them finish generating the cache and then the problem should go away. HI,Chris, yes...I did regenerate free_space last time Frederic told me to. the next boot after removing clear_cache from fstab is super slow. but after that boot, kernel still needs 135s to load... If it isn't the free space cache, it'll be a fragmentation problem. The easiest way to tell the difference is to get a few sysrq-w snapshots during the boot. How can I get a few sysrq-w snapshots please? My btrfs is automatically created during openSUSE install, so I don't know which command I can use to do so...please forgive my freshness and stupidity... Marguerite -- 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
