Re: Issue 52663 in chromium: frequent small disk I/O

[chro...@googlecode.com]

Comment #1 on issue 52663 by mkterra: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Maybe the phishing/malware filter downloading updates? See if it stops
doing it if you uncheck "Enable phishing and malware protection" in the
Options.

[chro...@googlecode.com]

Updates:
Labels: -Area-Undefined Area-Internals

Comment #2 on issue 52663 by stuart...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #3 on issue 52663 by jasontdavidson: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

WIN7 and with version 6.0.472.36 in BETA I get the same thing. When I
leave Chrome open the OS never goes into hibernation and will continually
run. If I close Chrome the OS will do as it is supposed to and go into
hibernation in a timely manner.

[chro...@googlecode.com]

Comment #4 on issue 52663 by Sean.Middleditch: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I had tried disabling phishing protection briefly, it didn't stop. Should
it take more than a minute after disabling before the disk I/O would stop?

[chro...@googlecode.com]

Comment #6 on issue 52663 by arkadi.shishlov: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

With a single static page open Chrome periodically writes into
~/.config/google-chrome/Default/Current Session file. This happens every
time the desktop holding browser window is activated even no activity is
performed (running xfwm4 with compositor).
If, for example, a webmail page is left open the background ajax requests
make Chrome write into following files:
~/.config/google-chrome/Default/Cookies-journal (re-created for every
transaction, unlinked)
~/.config/google-chrome/Default/Cookies
~/.config/google-chrome/.com.google.chrome.* (temporary, unlinked)
/var/tmp/etilqs_* (sqlite temporary, unlinked)

There are also /dev/shm/.com.google.chrome.* files, so
~/.config/google-chrome/.com.google.chrome files might also be another
problem.

[chro...@googlecode.com]

Comment #8 on issue 52663 by kgra...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

So perhaps making ~/.config/google-chrome a ramfs would be helpful? I'm
also just noticing this problem on my new laptop. Chrome seems to write to
disk every minute or so.

[chro...@googlecode.com]

Comment #9 on issue 52663 by Sean.Mid...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

It might be helpful as a hack. It'd be better to just fix the bug.

[chro...@googlecode.com]

Comment #10 on issue 52663 by xgates....@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I hear the hard drive being accessed when I'm just surfing the web on a
dual core 2.8ghz with 4GB ram on a fast box I built, there's no excuse to
hear hard drive access with a fast system....

PLEASE fix this Google...

THANKS

[chro...@googlecode.com]

Comment #11 on issue 52663 by tomvdmo...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

this bug still takes place in version 13.0.782.13 dev-m

chrome writes to disk when your mouse is inside the windows, even when it's
just sitting there... i checked with task manager.

AND THE BIG PROBLEMS IS i'm running an SSD AND THIS IS COSTING ME A LOT OF
MY WRITECYCLES

so generally chrome is SCREWING AROUND with my SSD

[chro...@googlecode.com]

Updates:
Labels: OS-Linux Stability-Performance

Comment #12 on issue 52663 by mkte...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Is everyone who sees this using Linux?

[chro...@googlecode.com]

Comment #13 on issue 52663 by tomvdmo...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Windows 7 Ultimate 64 bit

[chro...@googlecode.com]

Comment #14 on issue 52663 by pncal...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Mac OS 10.6.7

[chro...@googlecode.com]

Comment #15 on issue 52663 by jasontda...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Win 7 64 bit

[chro...@googlecode.com]

Updates:
Labels: -OS-Linux OS-All

Comment #17 on issue 52663 by mkte...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Thanks; Changing label to OS-All.

[chro...@googlecode.com]

Comment #19 on issue 52663 by i...@tarcus.org.uk: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I'm running Ubuntu 11.10 and am trying to get the drive to spin down,
unfortunately Chromium is hitting the disk every few seconds according to
the lm-profiler tool (which reports what is causing the disk to stay
awake). If I quit chromium the discs do spin down and the lm-profiler tool
then stops reporting frequent write accesses. Please fix this as I can't
use chromium if I am running on battery unless I want short battery life.

[chro...@googlecode.com]

Comment #24 on issue 52663 by hugues.m...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Same thing on my computer running Archlinux / 3.3.4-2 kernel. I can clearly
hear my drive writing every 3 seconds. It writes very often.
It's not the cache, because I have it on a tmpfs (ramdisk).
Enabled debug in my kernel, and the result is not surprising, Chromium uses
my disk everytime. Even with no extensions (previously was just
using "Adblock" and "Silver Bird"), or blank page, it's the same as before.

Here the output: http://pastebin.archlinux.fr/443140

Very annoying to see this bug is still not assigned. What are you doing
devs?

[chro...@googlecode.com]

Comment #25 on issue 52663 by gunfl...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Same issue, running Linux Mint 13, every few seconds confirmed chrome
process with iotop

[chro...@googlecode.com]

Updates:
Cc: tomhud...@chromium.org

Comment #26 on issue 52663 by tomhud...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Unfortunately, we haven't reproduced this in-house, so we can't really do
anything on it. If you're suffering from this, please follow the
instructions at
http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
and post the file generated here; that'll give us some idea of what's going
on on your computer to be causing this. Data from chrome://profiler and the
Chrome Task Manager (shift-escape) may also be useful.

[chro...@googlecode.com]

Comment #27 on issue 52663 by tomvdmo...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

here you go.

I just let it run for a few seconds, had some tabs open, but didn't do much.
chrome was still doing small frequent disk io

Attachments:
chromedebug.rar 410 KB

[chro...@googlecode.com]

Comment #28 on issue 52663 by tomhud...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

tomvdmolen@: Thanks. Unfortunately, although I can tell that the I/O thread
is doing stuff, we don't have it instrumented deeply enough to tell *what*
it's doing. Could you open up chrome://profiler, Group by > Birth thread,
Sort by > Total run time (DESC), save that & send it?

[chro...@googlecode.com]

Comment #29 on issue 52663 by tomhud...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Also, it might help to do that about a minute after restarting your
browser, or hit the "[Reset tracking data]" link at the bottom of the page,
wait a minute or three, and then save data.

[chro...@googlecode.com]

Comment #30 on issue 52663 by tomvdmo...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

@tomhudson: sure thing :)

Although I think this is a minor issue for HDD's you can imagine that I
have a little fear it decreases my SSD's lifespan.

Attachments:
3b5019c6-ee4a-418a-adb8-a212b468a335 1.1 MB

[chro...@googlecode.com]

Comment #31 on issue 52663 by tomvdmo...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

oh, and here is the second one

Attachments:
b315f7b8-5297-45f3-9a96-7cf8c81b3a3b 795 KB

[chro...@googlecode.com]

Updates:
Cc: j...@chromium.org

Comment #32 on issue 52663 by tomhud...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Jim, do you have an idea who'd be familiar enough with what task profiler
traces *should* look like to figure out if there's any smoking gun in these?

[chro...@googlecode.com]

Comment #34 on issue 52663 by tomhud...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Jim, for what it's worth, the b315... profile loads fine into Win7 Canary
for me.

Process type = Browser and Birth thread = Chrome_IOThread
23,113 9,776 0 2,553 5 285 13 unique 1 unique 161 unique 165 unique
Count** Total run time Avg run time Max run time Avg queue time Max queue
time Exec thread PID Function name Source location
13,097 467 0 59 2 217 CrBrowserMain 2580
IPC::ChannelProxy::Context::OnMessageReceivedNoFilter ipc_channel_proxy.cc
[97]
981 89 0 3 0 16 Chrome_CacheThread 2580
disk_cache::InFlightBackendIO::PostOperation in_flight_backend_io.cc [512]
690 0 0 0 0 68 Chrome_IOThread 2580
content::ResourceDispatcherHostImpl::StartRequest
resource_dispatcher_host_impl.cc [1767]
676 4 0 1 1 201 CrBrowserMain 2580
content::ResourceDispatcherHostImpl::UpdateLoadStates
resource_dispatcher_host_impl.cc [2241]
630 3 0 1 22 218 CrBrowserMain 2580
`anonymous-namespace'::ForwardRequestStatus chrome_network_delegate.cc [112]
467 12 0 1 81 115 CrBrowserMain 2580
`anonymous-namespace'::ChromeCookieMonsterDelegate::OnCookieChanged
profile_io_data.cc [90]
450 192 0 5 2 168 CrBrowserMain 2580
RenderWidgetHelper::DidReceiveBackingStoreMsg render_widget_helper.cc [209]
423 0 0 0 18 219 CrBrowserMain 2580 TaskManagerModel::NotifyBytesRead
task_manager.cc [1047]
416 0 0 0 0 0 Chrome_IOThread 2580
_IpcMessageHandlerClass::OnDataReceivedACK resource_dispatcher_host_impl.cc
[672]
378 2 0 1 0 0 Chrome_IOThread 2580
_IpcMessageHandlerClass::OnExtensionGenerateUniqueID
chrome_render_message_filter.cc [102]

Process type = Browser and Birth thread = Chrome_IOThread
23,113 9,776 0 2,553 5 285 13 unique 1 unique 161 unique 165 unique
Count Total run time** Avg run time Max run time Avg queue time Max queue
time Exec thread PID Function name Source location
27 8,014 297 2,553 0 6 WorkerThread-* 2580
net::HostResolverImpl::ProcTask::StartLookupAttempt host_resolver_impl.cc
[670]
13,097 467 0 59 2 217 CrBrowserMain 2580
IPC::ChannelProxy::Context::OnMessageReceivedNoFilter ipc_channel_proxy.cc
[97]
450 192 0 5 2 168 CrBrowserMain 2580
RenderWidgetHelper::DidReceiveBackingStoreMsg render_widget_helper.cc [209]
21 124 6 43 0 2 WorkerThread-* 2580 net::CertVerifierWorker::Start
multi_threaded_cert_verifier.cc [161]
1 92 92 92 0 0 AudioThread 2580 media::AudioOutputController::Create
audio_output_controller.cc [83]
981 89 0 3 0 16 Chrome_CacheThread 2580
disk_cache::InFlightBackendIO::PostOperation in_flight_backend_io.cc [512]
1 87 87 87 0 0 Chrome_FileThread 2580
MemoryDetails::CollectChildInfoOnIOThread memory_details.cc [191]
310 85 0 4 0 0 Chrome_IOThread 2580
_IpcMessageHandlerClass::OnRequestResource resource_dispatcher_host_impl.cc
[668]
6 68 11 15 1 4 Chrome_FileThread 2580
ChromeRenderMessageFilter::OnGetExtensionMessageBundle
chrome_render_message_filter.cc [319]
6 68 11 21 0 0 WorkerThread-* 2580
net::PollingProxyConfigService::Core::CheckForChangesNow
polling_proxy_config_service.cc [94]

[chro...@googlecode.com]

Comment #35 on issue 52663 by Andrey.P...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I confirm the issue. Ubuntu 12.04, Chromium 18.0.1025.168 (Developer Build
134367 Linux) Ubuntu 12.04. Write every several seconds, very annoying.

[chro...@googlecode.com]

Comment #36 on issue 52663 by Andrey.P...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

here the profile report

Attachments:
f0649346-1880-41c5-85e2-97fd8acb500e 2.4 MB

[chro...@googlecode.com]

Comment #39 on issue 52663 by teromlai...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

At least for me this seems to related to cookies. Procmon revealed that
chrome was constantly writing files
C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default\Cookies
and
C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default\Cookies-journal

Turning the cookies setting to the second option ("Keep local data only
until I quit my browser") seems to have fixed the problem, at least for now.

[chro...@googlecode.com]

Comment #40 on issue 52663 by darkwing...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I see this behaviour for different files, which have in commnon that they
are Sqlite DBs.

I guess chromium needs to set "PRAGMA synchronous = NORMAL;" [1] or even
OFF to reduce IO those minimal but frequent IO writes.

I tried to understand the code tree to figure out where this should belong
but might take some time.

[1] http://www.sqlite.org/pragma.html#pragma_synchronous

[chro...@googlecode.com]

Comment #41 on issue 52663 by Andrey.P...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Nice, waiting for it!

[chro...@googlecode.com]

Comment #42 on issue 52663 by tarasov....@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I can also confirm this (Ubuntu 12.10 64bit, Chrome 23.0.1271.91). I have
pretty quiet and cool notebook, most of the time you can't hear the cooler,
so the only thing you can hear is HDD heads moving. And when in a quiet
room you work, and notebook is ticking every few seconds (and HDD LED
flashes) it becomes more and more annoying. It distracts so much that I can
hardly concentrate. And I can't avoid having Chrome open constantly, as it
is one of my primary tools. And I don't even speak about energy saving...

So, please, fix this.

The files that are being updated:

.config/google-chrome/Default/Cookies
.config/google-chrome/Default/Cookies-journal
.config/google-chrome/Default/Current Session

Some testing and watching shows that "Current Session" file is being
updated at least every 10 seconds, sometimes more often. "Cookies"
and "Cookies-journal" get updated once in a minute. Plus if you have any
Google+ notification widgets on any open page (that is, any google service,
including search), or Google+ extensions, these also update local storage
frequently, which leads to saving data to disk. This all ends up in updates
every 2-10 seconds.

Also, "Curent Session" file keeps increasing it's size (currently, about
250K in a minute), so that it can end up in several megabytes in quite
short amount of time, and then at some point it shrinks back to ~200K. I
can hardly understand what data is being written down in such amounts,
every 10 seconds. Maybe most of it could be stored in memory? Opera
browser, for example, can also restore all tabs after restart or a crash,
but it records down state only when you navigate (url changes) or open up
new tabs.

Thanks in advance.

[chro...@googlecode.com]

Comment #43 on issue 52663 by macho...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

As far as I can tell I am seeing this exact behavior on Windows 7 Ultimate,
6GB RAM, with only a static page loaded in Chrome. Starting incognito or
starting without extensions doesn't seem to have any effect. I will add
that since this started happening when I start Chrome it will frequently,
but not always, complain that it failed to shut down gracefully. I wonder
if it's spooling some session data to a log and that isn't being closed
properly as a side effect of whatever the root problem is.

[chro...@googlecode.com]

Comment #44 on issue 52663 by macho...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Update: I tried uninstalling Chome and then downloading and installing the
latest version (24.0.1312.52) and I was *still* having the problem where
the disk was being hit every 5-10 seconds by a process started by Chrome. I
shut down Chrome, went to where all the session and user data is logged on
disk (on Windows 7 this is under here:
%LOCALAPPDATA%\Google\Chrome\) and then deleted the "User Data" folder.
Upon restarting and relogging into the browser the periodic logging has
stopped. I suspect there's still some bug in Chrome that gets the session
journal into a looping state, but nuking all the pre-existing cookies,
session data, etc. seems to finally fix the problem.

[chro...@googlecode.com]

Updates:
Cc: sh...@chromium.org

Comment #45 on issue 52663 by j...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

+cc Scott.... in case he has thoughts about some recovery mode in the
database that might drive this.

[chro...@googlecode.com]

Comment #46 on issue 52663 by sh...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

SQLite has no independent execution context. If SQLite is writing to the
disk, it's because a module which is a client of SQLite is writing stuff
into a database.

[chro...@googlecode.com]

Comment #47 on issue 52663 by gmcs...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Folks, I can confirm that exiting Chrome and deleting contents of your:

C:\Users\Andrew\AppData\Local\Google\Chrome\User Data\Default\Extension
State

folder fixes this issue. I had three profiles: default, profile 1, profile
2. In 'default' under 'extension state' I had almost 200 mb in 150 sst
files. In the other two profiles, under 'extension state' folder there was
negligible content.

Background
----------

I noticed Chrome was chewing 5 - 20% CPU constantly even with just the home
tab open. See http://i49.tinypic.com/17ek2h.png and
http://i48.tinypic.com/i6le86.png

I disabled ALL Chrome plugins, restarted, no change.

I uninstalled/reinstalled Chrome (but chose to retain my browsing history)
and no change. Same constant CPU use and IO activity.

I ran Sysinternals procmon to identify where Chrome was doing all the disk
I/O, and learned it was constantly creating and writing to sst files
in 'Chrome\User Data\Default\Extension State'.

http://i48.tinypic.com/69ls8o.png

Googling lead me to this topic, and deleting all content in that profile
folder solved the issue for me.

So this is definitely a bug.

My rig: Win7-64, Ahtlon 2 X4 640, 8 gigs memory, Chrome Version
24.0.1312.56 m

[chro...@googlecode.com]

Comment #48 on issue 52663 by gmcs...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Further to above, I zipped the contents of my 'extension state' folder
prior to deleting.

Here's the LOG file it contained: http://www.sendspace.com/file/zmmaat

Sample:

-----

2013/01/26-14:59:23.150 4764 Compacting 150@0 + 1@1 files
2013/01/26-14:59:23.914 4764 compacted to: files[ 150 1 0 0 0 0 0 ]
2013/01/26-14:59:23.915 4764 Delete type=2 #131928
2013/01/26-14:59:23.915 4764 Compaction error: IO error:

C:\Users\Andrew\AppData\Local\Google\Chrome\User Data\Default\Extension

State/000473.sst: File not found.
2013/01/26-14:59:23.915 4764 Waiting after background compaction error: IO
error: C:\Users\Andrew\AppData\Local\Google\Chrome\User
Data\Default\Extension State/000473.sst: File not found.
2013/01/26-14:59:24.915 4764 Compacting 150@0 + 1@1 files
2013/01/26-14:59:25.652 4764 compacted to: files[ 150 1 0 0 0 0 0 ]
2013/01/26-14:59:25.653 4764 Delete type=2 #131929
2013/01/26-14:59:25.653 4764 Compaction error: IO error:

C:\Users\Andrew\AppData\Local\Google\Chrome\User Data\Default\Extension

State/000473.sst: File not found.
2013/01/26-14:59:25.653 4764 Waiting after background compaction error: IO
error: C:\Users\Andrew\AppData\Local\Google\Chrome\User
Data\Default\Extension State/000473.sst: File not found.
2013/01/26-14:59:26.654 4764 Compacting 150@0 + 1@1 files
2013/01/26-14:59:27.388 4764 compacted to: files[ 150 1 0 0 0 0 0 ]
2013/01/26-14:59:27.388 4764 Delete type=2 #131930
2013/01/26-14:59:27.389 4764 Compaction error: IO error:

C:\Users\Andrew\AppData\Local\Google\Chrome\User Data\Default\Extension

State/000473.sst: File not found.
2013/01/26-14:59:27.389 4764 Waiting after background compaction error: IO
error: C:\Users\Andrew\AppData\Local\Google\Chrome\User
Data\Default\Extension State/000473.sst: File not found.
2013/01/26-14:59:28.389 4764 Compacting 150@0 + 1@1 files
2013/01/26-14:59:29.237 4764 compacted to: files[ 150 1 0 0 0 0 0 ]
2013/01/26-14:59:29.238 4764 Delete type=2 #131931

[chro...@googlecode.com]

Comment #49 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

gmcs' solution didn't fix it for me. It still gives tons of disk operations
on a clean incognito window several seconds later:
http://i.imgur.com/AEihTgI.png

[chro...@googlecode.com]

Comment #50 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

it appears to 'fix' if we completely delete(/rename) the
AppData\Local\Google\Chrome\User Data folder. I guess we'll have to go
slowly from there..

[chro...@googlecode.com]

Comment #51 on issue 52663 by gmcs...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Here's a diagnostics tip I received from François Beaufort.

Kill all chrome processes.

Create a new shortcut for Chrome and append --user-data-dir=foo to the
command line. This will create a new profile called 'foo'. Start chrome
from the new shortcut, which will automatically load the clean 'foo'
profile.

After chrome starts, check the chrome task manager (right-click on empty
part of tab strip at top) to see if any processes are consuming excessive
resources.

Run procmon and check chrome's disk activity.

This will at least tell you if the issue is profile specific, i.e. if you
do not see the issue happening when using a newly created profile then it's
something to do with your other profile. Perhaps a plug-in or setting.
Or, as in my case, some kind of persistent but profile-specific storage bug.

[chro...@googlecode.com]

Comment #52 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

It keeps doing tons of operations here with a clean profile (foo)

http://i.imgur.com/IrQSrkT.png

(I had written before a cleaning of appdata was fixing it. That was
erroneous/comment deleted.)

[chro...@googlecode.com]

Comment #53 on issue 52663 by gmcs...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

arx, as far as I can tell, those *.tmp file activites are normal. I tested
on my chrome with procmon and saw the same activity as your screenshot.

What's your specific issue? Mine was seeing a constant 10 - 20%
fluctuating CPU use by the main chrome process. My issue is different to
yours because it only involved *.sst files.

[chro...@googlecode.com]

Comment #54 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Why are they normal? What does an empty incognito window doing with writing
to several files after being idle?

[chro...@googlecode.com]

Comment #55 on issue 52663 by gmcs...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

arx, I just tested by:

* open new incognito window
* find the PID for the new incognito window from Chromes Task Manager >
Stats for Nerds
* set filter on procmon to only include events for that PID
* sample the activity over a minute while doing no browsing in the
incognito window

Results: about 69 entries in the procmon log, none of which were for *.tmp
files

So the issue is not exhibiting for me in the incognito tab scenario.

When you are running procmon, are you explicitly filtering only to capture
events from individual tabs via their PID. From memory, based on your
screenshot, you were only filtering on chrome.exe, which will include the
main browser process plus all sub processes (tabs). If you filter by PID
(process ID) then you'll have a better chance to narrow down exactly where
in Chrome the problem is happening.

[chro...@googlecode.com]

Comment #56 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Good idea. Though they all appear to be coming from the PID of 'Browser'
(the main process in the in-Chrome Task Manager).

[chro...@googlecode.com]

Comment #57 on issue 52663 by gunfl...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Similar results here, attached. It may be normal but it's irritating

Attachments:
chrome-io.jpg 393 KB

[chro...@googlecode.com]

Comment #58 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I was wondering if it's a system process that does it indirectly though
unlikely if it's reported on chrome.exe and if others are seeing it on
other operating systems.

I suspect it's internal operations running on a global loop, that probably
deal with caching, logging, memory caching, temp caching, etc.

I do not know if they are fundamental with the operation of the program but
it sounds peculiar if they are obligatory in principle (when an empty
window is idle for example).

[chro...@googlecode.com]

Comment #59 on issue 52663 by war59312: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Seeing this as well because of two errors it seems.

Every two seconds:

2013/02/06-20:43:25.483 5724 Compacting 32@0 + 1@1 files
2013/02/06-20:43:25.584 5724 compacted to: files[ 32 1 0 0 0 0 0 ]
2013/02/06-20:43:25.585 5724 Delete type=2 #320
2013/02/06-20:43:25.586 5724 Compaction error: IO error:
C:\Users\Will\AppData\Local\Google\Chrome\User Data\Performance Monitor
Databases\Metrics/000044.sst: File not found.
2013/02/06-20:43:25.586 5724 Waiting after background compaction error: IO
error: C:\Users\Will\AppData\Local\Google\Chrome\User Data\Performance
Monitor Databases\Metrics/000044.sst: File not found.

2013/02/06-20:40:33.079 5724 Waiting after background compaction error: IO
error: C:\Users\Will\AppData\Local\Google\Chrome\User Data\Performance
Monitor Databases\Max Value Metrics/000049.sst: File not found.
2013/02/06-20:40:35.428 5724 Compacting 29@0 + 1@1 files
2013/02/06-20:40:35.440 5724 compacted to: files[ 29 1 0 0 0 0 0 ]
2013/02/06-20:40:35.441 5724 Delete type=2 #236
2013/02/06-20:40:35.441 5724 Compaction error: IO error:
C:\Users\Will\AppData\Local\Google\Chrome\User Data\Performance Monitor
Databases\Max Value Metrics/000049.sst: File not found.

[chro...@googlecode.com]

Comment #60 on issue 52663 by newton.j...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

#52

I've tried to use this --user-data-dir=whatever flag to create a clean
profile. However, some of the SQLite databases are created with data
already in them.
http://sourceforge.net/projects/sqlitebrowser/

I've also tried marking the user data directory as read-only, but on my XP
machine, Chrome ignores it and writes to the directory anyway. Perhaps a
modern OS would be more careful about obeying read-only flags?

[chro...@googlecode.com]

Comment #61 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I still have no idea how it's justified to have disk operations on a lone
window staying idle on an empty page.

Has anyone found anything yet?

I would understand it if for optimization reasons it did for tons of pages
but for empty pages as well? Or even being idle and left alone? Why would
you do that?

[chro...@googlecode.com]

Comment #62 on issue 52663 by dgr...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Some background on the sst problem can be found from issue 171561. It
should be fixed in chrome 26. That's only a subset of problems that this
bug applies to, though.

[chro...@googlecode.com]

Comment #63 on issue 52663 by christangrant: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I fixed the problem in my case. I had to delete ALL history from the
beginning of time. Chrome has an auto archive and once mail gets to a
particular age chrome begins to archive the history from those days. If you
were particularly active on the internet for a time period who's time for
archival has arrived, you can expect an archival process to start.

I sadly, deleted all my history but know I can open my macbook air without
the it sounding like a vacuum when I open chrome.

[chro...@googlecode.com]

Comment #64 on issue 52663 by arx...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

This might be of indirect importance to the subject:

While I was trying to workaround it by using a RAM disk for a user dir (the
actual disk device is very quirky and I want to avoid its use wherever I
can on the system) and by using a cache size of one byte (no way apparently
to disable it altogether), I noticed if one points the cache to a
non-existent place it disables it completely. It sounds risky though since
I do not know if it's persistent and not changed in the future as a
behavior since it's probably undocumented and a workaround.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #67 on issue 52663 by d.noord...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Thanks gmcs, I had the same issue (actually chrome was doing 150-200MB disk
read/sec on some of the .sst files) and deleting the
Local\Google\Chrome\User Data\Default\Extension State dir fixed the problem.

Thanks again :)

[chro...@googlecode.com]

Comment #68 on issue 52663 by Mezin.Al...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

The problem for me is caused by flash plugin.

In chromium the process "plugins" is constantly writing something, in
chrome - "libpepperflash.so"

Removing "Extension State" directory doesn't solve the problem.

[chro...@googlecode.com]

Comment #69 on issue 52663 by doug65...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

To trace it in windows, use ProcessMonitor from SysInternals, run chrome,
and watch the spam of obviously unnecessary write calls made by the Chrome
process when it is completely idle.

I had to get rid of chrome because I felt it was wrecking my SSD. My 2 year
old SSD reports (in SMART) that it is 75% worn out from writes. Unnecessary
write spam is not negligible.

The bug probably also wrecks battery life for laptop users. If you use
Chrome on a laptop, uninstall it and get a browser that won't kill your
battery. Firefox is better anyway.

[chro...@googlecode.com]

Comment #70 on issue 52663 by alte...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I have the same trouble with Chrome version 26.0.1410.63 on Fedora 18.
Chrome use hard drive every 1-5 seconds.
I tried to store snapshots on chrome://profiler page by press to
button "Save", but it have no effect for me. :( Then i go to
chrome://tracing page and record some tracing info. This info attached to
the message.

P.S. btw in Firefox haven't described troubles.

Attachments:
tracing.chrome.log.tar.bz2 1.9 MB

[chro...@googlecode.com]

Comment #71 on issue 52663 by txsan...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

same happens with the new chromium based opera 15.
Really annoying, but it seems noone cares about this.

[chro...@googlecode.com]

Comment #72 on issue 52663 by erik.squ...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Seriously, this issue has been around for 3 years and it's yet to be
fixed?? I just noticed it while trying to figure out why my SSD didn't spin
down. Guess I'll go back to FF.

[chro...@googlecode.com]

Comment #73 on issue 52663 by luigi.ro...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Below files that are updated quite often. I'm running on Ubuntu 13.04 on a
USB drive. The light is always on. Is there a way to control the frenquency?

Extension Cookies
Extension Cookies-journal
QuotaManager-journal
QuotaManager
History
Favicons
Cookies
Cookies-journal
Visited Links
History-journal
Favicons-journal
Current Session
Origin Bound Certs
Origin Bound Certs-journal

[chro...@googlecode.com]

Comment #75 on issue 52663 by newton.j...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663


It's still happening and still annoying. My Google caches are disabled,
history and user data frequently cleared, and still Chrome feels the need
to write to my hard drive every few seconds even when I'm not browsing.

If it's session data to blame, I would be perfectly fine with session data
being recorded just once a minute.

What action is needed to mark this issue "confirmed"?

Can it be merged with Issue 258215?

[chro...@googlecode.com]

Comment #77 on issue 52663 by sh...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

#75, there are probably a half dozen or a dozen different sources of this,
what this bug needs is for someone to decide to commit to spending the time
tracking each one down, which is clearly a kind of bottomless pit for
engineering time. I periodically pull off such bugs to work on, but
unfortunately right now I'm working on a different yak-shave ...

[chro...@googlecode.com]

Updates:
Status: Available
Cc: pa...@chromium.org pli...@chromium.org bul...@chromium.org
Labels: Type-Bug

Comment #78 on issue 52663 by to...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

+1 to #c77. This probably has battery life implications on android. Maybe
that could help bump it up into someone's queue?

[chro...@googlecode.com]

Updates:
Cc: agau...@chromium.org

Comment #79 on issue 52663 by to...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Issue 258215 has been merged into this issue.

[chro...@googlecode.com]

Comment #81 on issue 52663 by sh...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Comment #48 is about a leveldb database, not SQLite.

[chro...@googlecode.com]

Comment #82 on issue 52663 by impinball: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Would any of these files (all output from about:tracing) help in diagnosing
this issue?

I attached the three in a single zip file.

Here's the ones I did it on (all 64-bit): Ubuntu 13.10 Saucy using Beta,
Windows 7 SP2 using Beta, and Windows 7 using Canary.

Attachments:
traces.zip 3.6 MB

[chro...@googlecode.com]

Comment #89 on issue 52663 by trammel...@gmail.com: frequent small
disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

On Linux running 32.0.1700.77 (Official Build 244503), I see the same
periodic writes. Using /proc/sys/vm/block_dump, the following appear in
dmesg:

[ 1365.166192] BrowserBlocking(2542): WRITE block 127002488 on dm-1 (8
sectors)
[ 1365.183999] BrowserBlocking(2542): WRITE block 25774832 on dm-1 (8
sectors)
[ 1365.184339] BrowserBlocking(2542): WRITE block 127002888 on dm-1 (32
sectors)
[ 1365.185080] BrowserBlocking(2542): WRITE block 26400496 on dm-1 (8
sectors)
[ 1365.185296] BrowserBlocking(2542): WRITE block 26631584 on dm-1 (32
sectors)
[ 1365.186041] BrowserBlocking(2542): WRITE block 26660808 on dm-1 (8
sectors)
[ 1365.186256] BrowserBlocking(2542): WRITE block 26660832 on dm-1 (8
sectors)
[ 1365.258000] BrowserBlocking(2542): WRITE block 127002488 on dm-1 (8
sectors)
[ 1367.167546] BrowserBlocking(2553): WRITE block 127002488 on dm-1 (8
sectors)
[ 1367.167815] BrowserBlocking(2553): WRITE block 127002712 on dm-1 (8
sectors)
[ 1367.168238] BrowserBlocking(2553): WRITE block 25774968 on dm-1 (16
sectors)
[ 1367.168635] BrowserBlocking(2553): WRITE block 26590344 on dm-1 (56
sectors)

[chro...@googlecode.com]

Comment #90 on issue 52663 by john.s....@live.com: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

# add save frequency option

## one size don't fit all for SSD killing

do you want to add a save frequency option?, because

* one size fit all can't accomodate user preference for SSD killing
behavior because

* some users use MLC rather than TLC flash that accept less writes
(https://www.google.com/search?q=ssd+endurance)

* some users want their SSD to last 30 rather than 3 years


## dude, you're killing my SSD

these pictures
https://www.dropbox.com/sh/2z5p162ovqtbn17/NXz1NzNd0O/program/chrome show
that chrome.exe write 5 g/day compared to 0,5 g/day for firefox.exe, week
after week until it kills my MFC flash after 3 years


## files written

@#73 I confirm that those files are written constantly for my Windows 7,
Chrome 33.0.1750.154 m


## chrome settings

my cache writes are disabled by using a non-existing cache dir by starting
the program with an argument

chrome.exe --disk-cache-dir="z:\" --media-cache-dir="z:\"


## firefox settings

My firefox.exe use settings that reduce save frequency

browser.sessionstore.interval=3600000
browser.cache.disk.enable=false

[chro...@googlecode.com]

Comment #91 on issue 52663 by DeathByN...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Good luck convincing the rulers to add an option. They hate those things
almost as much as they hate power users.

[chro...@googlecode.com]

Comment #92 on issue 52663 by impinball: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

And this is where I regret not really having the time nor experience with
C++ to do work on problem. It is easy to verify in my Ubuntu 13.10 64-bit
machine, even with a vanilla user idling. One thing that will help people
with the time: please post a log file here from about:net-internals (I
think, correct me if I'm wrong) along with your comment, first.

[chro...@googlecode.com]

Comment #93 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

impinball: the trace has a lot of activities, so after 10 min looking at it
I could not figure out which of those events actually access disk in a way
that concerns you. Can you attach strace (on linux) to the browser process
and find out what operations are performed? if files are open each time,
we're lucky, otherwise may require more tracing to find out what the
filenames for the current file descriptors are.

[chro...@googlecode.com]

Comment #94 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

impinball: figuring out which extensions / sites / renderers cause the
problem will help the investigation a lot.

Keep in mind that it's a relatively low priority issue, so you'd be very
welcome to do most of the investigations ;)

[chro...@googlecode.com]

Comment #95 on issue 52663 by ultimate.evil: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Honestly I gave up on Google to fix this problem, until they realize the
constant write pattern eats SSD NAND write's for breakfast lunch & dinner
the # of writes will never be controlled or fixed. Hopefully a ton of
their server's disks die so they get the hint since theres probably no
other way this "bug" will get addressed.

[chro...@googlecode.com]

Comment #96 on issue 52663 by txsan...@gmail.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Google don't use chromium browsers on their servers, so it won't happen :)

[chro...@googlecode.com]

Comment #97 on issue 52663 by impinball: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

pasko@, given the fact I only have one Linux PC to test on, it could be a
little hard. I do have one question, Linux-specific: would I be able to run
multiple channels simultaneously? I know different channels use different
names, but I don't know if they keep their respective settings separate
from each other (if not, it would be easy to work around that with symlinks
and small launcher script modifications at the top).

[chro...@googlecode.com]

Comment #98 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

impinball: why do you need multiple channels at once? AFAIR the linux
packages for each channel are mutually exclusive. The settings for each
channel are separate though. For instance, I sometimes switch between
stable/unstable channels, the profile directories for them are separate:
$HOME/.config/google-chrome
$HOME/.config/google-chrome-unstable

you can override the directory with a command-line flag: --user-data-dir=

[chro...@googlecode.com]

Comment #99 on issue 52663 by impinball: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

That was my question (whether Linux had mutually exclusive data/profile
directories for each channel), and you answered it. I wanted to be able to
test this in LKGR and stable (both vanilla) to make sure. I usually run
Beta, but with all that extension noise, I would prefer a vanilla profile
with Chrome stopped completely before I start. Even better is a channel I
don't normally use, which this is a case of.

[chro...@googlecode.com]

Comment #101 on issue 52663 by jaberwoc...@aol.com: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I'm noticing this issue for the first time. Laptop hard drive starts up and
stops every few seconds. CPU usage is at 100%, and physicla memeory usage
is in the high 90's (Though I'm used to this with physical memory, and I
normally have at least 100 tabs open at once, I've never noticed the hard
drive noises or the 100% CPU usage before.

I'd like to do what was asked and make a trace as explained here:
http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
but I don't see what use it would be since reading i you can only do it for
one tab at once.

In the windows task manager, out of the 85 chrome processes that are
running, at least 10 are using over 5 CPU at any given time, and at least 5
are using over ten. Again, I've never noticed high CPU usage or the hard
drives noises till this morning. Looking at I/O writes, again in the
windowes task manger, the values for I/O writes ranges from 4 million for
the highest, to 100 for the lowest.

Interestingly, I can end many of these chrome processes with noticeable
effect on chrome, but this does reduce the CPU and physical memory usage.

[chro...@googlecode.com]

Comment #102 on issue 52663 by johannes...@googlemail.com: frequent small
disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

well done google, this chrome kills my laptop.

i recommended chrome for 3 years, but now i will stop using it and also
recommend to NOT USE it any more.

maybe now is the time where the end of google begins.... just another too
big company which dont care about customers until they are all gone...

THANKS AGAIN FOR MESSING UP MY LAPTOP!!!

[chro...@googlecode.com]

Comment #103 on issue 52663 by johannes...@googlemail.com: frequent small
disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

so, i tested:
opera (22.0.1471.50), firefox (29.0.1) and chrome (Version 35.0.1916.114 m).

use case:
exact same 6 URLs open in 6 tabs in each browser.

the following disc read/writes seen after doing nothing in the browsers:
opera 0/0 after maybe 30 - 60 sec
firefox 0/10k sometimes (didnt wait long enought to say how often... but is
rather every minutes)
chrome 0/10k always

--> sadly but true, opera is my new choise until i hear that google has
fixed the chrome issue.

[chro...@googlecode.com]

Comment #106 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

hm, interesting, let's see if it opens/closes files for you.

try:
strace -pPID -e trace=file

where PID is the process id of the browser process, you can see it in the
browser task manager.

[chro...@googlecode.com]

Comment #107 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

if it does not open/close files, do this:

strace -pPID -e trace=open,close,read,write

and provide the output of this command:
ls -al /proc/PID/fd

(this will not cover memory-mapped I/O, but if we catch it on the level of
read/write/open/close, it would be nice)

[chro...@googlecode.com]

Comment #111 on issue 52663 by Andrey.P...@gmail.com: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I can see I/O events by chromium process in "iotop -o" and HDD red light is
flashing.

[chro...@googlecode.com]

Comment #115 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

cute, that's a wallet extension. I have no idea what it's doing. Did you
use google wallet? are you signed into chrome? How did you install chrome?

[chro...@googlecode.com]

Comment #116 on issue 52663 by johannes...@googlemail.com: frequent small
disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

hm, what is google wallet? never heard about it. if i am using it, i use it
without knowing that i am using it :)

[chro...@googlecode.com]

Comment #117 on issue 52663 by Andrey.P...@gmail.com: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Pasko, I don't use google wallet. Usually I am signed into chrome, but when
I did user-data-dir for your report I guess it didn't know anything and
acted like a new one.

I've installed Chromium from PPA "deb
http://ppa.launchpad.net/chromium-daily/stable/ubuntu precise main"

[chro...@googlecode.com]

Comment #118 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

re #117: so this is ubuntu/chromium, not chrome, good to know.

It seems that something happened with the extension (maybe it was
downloaded lazily, I'll need to find out how it works). To isolate the
effect, can you wait for an hour with chrome open and userdata in /tmp/u,
and then repeat the experiment in #114?

A few features are implemented as extensions in Chrome, and they are not
shown in chrome://extensions, but you can find them by appending the
extension hash to the CWS URL.

For example, in our case:
https://chrome.google.com/webstore/detail/nmmhkkegccagdldgiimedpiccmgmieda

[chro...@googlecode.com]

Updates:
Cc: est...@chromium.org
Labels: Cr-Platform-Extensions

Comment #119 on issue 52663 by ishe...@chromium.org: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Extensions folks, PTAL at comments 114-118. Also +cc Evan as an FYI
(though I don't think this is related to requestAutocomplete's Wallet
integration).

[chro...@googlecode.com]

Comment #121 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

re #120: oh cool, thanks, so extension thing is probably an
initialization-imposed red herring.

Now we can clearly see 6 calls to open(2) somewhere in the default profile,
yey! Can you repeat with strace of the browser process (-e
trace=open,close) for two minutes? I want to see the file names being open.
The inotify in the background would only make it better.

If attaching to browser process does not reveal anything, then please try
other chrome processes.

Chromites: can this be the GPU process?

[chro...@googlecode.com]

Comment #123 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

re #122: Sad.

What could happen is new process being forked briefly, doing open(), then
exiting. I am not sure which one this could be, seriously.

If you are adventurous, what you could do:

1. run Chrome with open() redefined via LD_PRELOAD, like here maybe:
http://www.tomaz.me/2014/01/08/detecting-which-process-is-creating-a-file-using-ld-preload-trick.html

(This should cover all forked processes automatically, except cases when a
process calls open directly via a syscall)

2. start chrome with logging enabled (--enable-logging --v=1), before idle
time begins, change permissions of the directory to make files unreadable
by the current user, look for relevant error messages when file access
fails.

[chro...@googlecode.com]

Updates:
Cc: rsl...@chromium.org

Comment #125 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I reproduced the Cookie sqlite error!

In debug mode the error is fatal:
[10869:10896:0612/191620:FATAL:sqlite_server_bound_cert_store.cc(521)]
Check failed: false. Could not add a server bound cert to the DB.
#1 0x7f32dcf09281 sql::Connection::OnSqliteError()
#2 0x7f32dcf12a27 sql::Statement::CheckError()
#3 0x7f32dcf117ee sql::Statement::Run()
#4 0x7f32d8f2860d SQLiteServerBoundCertStore::Backend::Commit()
#5 0x7f32d8f2ca14 base::internal::RunnableAdapter<>::Run()
#6 0x7f32d8f2c0e1 base::internal::InvokeHelper<>::MakeItSo()
#7 0x7f32d8f2b6b9 base::internal::Invoker<>::Run()
#8 0x7f32d8577be3 base::Callback<>::Run()
#9 0x7f32d9819fa3 base::SequencedWorkerPool::Inner::ThreadLoop()
#10 0x7f32d981882b base::SequencedWorkerPool::Worker::Run()
#11 0x7f32d9821718 base::SimpleThread::ThreadMain()

Ryan, what is the intentional behavior? It is OK to refresh bound certs
every minute and write them to disk? I could spot only the initial bound
cert write here, not sure.

[chro...@googlecode.com]

Comment #129 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

@rsleevi:

This indeed is a different error, which should be ignored when looking for
the cause of disk accesses every minute. Thanks!

@shess:

While a readonly profile is an interesting case, the DB retries are
irrelevant here: we are detecting the very first disk access that happens
in idle time. Unfortunately, even 30 seconds is not enough to make chrome
go idle (component updater activity, bound certs, ..). How much do we wait
before we are supposed to get idle? That's a very interesting question.

[chro...@googlecode.com]

Comment #130 on issue 52663 by Andrey.P...@gmail.com: frequent small disk
I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I have no intention to make extra noise, but I repeated experiment with
copy of my real config and two tabs opened (google.com, kernel.org). I kept
the browser opened for a couple of minutes, then did chmod -R 0555. And I
got the same errors again.

---cut---
[7736:7769:0613/191230:ERROR:connection.cc(1060)] Cookie sqlite error 778,
errno 0: disk I/O error, sql: UPDATE cookies SET last_access_utc=? WHERE
creation_utc=?
[7736:7769:0613/191230:ERROR:connection.cc(1060)] Cookie sqlite error 1,
errno 0: SQL logic error or missing database, sql: COMMIT
---cut---

I guess the problem is chromium tries to update cookies and commit to
sqlite without any reason.

[chro...@googlecode.com]

Comment #131 on issue 52663 by sh...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

You verified that neither site sent down new cookies?

[chro...@googlecode.com]

Updates:
Status: Assigned
Owner: pa...@chromium.org

Comment #133 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

re #132:

you probably start chrome from a readonly profile. That's not what we want
to see, we should make the profile idle after some time of inactivity. Like
this:

chmod -R a+w /tmp/n ; rm -rf /tmp/n && out_linux/Debug/chrome
--user-data-dir=/tmp/n --enable-logging --v=1 & sleep 120 && chmod -R a-w
/tmp/n

I instrumented Connection::OnSqliteError() to print a backtrace and caught
the cookie store problem with the command above:
[23529:23547:0613/201303:ERROR:connection.cc(1061)] Cookie sqlite error

778, errno 0: disk I/O error, sql: UPDATE cookies SET last_access_utc=?
WHERE creation_utc=?

[23529:23547:0613/201304:INFO:connection.cc(1065)] #0 0x7f19b645249d
base::debug::StackTrace::StackTrace()
#1 0x7f19b9c21201 sql::Connection::OnSqliteError()
#2 0x7f19b9c2a9a7 sql::Statement::CheckError()
#3 0x7f19b9c2976e sql::Statement::Run()
#4 0x7f19b9eecb49 content::SQLitePersistentCookieStore::Backend::Commit()
#5 0x7f19b9ef4a48 base::internal::RunnableAdapter<>::Run()
#6 0x7f19b9ef3a44 base::internal::InvokeHelper<>::MakeItSo()
#7 0x7f19b9ef27d3 base::internal::Invoker<>::Run()
#8 0x7f19b528fbe3 base::Callback<>::Run()
#9 0x7f19b6531f23 base::SequencedWorkerPool::Inner::ThreadLoop()
#10 0x7f19b65307ab base::SequencedWorkerPool::Worker::Run()
#11 0x7f19b6539698 base::SimpleThread::ThreadMain()
#12 0x7f19b652efa5 base::(anonymous namespace)::ThreadFunc()
#13 0x7f19afec3e9a start_thread
#14 0x7f19ae0783fd clone

I can increase the sleep from 120s to something significantly bigger, but I
think there is evidence of something unexpected happening already. I'll
take a closer look if nobody has an immediate idea of a possible
explanation.

[chro...@googlecode.com]

Comment #134 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I wrote:
> we should make the profile idle after some time of inactivity

I meant:
> we should make the profile *readonly* after some time of inactivity

[chro...@googlecode.com]

Updates:
Cc: -rsl...@chromium.org

Comment #135 on issue 52663 by rsl...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #136 on issue 52663 by sh...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

When I run a build of Chromium from a repo sync'ed this morning, on OSX,
with a real profile, I don't see any calls to
SQLitePersistentCookieStore::Backend::Commit() at all until I quit and it
flushes itself. When I run a build of Chromium with an empty profile and
load www.google.com and www.kernel.org, I get a call about 30s after
startup. There are no updates at all after that until shutdown. I left it
running for around 20 minutes.

I cannot emphasize enough that if you're going to change the attributes of
core storage while Chrome is running, you are into undefined territory
where lots of things can happen which really aren't actionable. You need
to be really careful that you are actually replicating the circumstances of
the bug, rather than generating a bunch of red herrings.

In this case you are artificially forcing failures, and I don't think that
retrying on failure is all that strange. Since you're making the entire
profile read-only, it's not even clear what the subsystem could do to
attempt to address the failure.

[chro...@googlecode.com]

Comment #137 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

I understand that making the profile readonly changes the behavior. Let me
say it again, the very first access to disk is considered a bug here if
it's happening after a few minutes of inactivity. It is really *not*
important what's happening after this first access, I ignore it.

And here we have the first "red herring". I dumped the cookies that were
flushed, and I am seeing APPENDACCESS operations on the google analytics
cookies (__utma, __utmb, __utmc, __utmz) from
https://www.google.com/intl/en/chrome/browser/welcome.html (The Getting
Started page)
Apparently if you start with an empty profile you have a background tab
open with /intl/en/chrome/browser/

If I close the "Getting Started" page when it loads, and stay only on the
New Tab Page, the cookie problem is not reproducible.

I think we should *not* flush APPENDACCESS cookie operations every 30s when
a page with analytics is open (as we currently do). But there are other
idle disk access problems like long-standing XHR, we should decide who is
responsible and what recommendations should be to web devs to avoid wasting
battery / killing the disk.

One more observation: almost immediately after the directory gets
protected, a few warnings pop out like:
Histogram: PerformanceMonitor.AverageCPU.BrowserProcess has bad minimum: 0
Histogram: PerformanceMonitor.AverageCPU.GPUProcess has bad minimum: 0
Histogram: PerformanceMonitor.AverageCPU.RendererProcess has bad minimum: 0

This suggests that we may be using a memory-mapped file for histograms, but
it needs more investigation.

[chro...@googlecode.com]

Comment #138 on issue 52663 by pa...@chromium.org: frequent small disk I/O
http://code.google.com/p/chromium/issues/detail?id=52663

Andrey.Perliev, do you see anything beyond those cookies if you close the
getting started page early?