aptosid.com

Anything Goes - SSD configuration

finotti - 17.03.2011, 20:08
Post subject: SSD configuration
Dear all,

I've just ordered a SSD for my Thinkpad T510. It's a 128GB Crucial. (This one: http://www.newegg.com/Product/Product.aspx?Item=N82E16820148348.)

I will start doing my research now for best file system and configuration. If anyone has already done similar research and is willing to share his/her experience and point of view, I'd greatly appreciate. (Of course, I will install aptosid in it.)

Best to all,

Luis
slh - 17.03.2011, 20:36
Post subject: RE: SSD configuration
SSDs shouldn't need any special configuration, even aligning the partitions to the erase block size (recommended, especially for older SSDs - but this is the same story for modern HDDs with 4 KB block size) is losing importance for current SSD generations.
finotti - 17.03.2011, 20:49
Post subject: Re: RE: SSD configuration
Thanks, slh for the response!

      slh wrote:
SSDs shouldn't need any special configuration, even aligning the partitions to the erase block size (recommended, especially for older SSDs - but this is the same story for modern HDDs with 4 KB block size) is losing importance for current SSD generations.


That was exactly one of the things I heard being mentioned. So, can I just use aptosid's partitioner with default parameters? Ext4 FS?

No swap, though, correct?

Thanks again,

Luis
devil - 17.03.2011, 20:52
Post subject: RE: SSD configuration
i also ordered a SSD (it will hit the shops next week) it is a OCZ Vertex 3 128 GB.
i cant share any experiences with it, but maybe i can make you rethink your choice (if still possible)

the difference between mine and yours is the controller. yours is Marvell, mine is SandForce 22xx series. there is quite some difference in transfer rates. the SandForce controller enbables the OCZ Vertex 3 to shove more than 500 MB/s read and write. it costs maybe 50 $ more (it would in DE).

anandtech reviewed it at: http://www.anandtech.com/show/4186/ocz- ... sed-sf2200

performance graphs of Crucical and OCZ on http://www.anandtech.com/show/4186/ocz- ... d-sf2200/3 ff. speaks for itself.

SandForce controllers cant be beat at the moment, and on top of that OCZ squeezes another ~ 30 MB/s out of the firmware.
so, at the moment, Vertex 3 is hard to beat in the consumer market.

edit: all this is only relevant for you if your TP sports a Sata 6 GB link. if not, ayou are probably even spending too much.
edit2: just checked: Main drive bay in TP T510 is SATA 3.0Gbps, the graphs in the review also compare those.

greetz
devil
slh - 17.03.2011, 20:59
Post subject: RE: Re: RE: SSD configuration
Unfortunately all partitioning programs are still lagging behind (and lacking) in regards to "ideal" alignment, because erase block sizes can't be queried in a generic way (especially as everything is already "lost", if windows started with a 'wrong' alignment) - and especially modern HDDs lie about their block size to retain compatibility with old window versions. However fortunately perfect alignment is losing importance with modern devices.

Regarding swap, you've always lost, if you actually need to use it - but swap is still important for suspend to disk and as emergency fallback in case you really temporarily run out of RAM... For modern SSDs, swap and its rewrite count shouldn't be a problem.



Disclaimer: I don't have any personal hands-on experiences with SSDs yet.
cid-baba - 17.03.2011, 21:29
Post subject: RE: Re: RE: SSD configuration
i've got a ssd (intel 80gb, bit older) - ext4 works perfectly. swap on the ssd is a good idea - if you get out of ram, the faster the drive, the faster you'll work Wink

if you're not a video-cutter or something like that you will seldom have to swap, so the rewritecount won't matter. (i've seen calculations, that even first generation ssds would run more than 3 jears if you write 10gb on them daily(!). rewritecount really doesn't matter for desktop users Wink )
dibl - 17.03.2011, 22:42
Post subject:
I have aptosid installed and running very successfully on 3 SSDs:

- EEE PC 701/4G (ouranos) (wife's netbook) -- the SSD is formatted ext2, and running the original slh 2.6.32 kernel for EEE PCs

- Toshiba NB205 netbook (keres) -- this has an OCZ Vertex 2, 40GB SSD. aptosid keres is in a 4.5GB ext4 partition.

- Desktop rig (apate) -- Asus P6X58D-E motherboard, Intel i7 950 CPU, 6GB memory, and an OCZ RevoDrive 120GB PCI bus SSD.

To partition the Vertex 2 and the RevoDrive, I used fdisk and set heads=32, sectors=32, and then aligned to 512K erase blocks, according to this guide:

http://www.ocztechnologyforum.com/forum ... post373226

I am not knowlegeable enough on the SSD controller designs to know whether it is important to let the journals run in tmp filesystems, so I did set them up that way, to be cautious. I saw slh's comment several weeks ago about "1 million erase cycles" -- it certainly may not be necessary to change the /var and ext4 defaults. Regardless, aptosid is performing very well on these SSDs. I will be happy to share the /etc/fstab and /etc/sysctl.conf configuration settings if anyone is interested.
devil - 17.03.2011, 23:02
Post subject:
      Quote:

nd an OCZ RevoDrive 120GB PCI bus SSD.

thats a hot one Smile

greetz
devil
dibl - 17.03.2011, 23:07
Post subject:
Grub menu to KDE greeter = 11 seconds. Very Happy
devil - 17.03.2011, 23:37
Post subject:
i will let you know what the Vertex 3 can do, once i get it. (hopefuly next week, all other parts are waiting already for a new box)

greetz
devil
DeepDayze - 18.03.2011, 01:13
Post subject: Re: RE: SSD configuration
      slh wrote:
SSDs shouldn't need any special configuration, even aligning the partitions to the erase block size (recommended, especially for older SSDs - but this is the same story for modern HDDs with 4 KB block size) is losing importance for current SSD generations.


So you are saying that the current partitioning tools are safe to use on the more recent SSD's in the same way as used on traditional HDD's?

      cid-baba wrote:
i've got a ssd (intel 80gb, bit older) - ext4 works perfectly. swap on the ssd is a good idea - if you get out of ram, the faster the drive, the faster you'll work Wink

if you're not a video-cutter or something like that you will seldom have to swap, so the rewritecount won't matter. (i've seen calculations, that even first generation ssds would run more than 3 jears if you write 10gb on them daily(!). rewritecount really doesn't matter for desktop users Wink )


That's about what the average conventional HDD lasts nowadays with heavy usage, but SSD reliability is improving so someday they'll last far longer than regular HDD's
se7en - 18.03.2011, 01:15
Post subject:
Found that article yesterday.
http://www.linux-mag.com/id/8397/?utm_s ... Stories%29
DeepDayze - 18.03.2011, 01:24
Post subject:
      se7en wrote:
Found that article yesterday.
http://www.linux-mag.com/id/8397/?utm_s ... Stories%29


An interesting article, bookmarked for reference. It's a good idea to get some of the specs for the SSD you want to purchase so you can decide if it will meet your needs with respect to partitioning and usage
clivesay - 18.03.2011, 03:28
Post subject:
I have a crucial 64gb SSD running aptosid. It is consistently at 7.8 seconds from grub boot to login. I recently upgraded this machine to a hex core with 16gb ram (yes this is my workhorse and the components were part of a great sale). I keep my OS on the SSD and all my file storage on a separate drive. I am really happy with performance and stability.

Chris
finotti - 18.03.2011, 08:35
Post subject: Re: RE: SSD configuration
Thanks devil and all for the replies and insight!

      devil wrote:
i also ordered a SSD (it will hit the shops next week) it is a OCZ Vertex 3 128 GB.
i cant share any experiences with it, but maybe i can make you rethink your choice (if still possible)


It seems that they will still take a while to get to the US. The only
place I've found was Amazon, but it says "ships in 1 or 2 months".

      Quote:

anandtech reviewed it at: http://www.anandtech.com/show/4186/ocz- ... sed-sf2200

performance graphs of Crucical and OCZ on http://www.anandtech.com/show/4186/ocz- ... d-sf2200/3 ff. speaks for itself.


Thanks for the informative article.

      Quote:

edit: all this is only relevant for you if your TP sports a
Sata 6 GB link. if not, ayou are probably even spending too much.
edit2: just checked: Main drive bay in TP T510 is SATA 3.0Gbps, the graphs in the review also compare those.


Thanks for looking it up! So, I gather that the Crucial should be
fine for me...

The graphs surprise me a bit, though. If the Crucial is too fast to
3Gbps, how come it seems that other drives in 3Gbps are faster? (I'm
assuming the if there is no mention of 6Gbps, the test was made with a
3Gbps SATA controller... Am I wrong?)

Thanks again,

Luis
devil - 18.03.2011, 10:49
Post subject: RE: Re: RE: SSD configuration
if there is no mention of 6 Gbps, my guess is, the drive is not suited for it.
speed is all in the controllers, and as i said, SandForce 2xxx is the best controller on the market right now.
for 3 Gbps a SandForce 1xxx should be sufficient. that would have to be verified though by looking at real numbers.

greetz
devil
finotti - 28.03.2011, 12:13
Post subject:
OK, I've got my new SSD and installed it this weekend. I haven't used my laptop much yet, but it seems really quick now. (Grub to KDM in about 13 seconds.)

FYI, I've used this tutorial:

https://wiki.archlinux.org/index.php/Solid_State_Drives

I cannot vouch for how accurate it is, but it matched things I've seen in other sites and was pretty complete. In particular, I've used gdisk to partition the SSD. (I did not follow the tips to minimize I/O writting, though.)

I did not put the "discard" option in fstab, though, as it seemed not be very stable, according to the wiki. Does any one have experience with that?

Thanks to all,

Luis
IgnorantGuru - 03.04.2011, 14:24
Post subject:
I've been using a OCZSSD2-1VTX30G for two years. I found that some of the changes I made for the ssd also made for a faster system in general.

Add commit=240 to fstab (this delays writing of data to the drive for up to 4 minutes, which could cause loss of data, but my system is stable and its never been a problem):
      Code:
/dev/sda1 /       ext3 noatime,errors=remount-ro,commit=240  0 1


Add to bottom of /etc/sysctl.conf:
      Code:
# reduce disk activity to 240 seconds
vm.dirty_ratio = 40
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 24000


Add to rc.local:
      Code:
# Set sda to use deadline scheduler
echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch


After reboot check:
      Code:
cat /proc/mounts | grep commit
cat /proc/sys/vm/dirty_ratio
cat /proc/sys/vm/dirty_background_ratio
cat /proc/sys/vm/dirty_writeback_centisecs
cat /sys/block/sda/queue/scheduler
cat /sys/block/sdb/queue/scheduler
cat /sys/block/sda/queue/iosched/fifo_batch


And I mount some system folders to a ramdrive (also good for speed) in fstab:
      Code:
# For SSD:
tmpfs /var/log tmpfs defaults,noatime,size=200M,mode=0755 0 0
tmpfs /tmp tmpfs defaults,noatime,size=1000M,mode=1777 0 0


Those sizes may need to be adjusted for your purposes, but they work well for me. Also, I turn off swap.

I also setup a folder in /dev/shm for firefox (in rc.local or elsewhere), and in Firefox's about:config change:
browser.cache.disk.parent_directory = /dev/shm/firefox

If you use amule or deluge, or similar, it's good to move their home folders to a conventional hard drive if possible, as they write frequently.

It's good to check what other files may be written frequently. To see files changed in the last 3 minutes:
      Code:
find / -xdev -cmin -3


If your home folder is on another partition, check that too:
      Code:
find /home -xdev -cmin -3


Maybe not all of that is necessary with newer SSDs (I'm not up on the latest), but it doesn't hurt, makes the drive work faster for more years, and makes the system nice and fast. My drive is still working after 2 years of continuous operation, so that's a good sign.
dibl - 04.04.2011, 12:42
Post subject:
I have done a similar setup of /etc/fstab and /etc/sysctl.conf on my SSDs, and they are working well -- the EEE PC 4G/701 is running 2009-01 "ouranos" still.

However, here is one question for you:

      IgnorantGuru wrote:


Add commit=240 to fstab (this delays writing of data to the drive for up to 4 minutes, which could cause loss of data, but my system is stable and its never been a problem):
      Code:
/dev/sda1 /       ext3 noatime,errors=remount-ro,commit=240  0 1



What is the output of
      Code:
# mount
for your root filesystem?
IgnorantGuru - 04.04.2011, 13:40
Post subject:
      dibl wrote:
What is the output of
      Code:
# mount
for your root filesystem?


Hey dibl, fancy meeting you here. Wink

      Code:
/dev/sda1 on / type ext3 (rw,noatime,commit=240,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
tmpfs on /tmp type tmpfs (rw,noatime,size=1000M,mode=1777)
tmpfs on /var/log type tmpfs (rw,noatime,size=200M,mode=0755)


The only ones there which I modified are sda1, /tmp, and /var/log. I also tend to set commit=120 for my conventional drives (not shown), just to make them quieter.
dibl - 04.04.2011, 14:19
Post subject:
Interesting. I'm seeing a "commit=0" option being added to my ext4 mount lines, for some reason:

http://aptosid.com/index.php?name=PNphp ... amp;t=1072

I don't know when this started happening. I've still got a 2.6.36 and a 2.6.37, and it happens when I boot those kernels also. So I think you're booting a 2.6.37, and I don't see the "commit=0" option added on yours. I wonder what's up with my ext4 filesystem?


EDIT: I have found that the ext4 root partition is being re-mounted during the boot process:

      Code:
don@aptosidbox:~$ dmesg | grep remount
[   16.009772] EXT4-fs (sdb1): re-mounted. Opts: errors=remount-ro,barrier=0,discard
[   29.108894] EXT4-fs (sdb1): re-mounted. Opts: errors=remount-ro,barrier=0,discard,commit=0


and so this second remount is where the "commit=0" option is being appended to whatever I have in /etc/fstab for that partition (it happens to other ext4 partitions also).
IgnorantGuru - 04.04.2011, 15:08
Post subject:
      dibl wrote:
and so this second remount is where the "commit=0" option is being appended to whatever I have in /etc/fstab for that partition (it happens to other ext4 partitions also).


That is strange - I haven't given ext4 a serious try yet. And yes I'm using the 37 kernel still.

I would try this:
      Code:
sudo grep -Rs "commit=" /etc /usr


This hit might be relevent - do you have power.d enabled?

      Code:
/usr/lib/pm-utils/power.d/journal-commit:   remount_fs $1 "commit=${2}"

dibl - 04.04.2011, 19:05
Post subject:
      IgnorantGuru wrote:


This hit might be relevent - do you have power.d enabled?


That was a good hint. There's no need for power.d on this desktop rig, but you are correct that there is a file at /usr/lib/pm-utils/power.d/journal-commit that provides a default commit=0 value for a change from battery to AC. But that one is not the source of the appended "commit=0" on my system. I changed the AC value in journal-commit and rebooted to be certain -- it is coming from somewhere else.
IgnorantGuru - 04.04.2011, 19:14
Post subject:
      dibl wrote:
it is coming from somewhere else.


Well, you could always remount it (perhaps in rc.local?) Doesn't seem like it should be doing that though, so it would be good to know where it's coming from.
dibl - 04.04.2011, 20:01
Post subject:
      IgnorantGuru wrote:


Well, you could always remount it (perhaps in rc.local?)


Well, maybe ... funny thing, "mount -a" has also lost some of its mojo in recent times -- apparently it no longer parses the mount options in /etc/fstab. So I'll have to learn more about the mount command, I guess, and maybe try something like you suggested.


p.s. -- no "sudo" prefix on Debian commands (unless you deliberately re-wire it to use sudo). Wink
IgnorantGuru - 04.04.2011, 20:19
Post subject:
      dibl wrote:
I guess, and maybe try something like you suggested.


This should do it, perhaps put it in rc.local:
      Code:
mount -o remount,commit=240 /dev/sda1


      Quote:
p.s. -- no "sudo" prefix on Debian commands (unless you deliberately re-wire it to use sudo). Wink


I use sudo to denote "do this command as root", but I need to find a better way, as some people do indeed not use sudo. What is the norm? Some preface root commands with "#" and users with "$", but I don't like that as # is a comment.
dibl - 04.04.2011, 20:26
Post subject:
Well ....

      Code:
root@aptosidbox:/etc# mount -o remount,commit=120 /dev/sdd1
root@aptosidbox:/etc# mount
/dev/sdd1 on / type ext4 (rw,noatime,errors=remount-ro,discard,barrier=0,commit=120,commit=120)


So, seeing the extra "commit=120" appended, I tried it this way:

      Code:
root@aptosidbox:/etc# mount -o remount /dev/sdd1
root@aptosidbox:/etc# mount
/dev/sdd1 on / type ext4 (rw,noatime,errors=remount-ro,discard,barrier=0,commit=120)


and THERE I have it mounted exactly as stated in /etc/fstab. But I'm so confused ... Sad

EDIT: It is possible that the AMI BIOS, and the BIOS's on the (a) PCI SSD and (b) the Marvel SATA 6GiB/s controller are interacting in some way during boot -- it's a complex setup for a desktop system and I don't pretend to understand every bit of the complexity that I have built here, although it generally works great.
IgnorantGuru - 04.04.2011, 21:45
Post subject:
The double commit is odd - I can't explain that, but I get the same behavior here. According to man, remount "merges" options. At any rate, your solution looks like it works. I doubt the double option is a problem, but I don't know how to test if it's really working.

      Quote:
EDIT: It is possible that the AMI BIOS, and the BIOS's on the (a) PCI SSD and (b) the Marvel SATA 6GiB/s controller are interacting in some way during boot -- it's a complex setup for a desktop system and I don't pretend to understand every bit of the complexity that I have built here, although it generally works great.


I would more suspect something to do with ext4, but I don't know. Something is remounting it during the boot with options different than fstab. You could try temporarily disabling acpid to see if that's the culprit.
dibl - 04.04.2011, 22:30
Post subject:
Thanks for the help, IG. I'm going to settle, for now, since I'm able to remount it with my chosen options. I've got a feeling there is more information coming -- probably I just need to hang in for some weeks or months until the rest of the story comes out.

Thanks again! Smile
IgnorantGuru - 05.04.2011, 12:02
Post subject:
My pleasure - "it doesn't have to be perfect". Smile
dibl - 05.04.2011, 19:51
Post subject:
Found this in /var/log/daemon.log:


      Code:
/usr/lib/pm-utils/power.d/intel-audio-powersave false: success.
Running hook /usr/lib/pm-utils/power.d/journal-commit false:

/usr/lib/pm-utils/power.d/journal-commit false: success.
Running hook /usr/lib/pm-utils/power.d/journal-commit_orig false:
Setting journal commit time for / to 0...Done.
Setting journal commit time for /mnt/REVODATA to 0...Done.
Setting journal commit time for /mnt/WHATEVER to 0...Done.


The file "journal-commit_orig" is just the backup of the original file, before I changed the default for AC mode to 120 seconds. So this being done by ACPI, right?

FIXED: The backup file "journal-commit_orig" was apparently being parsed, after the "journal-commit" file, and the value "commit=0" was accepted and used. I deleted that file entirely, leaving only the edited "journal-commit" file, with the commit value changed to 120, and after a reboot the ext4 filesystems are mounted with the desired options, according to "mount".
All times are GMT - 12 Hours
Powered by PNphpBB2 © 2003-2010 The Zafenio Group
Credits