[opensuse] insane disk activity after resume?
Hi, since I switched my Laptop to OS 13.2 with BTRFS as root filesystem, after each resume I see an insane disk activity on my system disk. The HD light is flashing permanently, and activating block dump logging gives entries like Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2067264 on sdb2 (96 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2067520 on sdb2 (32 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2067872 on sdb2 (32 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2068256 on sdb2 (320 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2068608 on sdb2 (160 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2068800 on sdb2 (128 sectors) Apr 17 08:31:06 snoopy kernel: kworker/u4:1(2540): WRITE block 2089472 on sdb2 (96 sectors) It really seems to be going through the *whole* disk (100G), it is currently still running, 1h 40 after resume. Does anyone have an idea *what* the reason for this is, or how I can try to find out? This is an SSD, so I'm definitely NOT amused about this massive writing (at least) two times per day. Pit -- Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit Institute for Solar Physics Tel.: +34 922 405 590 (Spain) P.Suetterlin@royac.iac.es +46 8 5537 8507 (Sweden) Peter.Suetterlin@astro.su.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Freitag, 17. April 2015 09:42 CEST, P.Suetterlin@royac.iac.es schrieb:
since I switched my Laptop to OS 13.2 with BTRFS as root filesystem, after each resume I see an insane disk activity on my system disk.
You can use the commands atop, sar or iostat to find out which process triggers those writes. See also https://unix.stackexchange.com/questions/55212/how-can-i-monitor-disk-io/ Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2015 03:42 AM, P.Suetterlin@royac.iac.es wrote:
Does anyone have an idea *what* the reason for this is, or how I can try to find out?
An inherent problem with disk drivers and file systems is that so much of the activity has to be run at kernel level to preserve integrity. In some extreme cases it is not even possible to suspend the relevant thread (e.g. Waiting for an interrupt) and the CPU is in a kernel level spin loop. This is hateful and such needs to be avoided, but like so many things, each generation of programmers needs to re-learn it. Its too easy to 'spin-loop' rather than set up conditions to preserve integrity across changes in execution thread and possible discontinuity/crash. I don't know if this is what is going on here. I do know from my own experience writing error correcting disk drivers for pre-Linux UNIX that it can happen, that it is tempting for kernel coders to take an easy route rather than consider how to 'checkpoint' kernel level operations to make them atomic. Personally I'd hate to be a programmer on the BtrFS project. The though of trying to purge and balance at the kernel level as opposed to an off-line FSCK parameter scares me! I subscribe to the BrtFS list and see some of the patches coming though and its not so much the parches themselves so much as the problems they are 'solving' that makes me wish for the "simplicity" of the old V7FS. Sometimes the price of progress is complexity, and managing that complexity is a problem in its own right. Still, I can't imagine a V7FS scaling to 4T disk and today's databases :-) What we have to do is make sure we post bug reports and get them acted on. Sadly, sometimes its not easy to tie down a 'bug' (as opposed to 'syndromic behaviour') in such a way that the developers can recognise it and try to trace its cause. And even then .... Well the Ruby/Tk problem I've mentioned in another thread has been known and reported since, that I know of, as far back as 2010, and nothing has been done about it. lets how a file system bug is considered more critical. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Aaron Digulla -
Anton Aylward -
P.Suetterlin＠royac.iac.es