lm-profiler SSD and flush problem

[kinders]

Hey guys, I got some kind of problem here.

After purchasing new 64Gb Kingston SSD drive I am trying to minimize write disk activity.
Inspired by http://www.gentoo.org/doc/en/power-management-guide.xml guide, I got:

localhost linux # lm-profiler
Profiling run started.
Write accesses at 3/600 in lm-profiler run: flush-8:0
Write accesses at 8/600 in lm-profiler run: flush-8:0
Write accesses at 13/600 in lm-profiler run: flush-8:0
Write accesses at 28/600 in lm-profiler run: flush-8:0
Write accesses at 33/600 in lm-profiler run: flush-8:0
Write accesses at 42/600 in lm-profiler run: flush-8:0
Write accesses at 47/600 in lm-profiler run: flush-8:0
Write accesses at 62/600 in lm-profiler run: flush-8:0

As you can see lm-profiler every ~5 seconds flushes something, but I don't know why and how to stop it.
There is no other activity, nothing writes to disk, but flush is active, why ?

SYSTEM: amd64, ACCEPT_KEYWORDS="~amd64", 2.6.32-gentoo kernel, elevator=noop kernel option

[smlgbl]

Same thing here. Any news?
_________________
samuel.
'Do not let one girding on boast about himself like one unfastening'

[dman777]

I haven't got a chance to try this on my ssd yet or investigate but here's a link that may help:

http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment

[dman777]

did anyone find out how to stop the flush by lm-profiler even when there is no activity?

[zeroth]

same here. really want to figure this out

[Seron]

I found that you can set the interval with LM_SECONDS_BEFORE_SYNC in /etc/laptop-mode/laptop-mode.conf. There's some info in the laptop-mode.conf man page.
_________________
man cannot be brave without being afraid

[Shining Arcanine]

That is the ext3 commit interval, which is by default set to 5 seconds:

http://lmgtfy.com/?q=ext3+commit+interval

Anything it writes is information that programs wrote to the disk (e.g. your text editor). If the write buffer is not flushed, then it is probable that you will experience data loss, ranging from minor loss (e.g. the important document you spent 5 hours writing in Open Office Writer was never saved to your disk) to catastrophic data loss (e.g. you installed updates to critical system components and part of the changes were never saved to the disk, rendering your system useless).

You can change the interval to be a minute or even an hour, but doing that will not prolong the life of your SSD because the same amount of data will be written and should less data be written as a consequence, having done that will more than likely decrease the lifespan of your SSD because of the re-installation you would need to do when core system files have become irreversibly corrupted.

I suggest that you look elsewhere for things to try to disable, because this is definitely not one of them.

[tnt]

[Shining Arcanine]

[tnt]

well, this is the graph of past week showing writes to my ext4 fs (yellow) and host writes to my x25-v (red).

http://img241.imageshack.us/img241/9784/systemg29week.png

commit=100 did the difference as my fs writes started to grow more quickly then host writes.
_________________
gentoo user

[Shining Arcanine]

[tnt]

I'm monitoring
/sys/fs/ext4/sda1/lifetime_write_kbytes
because sda1 is the one and only partition on my SSD
and
smartctl -A /dev/sda|gawk '{if ($1==225) print($10)}'
(multipling with 32MB)
because it represents all writes SSD host has seen in it's lifetime

comparation of those two values and tendency of growth can show efficiency of buffering:
if filesystem sees more writes then host itself, it means you've managed to save a little bit of wearing.

I wanted to show this as an example of real-life success avoiding further theory on buffering and SSD writing.
_________________
gentoo user

[Shining Arcanine]

If I am interpreting this correctly, moving to commit=100 actually increased the number of writes done to your SSD, because I assume that the jump I observe in the graph between 22 and 23 on that graph, is because you moved to commit=100, which is something that I would not expect to see. As for whether or not this decreased the rate at which writes were done, you would need to calculate the slope of that graph at every point your data set.

[tnt]

you interpreted it wrong, and it's my fault I didn't explain it better:

commit=100 is set long time ago.
it made difference between filesystem writes and SSD writes so big (209GB vs. 138GB).
that means, so far I've saved about 71GB of writes.
it took me about two months, but I'm glad to see that only 2/3 of fs writes ends on SSD.
_________________
gentoo user

[Seron]

I don't have SSD or ext3 but a HDD and ReiserFS. Perhaps ReiserFS has a commit interval works in a similar fashion.

I looked at laptop_mode because I was trying to lower disk access frequency. This disk is used in a laptop that acts as a server.

I observed that in my case flush frequency displayed by lm-profiler was related to LM_SECONDS_BEFORE_SYNC. My disk spins down a few seconds (~5 s.) after access, so the flush is audible if spindown is performed before a flush. I noticed that the HDD wouldn't make flush interval noises unless lm-profiler was running, so it seems to me that flush was actually caused by lm-profiler, which seems kind of odd.
_________________
man cannot be brave without being afraid

[kinders]

Hello.
I have found my reason for flush'es.
Lm-profiler actually is not good enough tool for searching reading/writing applications, in kernel documentation I have found accurate method:

1) stop syslog daemon: /etc/init.d/syslog-ng stop
2) echo "1" >/proc/sys/vm/block_dump

Now every read/write event will be shown in dmesg. But there are only inodes, not filenames. To find corresponding file:
find / -inum 1234567 -exec echo {} \;
1234567 - inode number.

Using this method I have found application responsible for writing activity.

3) echo "0" >/proc/sys/vm/block_dump
4) start syslog daemon if you need