a lot of questions about SSD

Bahaika · 2010-04-17 06:27:29

Hi everybody;

I've bought yesterday a SSD (G skill 64 Gb) but i'm a little lost right now !
My questions are :
1, What file system can I use with tje SSD ? I've read a lot of things on the web about that, and the Brtfs (included since march in kernel) seems to be a good Idea; isn't it ?
2, About Wear Leveling; is there any firmware which care about that ? Is this necessary to have FS which do it again ?
3, I've a 160 Gb at 5400rpm plugged on the lattop and i would to know if mount the Swap; the /tmp and /var + /home on that disk is the good idea ? (In the way to win speed)

I'm french; and my english is not very good indeed
Thanks for the help;

Bye;

Bahaika

Last edited by Bahaika (2010-04-17 06:28:59)

thestinger · 2010-04-17 07:55:18

as of kernel 2.6.33 linux has trim support (check hdparm) - that should prevent loss of speed overtime as long as you do it on a regular basis (maybe a cronjob? I haven't ever used it so I don't know if the filesystem can be mounted when it runs)

brtfs has real time trim support but the filesystem isn't ready yet afaik - once it is more stable, that's what you'll want to use

You want to minimize repeated writes to the same area - so a journalled filesystem is a bad thing. That doesn't mean "use ext2" - you can use ext4 and disable the journal with tune2fs (it has better performance than ext2).

You should mount /tmp either as tmpfs (if you have 2GB+ of RAM) or on another drive. If you do put it in ram, it really won't use a lot (~1MB) except during compiling (for something big like firefox it will top out at around 700MB).

Put your browser caches in /tmp after you have it mounted as tmpfs/other drive (example: 'su -c "mkdir /tmp/chromium-cache" username' in rc.local and then symlink ~/.cache/chromium to there).

you can use rebase (pacman -S rebase) instead of pacman -Syy and pacman -Sy to minimize drive wear from database updates

you COULD put /var on another drive, but then you lose a lot of the SSD speed benefits, minimizing logging might be a better solution

/home you want on the SSD for sure - those are mostly "big" files (music, movies, images) and it's not really repeated writes

Also, how much ram do you have? you don't have to have swap if you have a lot of ram (2GB+ probably)

Don't worry too much about wearing out the SSD, it should last you a long time with normal use (you aren't running an sql server afaik). It might get a bit slower over time due to wearing out the drive, but by the time it's really noticeable you'll want a new SSD anyway (they'll be a lot cheaper, faster and bigger a year or two from now).

graysky · 2010-06-26 23:21:11

@thestinger - I have a question about your comments about the drive slowing with repeated use: isn't that what TRIM is for?

Cdh · 2010-06-27 10:58:35

thestinger wrote:

brtfs has real time trim support but the filesystem isn't ready yet afaik - once it is more stable, that's what you'll want to use

It may not be ready but it is very usable already.

Just do backups like you would do anyway (of course!) and I see no reason to not use it.

When you have a multicore CPU you can use compression too, very cool feature to even speed up more:
http://www.phoronix.com/scan.php?page=a … trfs&num=2

DeletedUser201201 · 2010-06-27 11:28:05

^ I agree, it might not be finished yet but I would give it a go.

Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. Please email the Btrfs mailing list if you have any problems or questions while using Btrfs.

https://btrfs.wiki.kernel.org/

Last edited by DeletedUser201201 (2010-06-27 11:28:36)

graysky · 2010-06-27 11:30:15

@op- http://wiki.archlinux.org/index.php/SSD

Nepherte · 2010-06-27 12:24:05

thestinger wrote:

as of kernel 2.6.33 linux has trim support (check hdparm) - that should prevent loss of speed overtime as long as you do it on a regular basis (maybe a cronjob? I haven't ever used it so I don't know if the filesystem can be mounted when it runs)

Adding discard to /etc/fstab should enable trim support. I don't think there's any need for some sort of cronjob.

thestinger wrote:

brtfs has real time trim support but the filesystem isn't ready yet afaik - once it is more stable, that's what you'll want to use

I wouldn't use a filesystem marked unstable either for now.

thestinger wrote:

You want to minimize repeated writes to the same area - so a journalled filesystem is a bad thing. That doesn't mean "use ext2" - you can use ext4 and disable the journal with tune2fs (it has better performance than ext2).

I'd keep journaling support. Recovering from crashes is certainly a valuable feature and journaling affects performance/life of any disk in general. I don't think it will affect the life expectancy that much, although I have no numbers to back this up. On a side note, ext4 does more journaling than other journaling file systems like xfs. It is possible to reduce the amount of journaling in ext4 to the journaling level in xfs. A good compromise?

thestinger wrote:

You should mount /tmp either as tmpfs (if you have 2GB+ of RAM) or on another drive. If you do put it in ram, it really won't use a lot (~1MB) except during compiling (for something big like firefox it will top out at around 700MB).

I agree

thestinger wrote:

Put your browser caches in /tmp after you have it mounted as tmpfs/other drive (example: 'su -c "mkdir /tmp/chromium-cache" username' in rc.local and then symlink ~/.cache/chromium to there).

I agree. Something similar can be done for firefox's temporary files in about:config

thestinger wrote:

you COULD put /var on another drive, but then you lose a lot of the SSD speed benefits, minimizing logging might be a better solution

/var is also a good candidate for placing in RAM, just like /tmp, if you don't keep pacman's packages cache. No loss in speed but you need enough ram obviously (without pacman's cache, my /var is around 250Mb).

thestinger wrote:

/home you want on the SSD for sure - those are mostly "big" files (music, movies, images) and it's not really repeated writes

Keeping home on a ssd makes sense if you put your big file data like your entire movie collection or large downloads on another drive. You can't expect one to keep an entire movie collection on an SSD unless the collection is tiny.

In addition, I'd like to add partition and file system alignment to the list of SSD improvements.

Last edited by Nepherte (2010-06-27 12:24:20)

Arch Linux

#1 2010-04-17 06:27:29

a lot of questions about SSD

#2 2010-04-17 07:55:18

Re: a lot of questions about SSD

#3 2010-06-26 23:21:11

Re: a lot of questions about SSD

#4 2010-06-27 10:58:35

Re: a lot of questions about SSD

#5 2010-06-27 11:28:05

Re: a lot of questions about SSD

#6 2010-06-27 11:30:15

Re: a lot of questions about SSD

#7 2010-06-27 12:24:05

Re: a lot of questions about SSD

Board footer