+ scottmg@ for further inputs here.

Thank you!

Can confirm this started happen when I went from version 56 to 57.
It happens often. Don't know the trigger but it's happened 3 times today!!!!

Can't use chrome when it does this to my hard drive constantly. SSD users will be major pissed above chromes already constant reads and writes when browser is not used.

I'm currently capturing another log with process monitor. Looks identical to the first one.

@ labobolink : Could you please provide us any sample test steps of the issue to triage the issue from test team end.

Thank You!

Once it started when I closed a tab and opened another one to a site.

Just today it happened when I tried to open the history (chrome://history/)
The history page came up but not the any history. Only hard drive grind.

I'm not sure but in both cases there might have been little free ram left.

So I assume you don't want what I've captured with process monitor?

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding respective Components to further triaging it.

Anyone else noticed this? I haven't tried to compare 56 to 57 yet.

(Seems sort of unlikely that it's Windows-specific, but maybe other OSs coalesce writes more.)

5 KB is an odd size for an I/O block. I looked through the entire Chrome code but couldn't find anything similar to 5120 or 5 * 1024. 

labobolink@gmail.com, what did you use to see disk writes and how did you determine the size? Are there any logs or traces that show these disk writes that you could share?

From the description it sounds like it could be History DB writes. History sqlite DB has 4096 byte page size. Another possibility is those writes are triggered by Sync DB although Sync tends to write in very small incremental changes and Sync DB page size is 32K.

Noticed I can replicate this bug.
1. Start chrome
2. Menu->Settings

And the hard disk grind begins reading and writing small chunks of data to the History file, overloading the hard drive in the process.

@9: If you read the bug report you'll see this:
"Recorded it with Process Monitor."

">>>>I'd like to send you what Process Monitor captured but I'd like it to be private.<<<<< File is around 5 mb when compressed with 7-zip."

Later comment hinted at it again:
"So I assume you don't want what I've captured with process monitor?"

Shouldn't committers be able to read bug reports properly? This have happened before, noticing a pattern here. Perhaps rules for becoming a committer should be updated to include English comprehension tests.

To the questions:
Captured with process monitor. Filtered to only include Chrome process, saved and compressed. Ready for sending _Privately_. Have not found any check box for making file uploads to crbug as private as in google's chrome dev team only, as in no volunteers.

Now that I can replicate the bug. I can capture from beginning to end.

> what did you use to see disk writes and how did you determine the size?

Both Windows Explorer and process monitor to check the history-journal file. See screenshot.

> From the description it sounds like it could be History DB writes. 

"It went nuts writing 5 kb pieces to >>>>history<<<<<< for several seconds."
Was that not clear seeing that I used process monitor to track it down?

The screenshot includes the relevant of what it's doing (filtered down to ReadFile and WriteFile operations). The saved capture files includes everything.

Slightly off topic:
Why isn't the pdb files available for downloading? Would enable people to make better and more precise bug reports. Would even enable people to suggest a fix. At least I would. That's how I started committing patches to several open source projects. Chrome really need more committers.

Deleted: pm filter ReadFile WriteFile.png 304 KB

	pm filter ReadFile WriteFile.png 304 KB View Download

If you could share the process monitor file with me at brucedawson@chromium.org (email should work fine) that would be very helpful. Apologies for not noticing your earlier offer.

> Shouldn't committers be able to read bug reports properly?

Yes, we should. On the other hand, there are many bugs and it is easy to miss details, especially when nobody has been assigned to the bug. Be careful of tone.

> Why isn't the pdb files available for downloading?

PDBs for Chrome on Windows are available. There are instructions on how to configure tools to use Chrome's symbol server here:

https://www.chromium.org/developers/how-tos/debugging-on-windows

If you debug using Visual Studio or windbg then you can even configure them to download the PDBs and then use information in the PDBs to download the relevant source files on-demand. Process Monitor should also be able to be configured to automatically download the correct PDBs from the symbol server. If you're not familiar with symbol servers and source indexing I can share further instructions.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot