[Bug 776563] New: NetworkManager 80000+ms on boot
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c0 Summary: NetworkManager 80000+ms on boot Classification: openSUSE Product: openSUSE 12.2 Version: RC 2 Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: i@marguerite.su QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=502816) --> (http://bugzilla.novell.com/attachment.cgi?id=502816) boot plot by systemd-analyze User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1190.0 Safari/537.1 SUSE/22.0.1190.0 Hi, I saw the post on lizards teaching us how to improve openSUSE boot performance to 2s, but when it was my case: marguerite@linux:~> systemd-analyze blame 88848ms NetworkManager.service 5578ms home.mount 4145ms systemd-modules-load.service 2684ms windows-C.mount 2089ms localnet.service 1903ms systemd-vconsole-setup.service 1492ms remount-rootfs.service 1341ms xdm.service 1300ms sys-kernel-security.mount 1287ms udev.service 1255ms systemd-remount-api-vfs.service 1138ms systemd-logind.service 931ms vboxdrv.service 860ms media.mount 851ms var-lock.mount 849ms dev-hugepages.mount 848ms var-run.mount 841ms dev-mqueue.mount 825ms sys-kernel-debug.mount 708ms syslog.service 231ms systemd-readahead-replay.service 218ms udev-trigger.service 210ms vboxweb-service.service 207ms systemd-readahead-collect.service 206ms systemd-tmpfiles-setup.service 203ms network.service 199ms vboxballoonctrl-service.service 192ms systemd-sysctl.service 181ms boot.mount 138ms upower.service 130ms bluez-coldplug.service 89ms console-kit-log-system-start.service 89ms fbset.service 48ms rtkit-daemon.service 42ms systemd-user-sessions.service 28ms console-kit-daemon.service 21ms acpid.service 15ms rc-local.service 2ms sys-fs-fuse-connections.mount and I had a few tests with help from Binli: * It's not an specific AP related bug. It's even slower without an AP. because then NM took 60000+ ms, but systemd-modules-load.service took another 30000+ ms. * Binli said it may be related to these lines: Aug 19 23:28:39 linux NetworkManager[709]: <warn> Trying to remove a non-existant call id. Aug 19 23:28:51 linux NetworkManager[709]: <info> Auto-activating connection 'NETGEAR'. Since I'm not a low-level hacker, and Binli is busy at the moment, so I attached my logs and plots to see if any other basesystem maintainer can offer some help. Marguerite Reproducible: Always Steps to Reproduce: boot Actual Results: after around 5 minutes I saw the KDE splash Expected Results: It should be below 1 minute NM version: 0.9.4.0-5.2.1 wpa_supplicant version: 1.0-2.1.2 Kernel version: 3.4.6-1.1-desktop systemd version: 44-10.1.1 (also happens to 44-9) by the way, systemd split systemd-analyze to a separate package. so you need to download and install systemd-analyze manually from https://build.opensuse.org/package/binaries?package=systemd&project=openSUSE%3A12.2&repository=standard -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c1 --- Comment #1 from Marguerite Su 2012-08-20 10:33:06 UTC --- Created an attachment (id=502817) --> (http://bugzilla.novell.com/attachment.cgi?id=502817) boot.log messages NetworkManager wpa_supplicant.log and: marguerite@linux:/etc/systemd/system> ls default.target multi-user.target.wants runlevel5.target.wants default.target.wants network.target.wants sockets.target.wants getty.target.wants runlevel2.target.wants klogd.service runlevel3.target.wants No self tweaks. Computer: Lenovo T61 8890-A28 from Singapore. Wireless card: iw3945 (seems to be the best Wireless card NM supports.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c2
kk zhang
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c3
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c4 --- Comment #4 from Marguerite Su 2012-08-21 11:54:23 UTC --- Hi, Frederic, Thanks very much for looking at this. 1/ It's generated by mkinitrd...all kernel-related stuff I had is Virtualbox, but seems it loads after network.target. So actually I don't know what happened. Can you point me a way on how to debug initrd? 2/ Thanks for clarifying it. So now it's a pure "wireless" stuff... KK, who should this be assigned to? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c
kk zhang
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c5
Li Bin
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c6
Li Bin
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c7
Li Bin
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c8 --- Comment #8 from Marguerite Su 2012-08-28 11:40:47 UTC --- That may be because I have a 1T Sumsung Harddisk...anyway I'm also trying to figure out how to mount it faster. here's my initrd. 17m. http://ge.tt/9N3GgiM/v/0 but takes 70s to load on boot. And: marguerite@linux:~> rpm -qf /lib/mkinitrd/scripts/setup-* | sort -u cifs-utils-5.5-2.2.3.x86_64 cryptsetup-1.4.2-3.2.2.x86_64 device-mapper-1.02.63-26.1.2.x86_64 dmraid-1.0.0.rc16-18.2.2.x86_64 kpartx-0.4.9-3.3.1.x86_64 lvm2-2.02.84-26.1.2.x86_64 mdadm-3.2.5-3.4.1.x86_64 mkinitrd-2.7.0-62.3.2.x86_64 multipath-tools-0.4.9-3.3.1.x86_64 nfs-client-1.2.6-2.2.1.x86_64 plymouth-scripts-0.8.6.1-1.1.1.noarch splashy-0.3.13-35.1.2.x86_64 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c9
Dieter Schroeder
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c10 --- Comment #10 from Marguerite Su 2012-09-07 00:26:12 UTC --- I‘m btrfs too... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c11
--- Comment #11 from Dieter Schroeder
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c12
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c13 --- Comment #13 from Marguerite Su 2012-10-10 14:47:43 UTC --- @Frederic Hi, Yes, you're right. (I still not give up...) I added "comment=systemd.automount" to my 1TB btrfs partition (/home), and it frees NM. here're the newest results: 227412ms systemd-tmpfiles-setup.service 9948ms NetworkManager.service 3638ms systemd-modules-load.service 3591ms systemd-vconsole-setup.service 3467ms localnet.service 2656ms dev-mqueue.mount 2652ms sys-kernel-debug.mount 2536ms var-run.mount 2519ms dev-hugepages.mount 2007ms udev.service (I have no other tweaks to systemd...) I don't know why systemd-tmpfiles-setup.service took so long. And there's still a problem that kernel needs 40s to load and userspace needs another 20s to call the first service. they're not shown in blame. I'm trying to compile btrfs module from git using dkms, but seems 3.4.6 from 12.2 can't do the trick: make KERNELRELEASE=3.4.6-2.10-desktop -C /lib/modules/3.4.6-2.10-desktop/build M=/var/lib/dkms/btrfs/git/build.....(bad exit status: 2) [...] make[3]: *** no rule to create targets "__build" needs "/var/lib/dkms/btrfs/git/build/missing-syscalls". aborted. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c14
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c15 Marguerite Su changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #502816|0 |1 is obsolete| | --- Comment #15 from Marguerite Su 2012-10-10 15:49:47 UTC --- Created an attachment (id=508990) --> (http://bugzilla.novell.com/attachment.cgi?id=508990) latest systemd plot yes, I set CLEAN_TMP_DIRS_AT_BOOT to "no" from yast and it's gone: 7449ms systemd-modules-load.service 6068ms systemd-logind.service 5765ms systemd-tmpfiles-setup.service 4153ms localnet.service 3908ms systemd-vconsole-setup.service 3323ms vboxdrv.service 2712ms sys-kernel-security.mount 2190ms dev-mqueue.mount 2187ms sys-kernel-debug.mount 2150ms syslog.service but still, kernel+usrspace took 116s until -.mount I know nothing about kernel , but seems it's hard to load it from a big btrfs partition. maybe btrfs's read/write has some unknown bugs. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c16
--- Comment #16 from David Sterba
I know nothing about kernel , but seems it's hard to load it from a big btrfs partition. maybe btrfs's read/write has some unknown bugs.
There was a change in 3.4 that needed to rebuild free space cache, please attach output of dmesg so I can verify if it's the case. This is a known issue and has been fixed in newer kernels, I'll have a look what patches need backporting. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c17 --- Comment #17 from Marguerite Su 2012-10-10 17:49:59 UTC --- Created an attachment (id=509007) --> (http://bugzilla.novell.com/attachment.cgi?id=509007) dmesg output (In reply to comment #16)
There was a change in 3.4 that needed to rebuild free space cache, please attach output of dmesg so I can verify if it's the case. This is a known issue and has been fixed in newer kernels, I'll have a look what patches need backporting.
Hi, David, Here you are. I'm happy this annoying thing seems to have an end. thanks in advance. Marguerite -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c18
Vladimir Botka
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c19 Marguerite Su changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #508990|0 |1 is obsolete| | --- Comment #19 from Marguerite Su 2012-10-11 13:47:38 UTC --- Created an attachment (id=509175) --> (http://bugzilla.novell.com/attachment.cgi?id=509175) latest systemd plot running 3.6.1 kernel Hi, I updated kernel 3.6.1 and rebuilt my btrfs cache by add mount option clear_cache to my root partition and home partition. but kernel still needs 135s to be ready to do other things. I guess it *might* be because btrfs run fsck.btrfs everytime instead of having some max mount number interval like ext4 does. then if kernel wants to modprobe a module in /lib, it has to wait for the fsck and mount of /. which slows everything. it's a reasonable guess but I don't know how to make sure if it is true. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c20 Marguerite Su changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #509007|0 |1 is obsolete| | --- Comment #20 from Marguerite Su 2012-10-11 13:48:30 UTC --- Created an attachment (id=509176) --> (http://bugzilla.novell.com/attachment.cgi?id=509176) latest dmesg output running 3.6.1 kernel -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c21
--- Comment #21 from David Sterba
Hi, I updated kernel 3.6.1 and rebuilt my btrfs cache by add mount option clear_cache to my root partition and home partition.
but kernel still needs 135s to be ready to do other things.
Clear_cache implies that the cache needs to be rebuilt on next mount (without clear_cache obviously), this takes time proportional to the filesystem size and free space. So, this will give a different number after the cache is rebuilt. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c22
--- Comment #22 from David Sterba
I guess it *might* be because btrfs run fsck.btrfs everytime instead of having some max mount number interval like ext4 does. then if kernel wants to modprobe a module in /lib, it has to wait for the fsck and mount of /. which slows everything. it's a reasonable guess but I don't know how to make sure if it is true.
It's known that running fsck.btrfs at boot time slows things down, but it does not happen on opensuse because it's replaced by /bin/true, ie. doing nothing -- because it is not supposed to work like this. Not all distros do it like this (Ubuntu). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c
David Sterba
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c23 --- Comment #23 from Marguerite Su 2012-10-11 18:41:05 UTC --- (In reply to comment #21)
Clear_cache implies that the cache needs to be rebuilt on next mount (without clear_cache obviously), this takes time proportional to the filesystem size and free space. So, this will give a different number after the cache is rebuilt.
Hi, do you mean: 1. add clear_cache to root btrfs 2. reboot 3. remove it 4. reboot twice for the readhead 5. now check the magic ? if so, I'll do it again. here's what I did: 1. add 2. reboot twice 3. remove 4. check the magic -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c24 --- Comment #24 from Marguerite Su 2012-10-11 18:43:43 UTC --- (In reply to comment #22)
It's known that running fsck.btrfs at boot time slows things down, but it does not happen on opensuse because it's replaced by /bin/true, ie. doing nothing -- because it is not supposed to work like this. Not all distros do it like this (Ubuntu).
Well...seems my system didn't When I rebuilt the initrd, it told me I have to install btrfsprog and I installed. then /sbin/fsck.btrfs is a real thing instead of a soft link to /bin/true. so I'll try manual link. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c25
--- Comment #25 from David Sterba
1. add clear_cache to root btrfs 2. reboot 3. remove it 4. reboot twice for the readhead 5. now check the magic
For a rootfs it's more complicated as one cannot just umount and mount, so these steps should do it. It is important once the clear_cache is removed that the filesystem has time to rebuild the cache, so the second reboot should not come in a quick sequenct. I don't know about the readahead though, if it makes a difference or not. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c26
--- Comment #26 from David Sterba
When I rebuilt the initrd, it told me I have to install btrfsprog
and I installed.
How come you don't have installed btrfsprogs and using btrfs? Do you have the utilities built from eg. git sources? Even if you don't use the ones from distro, keep the btrfsprogs installed, and place own-built in /usr/local .
then /sbin/fsck.btrfs is a real thing instead of a soft link to /bin/true.
so I'll try manual link.
cp /bin/true /sbin/fsck.btrfs And I've checked the package installation process does this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c27 --- Comment #27 from Marguerite Su 2012-10-11 19:10:28 UTC --- (In reply to comment #26)
How come you don't have installed btrfsprogs and using btrfs?
easy...I just uninstall it once I saw it is in the unneeded package section of YaST2. and I reinstalled it immediately...in less than 5 minutes.
cp /bin/true /sbin/fsck.btrfs
okay, then I can just keep it there. I thought it was a real fsck.btrfs intead of /bin/true since it's not a link but a copy. I'll try clean_cache and keep you informed. M -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c28
--- Comment #28 from David Sterba
easy...I just uninstall it once I saw it is in the unneeded package section of YaST2. and I reinstalled it immediately...in less than 5 minutes.
Oh, this should not happen. I think 'unneeded packages' just looks if there are dependencies on that package and if not, it suggests for removal. And there are none. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c29 --- Comment #29 from Marguerite Su 2012-10-12 09:31:25 UTC --- Created an attachment (id=509354) --> (http://bugzilla.novell.com/attachment.cgi?id=509354) latest systemd plot after clear_cache (In reply to comment #28)
Oh, this should not happen. I think 'unneeded packages' just looks if there are dependencies on that package and if not, it suggests for removal. And there are none.
yes. but there're dependencies on btrfsprog like coreutils and libc, but YaST unneeded package still suggest for removal... Since yesterday I rebooted a lot, but every time it just returns the same result. kernel still need 120~130s to load and -.mout then every systemd service began. So it seems to be some unknown bugs which is btrfs related but not clear_cache related. see my latest systemd plot after clear_cache. M -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c30 Marguerite Su changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |dsterba@suse.com --- Comment #30 from Marguerite Su 2012-10-19 18:58:18 UTC --- It is solved! http://www.spinics.net/lists/linux-btrfs/msg19766.html I asked for help upstream. and they found the reason is:
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.
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).
the solution is: UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e / btrfs defaults,space_cache,comment=systemd.automount 1 0 UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /home btrfs defaults,space_cache,comment=systemd.automount 1 0 which openSUSE has a different setting: defaults 1 2 it means it didn't enable cache for btrfs at all(so my last try of clear_cache didn't work, because there's no cache to clear). So David, can we make the setting above happen in openSUSE? * add "space_cache" to btrfs partition will make sure it enables cache. * 2->0 make sure it will not do fsck.btrfs. then we can restore fsck.btrfs to its normal function. Marguerite -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563
https://bugzilla.novell.com/show_bug.cgi?id=776563#c31
David Sterba
(In reply to comment #28)
Oh, this should not happen. I think 'unneeded packages' just looks if there are dependencies on that package and if not, it suggests for removal. And there are none.
yes. but there're dependencies on btrfsprog like coreutils and libc, but YaST unneeded package still suggest for removal...
No, the other way around: there are no packages that require btrfsprogs (checked on my installations, where eg. yast and snapper are installed) (In reply to comment #30) I think that the problems originate from a non-installed package of btrfsprogs, thus the fsck.btrfs utility was not properly made a no-op. The fstab option should not matter at all and this is intentional. There is no need to fsck a btrfs filesystem at mount time, by design. This was required by extN filesystems as their fsck also replays the journal. The best values are "0 0" and I'll ask to change this in yast. The space_cache option is turned on implicitly, there's no point in adding it to the mount options. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=776563 https://bugzilla.novell.com/show_bug.cgi?id=776563#c32 --- Comment #32 from Marguerite Su 2012-10-25 16:54:05 UTC --- (In reply to comment #31)
The space_cache option is turned on implicitly, there's no point in adding it to the mount options.
yes, but are you sure this option is the same for early created btrfs like before 3.2? if it's my mistake that I turned off that option, there should be no one except me get involved in this thread. but there was another one jumped in and had the same problem. so I guess maybe here's the thing: 1. space_cache doesn't work for btrfs created before 12.2 unless after a clear_cache. As you said, it's a 3.4 issue. but my btrfs still lag in 3.3 if that option was enabled for that period....or that option was introduced in 3.4? 2. or that option wasn't enabled for btrfs created before 12.2. only enabled for fresh installed 12.2 with unparted harddisks.. I'm completely outsider for btrfs...so if you think it's worthy digging further...then dig. or else it is resolved. Thanks for all your help, David. Marguerite -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com