Am Samstag, 14. Mai 2011 schrieb Stan Hoeppner: > On 5/14/2011 11:02 AM, Rainer Dorsch wrote: > > Am Freitag, 13. Mai 2011 schrieb Miles Fidelman: > >> Stan Hoeppner wrote: > >>> On 5/12/2011 5:19 AM, Rainer Dorsch wrote: > >>>> Sometimes though something is accessing data on the disk drives, > >>>> which I do > >>>> not understand. > >>> > >>> Did you relocate swap to the SSD? > >> > >> What do you have under root vs. your hard drives. There's lots of stuff > >> going on all the time - network activity, mail spools, cron jobs, > >> logging. > > > > To answer a few questions: > > > > - I did not relocate swap to SSD, but reduce swapiness: > > echo 20 > /proc/sys/vm/swappiness > > I have 4 GB or RAM, in most cases that is more than plenty for me. As > > long as top shows 0 swap in use, I would think I am safe. > > Safe for now. > > > My Main reason for not doing it was that I do run the SSD partitionless > > to avoid partition alignment issues. > > There are no partition alignment issues with SSDs. SSDs have no I can report differently: I see between 5% and 100% better dd write performance when running partitionless compared to my original (50GB/70GB) partioning: blackbox:~# fdisk -ul /dev/sdc Disk /dev/sdc: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 * 63 97659134 48829536 83 Linux /dev/sdc2 97659135 234436544 68388705 83 Linux blackbox:~# (that is what cfdisk created without taking any special care). For small write blocks the performance improvement is higher. Here is a lengthy blog from Ted Tso on that topic (be warned, it was not an easy read for me): http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd’s-erase- block-size > cylinders, no heads, no mechanical parts. Native sector size is 512B, > access time to every sector on the device is uniform--non issue. SSD > random read/write access is 10,000x faster than your HDDs so make a > small swap file on the SSD--you don't need a partition for swap, use a > file. It's brain dead simple. Make a 128MB swap file just so you have > some swap to keep the kernel happy. BTW, it is possible to run totally > without swap. You just might see some unintended consequences doing so. > With 4GB RAM on a workstation it's unlikely though. Anyway, to > deactivate and remove the current swap partition, and make a small 128MB > swap file on your SSD and activate it: > > # swappoff -a > # dd if=/dev/zero of=/swapfile1 bs=1024 count=131072 > # mkswap /swapfile1 > # swapon /swapfile1 > # vi /etc/fstab > Add: > /swapfile1 swap swap defaults 0 0 > > and remove the old swap entry. On reboot only new swap file is used. > Linux has had swap file capability for many years, introduced in 2.6. > > The kernel keeps track of the on disk location of swap files and > bypasses the filesystem and buffer cache, performing direct disk access. > With modern hardware, whether SSD or hard disk, there is no performance > difference between a swap file or partition. Using swap files simply > gives you more flexibility--you can add or remove swap anywhere, any > time, without needing to dedicate partitions to swap. Thank you for the detailed instructions. The biggest pain of having swap for me is that the harddist needs to start during shutdown and I think during startup it tries to resume from this partition. I thought of putting the swap partition on an USB stick (almost never used in my system and it should be faster than starting a disk during shutdown). > > - I moved everything on the SSD except some folders in /opt and /home > > Why haven't you moved those over? The SSD is too small to put everything on it (e.g. photo/video collection). > > - The inotifywait works nicely :-) > > So tell us what is accessing the disks already. Lemme guess, some cron > job firing a binary in /opt. I still need to track that down in detail, once I saw backup running. My biggest suspect right now is nepomuk, I will report when I can confirm it. Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdorsch@web.de jabber: rdorsch@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/
Attachment:
signature.asc
Description: This is a digitally signed message part.