# reducing write load for SSD main drive...

## Oo.et.oO

there are some tips here:

http://en.gentoo-wiki.com/wiki/Solid_State_Disk

and they are good ones.  i've moved my portage tree into network storage, and my portage tmpdir as well as /tmp in to tmpfs.

but conky still shows pretty consistent disk writes (main drive is still a classical rotating drive while i try to figure this out).

i posted some other things we should be looking into on the discussion page for that wiki page:

http://en.gentoo-wiki.com/wiki/Talk:Solid_State_Disk

i've used lsof to try to see what/where these writes are coming from:

```
#> lsof /dev/sda3 | awk '$4 ~ /(FD|[wWuU]$)/'

COMMAND     PID  USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME

metalog    1859       root    8w   REG    8,3   351408  131077 /var/log/everything/current

atd        1901         at    3uW  REG    8,3        5  132674 /var/run/atd.pid

mysqld     1907      mysql    1w   REG    8,3     2927  132667 /var/log/mysql/mysqld.err

[... tons of mysql files open for write]

cron       1934       root    3u   REG    8,3        5  132931 /var/run/cron.pid

cupsd      1996       root    5u   REG    8,3      248  133499 /var/log/cups/error_log

smbd       2056       root    2w   REG    8,3     2310  939835 /var/log/samba/log.smbd

[... tons of samba files open for write]

apache2    2139       root    2w   REG    8,3      322  132634 /var/log/apache2/error_log

[... tons of apache files open for write]

console-k  2233       root    9w   REG    8,3     7738  154537 /var/log/ConsoleKit/history

qmgr      12947    postfix    6u  FIFO    8,3      0t0  133475 /var/spool/postfix/public/qmgr

usbmuxd   16340     usbmux    3wW  REG    8,3        5  156212 /var/run/usbmuxd.pid

pickup    16857    postfix    6u  FIFO    8,3      0t0  133473 /var/spool/postfix/public/pickup

X         26628       root    0w   REG    8,3    28575  132678 /var/log/Xorg.0.log

```

```
#> lsof /dev/sda4 | awk '$4 ~ /(FD|[wWuU]$)/'

COMMAND     PID  USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME

firefox-b  9570 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

[... tons of these]

firefox-b  9570 erict    3u   REG    8,4    65536  9968258 /home/erict/.mozilla/firefox/uonbzh0q.default/search.sqlite

firefox-b  9570 erict   16wW  REG    8,4        0  9968246 /home/erict/.mozilla/firefox/uonbzh0q.default/.parentlock

firefox-b  9570 erict   44u   REG    8,4    65536  9968265 /home/erict/.mozilla/firefox/uonbzh0q.default/cert8.db

firefox-b  9570 erict   45u   REG    8,4    16384  9968267 /home/erict/.mozilla/firefox/uonbzh0q.default/key3.db

plugin-co  9619 erict    2w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

npviewer.  9640 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

pulseaudi 17238 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

sh        26686 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

gnome-ter 26742 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

pidgin    26748 erict    2w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

xscreensa 26749 erict    6w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

deluge    26750 erict    2w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors

fbpager   26752 erict    1w   REG    8,4    30573  8655817 /home/erict/.fluxbox-errors
```

any ideas on how to see how often each of these are actively writing?  i'm thinking i can use a few "find -mtime" on each of the above files, to see how recently they've written and compare across time.

i can probably move the logs to network storage, and perhaps the best way to prevent logging of errors from XSESSION (those .fluxbox-errors files) is to fix the errors   :Laughing: 

other ideas?   the above seems like a much higher write load than even the portage tree (which i sync once a week)

----------

## Hu

You could use iotop to see which processes are writing.  You may need to enable some additional kernel options first.

----------

## causality

On a desktop system that isn't a server, /var, /usr/portage, and /home are where most of your day-to-day disk activity takes place.

I do not have an SSD but I enjoy having /var and /usr/portage on separate disks.  Along with multi-core processors it means I can put a big emerge update in the background, forget all about it, and never notice a slowdown.  If my goal were to minimize disk writes, I'd also place /home on a mechanical drive and reserve the SSD for system software.

You very well may have lots of success using iotop and lsof and other tools to monitor disk usage until you pin it down to a few major locations.  This is the inductive method.  The problem is, you'll soon discover that a working Linux system has tons of files to examine and no clear indication of where to start.

It might be easier to use the deductive method, to start with the general principles of how the filesystem is laid out and why, what the top-level directories are intended for, and then take care of the few exceptions to the rule.  A reference that isn't gentoo-specific can be found here: http://www.pathname.com/fhs/pub/fhs-2.3.html

----------

## Oo.et.oO

 *causality wrote:*   

> On a desktop system that isn't a server, /var, /usr/portage, and /home are where most of your day-to-day disk activity takes place.
> 
> [...] If my goal were to minimize disk writes, I'd also place /home on a mechanical drive and reserve the SSD for system software.
> 
> 

 

that's limiting the effectiveness of the SSD on the system.  eg i WANT the files i work on as a human to be on the SSD so they open quickly along with the lumbering software i'm using.  the challenge in this case (or the very real case where the machine ONLY has an SSD) is to find what other processes are writing rapidly or possibly redundantly to the SSD areas and possibly moving the written file locations to network storage and/or tmpfs.  On my system these all seem to be logging and/or file/database summaries (located, beagled), or application history (pidgin logging, firefox history).

 *causality wrote:*   

> 
> 
> You very well may have lots of success using iotop and lsof and other tools to monitor disk usage until you pin it down to a few major locations.  This is the inductive method.  The problem is, you'll soon discover that a working Linux system has tons of files to examine and no clear indication of where to start.
> 
> 

 

that's the very point of this exercise.  lsof leads to files and repeatedly checking their write times is a pretty easy place to start.  

thanks for the link.  i've had to back-burner my progress on this and for now i'm stuck with this magnetic drive.  

i'll try out some other options when i re-visit next week.

----------

