after a while living with ubuntu, i'm moving back to fedora as of F18, and would like some advice. i have an ASUS G74S with twin 750G drives, but i want to replace the boot drive with an SSD, and install F18 in such a way as to maximize the benefit of the SSD for booting and (mostly) R/O storage.
a lot of my time will be spent doing lengthy compiles (kernel, openembedded), so in addition to system content on the SSD, i'll want to keep all of my source there as well, while the build directories will be on the regular drive.
is there a recommendation for installing F18 in terms of separating what's appropriate for the SSD versus what isn't? most of that is fairly obvious, just wondering if anyone wrote up something about their experience doing just that and how well it worked for them. thanks.
rday
On 01/22/2013 01:08 PM, Robert P. J. Day wrote:
is there a recommendation for installing F18 in terms of separating what's appropriate for the SSD versus what isn't? most of that is fairly obvious, just wondering if anyone wrote up something about their experience doing just that and how well it worked for them. thanks.
SSDs are now so big that you can fit the whole OS on one with room to spare, and just use the hard drive for scratch data. I use a 47G partition on a 128G SSD for my root filesystem. It's getting full now, but 13G of that is scratch.
Andrew.
On 01/22/2013 06:08 AM, Robert P. J. Day wrote:
after a while living with ubuntu, i'm moving back to fedora as of F18, and would like some advice. i have an ASUS G74S with twin 750G drives, but i want to replace the boot drive with an SSD, and install F18 in such a way as to maximize the benefit of the SSD for booting and (mostly) R/O storage.
a lot of my time will be spent doing lengthy compiles (kernel, openembedded), so in addition to system content on the SSD, i'll want to keep all of my source there as well, while the build directories will be on the regular drive.
is there a recommendation for installing F18 in terms of separating what's appropriate for the SSD versus what isn't? most of that is fairly obvious, just wondering if anyone wrote up something about their experience doing just that and how well it worked for them. thanks.
rday
I have has an OCZ-VERTEX3 as my primary drive for about a year now, and it has been awesome.
What was most impressive was installing some various virtual machines for work testing.
The first time I saw my new Fedora 17 VM boot in less than 3 seconds, I knew I had a winner. :) And when it was shut down, it literally 'blinked' off. It was amazing.
I highly recommend a SSD for Linux. The mount command is generally smart enough to select what needs to be done.
/etc/fstab says:
UUID=32ce7d57-5c81-4e4f-9bbb-91e5cde5db3b / ext4 defaults 1 1
but it actually mounts with:
(rw,relatime,data=ordered)
Go for it!
Robert P. J. Day wrote:
after a while living with ubuntu, i'm moving back to fedora as of F18, and would like some advice. i have an ASUS G74S with twin 750G drives, but i want to replace the boot drive with an SSD, and install F18 in such a way as to maximize the benefit of the SSD for booting and (mostly) R/O storage.
a lot of my time will be spent doing lengthy compiles (kernel, openembedded), so in addition to system content on the SSD, i'll want to keep all of my source there as well, while the build directories will be on the regular drive.
is there a recommendation for installing F18 in terms of separating what's appropriate for the SSD versus what isn't? most of that is fairly obvious, just wondering if anyone wrote up something about their experience doing just that and how well it worked for them. thanks.
First, read the multiple threads regarding the fc18 installer. Go look at the links in the messages. After you have a handle on the new installer, go for it.
If you are doing builds, you presumably do multi-threaded make operation, so the source files on SSD will buy you little. If you have room, fine, but putting the object files, temp space, swap[1] space, any libraries you use, on SSD will buy you more. I put a small swap on SSD high priority so it gets used first. Swap usage is pretty light if you have memory suited to your task, so it need not be huge. If you intend to hibernate leave room for the compressed RAM image there, it makes boot a lot faster.
Definitely put root on SSD, that's a gain. I've played with putting the journal of filesystem on SSD for my disk based filesystems. Too early to say how well I like it or how good it is. I did do crash testing to be sure it work, reading a journal from SSD is *fast*.
One issue with the new installer is that it's difficult to pre-create the filesystems and then use them, playing with filesystem directory hash, stripe and stride extended options to change write behavior, all hard with the new install. Frankly, unless you are doing guru level tuning, don't worry about it.
Enjoy your SSD!
Look this topic: http://thessdreview.com/Forums/linux/225-post2940.htm#post2940 I using Fedora 17 with this options.
PS: my logs put in other HD.
-- Sergio Augusto Vladisauskis -> Oportunix IT Services Brasil - ME -> Site: http://www.facebook.com/oportunix -> Fone: +55 (11) 4221-8163 -> Móvel: +55 (11) 9-5308-7965 [Vivo] -> Skype: oportunix -> Registered Linux User: 305281
2013/1/22 Bill Davidsen davidsen@tmr.com
Robert P. J. Day wrote:
after a while living with ubuntu, i'm moving back to fedora as of F18, and would like some advice. i have an ASUS G74S with twin 750G drives, but i want to replace the boot drive with an SSD, and install F18 in such a way as to maximize the benefit of the SSD for booting and (mostly) R/O storage.
a lot of my time will be spent doing lengthy compiles (kernel, openembedded), so in addition to system content on the SSD, i'll want to keep all of my source there as well, while the build directories will be on the regular drive.
is there a recommendation for installing F18 in terms of separating what's appropriate for the SSD versus what isn't? most of that is fairly obvious, just wondering if anyone wrote up something about their experience doing just that and how well it worked for them. thanks.
First, read the multiple threads regarding the fc18 installer. Go look
at the links in the messages. After you have a handle on the new installer, go for it.
If you are doing builds, you presumably do multi-threaded make operation, so the source files on SSD will buy you little. If you have room, fine, but putting the object files, temp space, swap[1] space, any libraries you use, on SSD will buy you more. I put a small swap on SSD high priority so it gets used first. Swap usage is pretty light if you have memory suited to your task, so it need not be huge. If you intend to hibernate leave room for the compressed RAM image there, it makes boot a lot faster.
Definitely put root on SSD, that's a gain. I've played with putting the journal of filesystem on SSD for my disk based filesystems. Too early to say how well I like it or how good it is. I did do crash testing to be sure it work, reading a journal from SSD is *fast*.
One issue with the new installer is that it's difficult to pre-create the filesystems and then use them, playing with filesystem directory hash, stripe and stride extended options to change write behavior, all hard with the new install. Frankly, unless you are doing guru level tuning, don't worry about it.
Enjoy your SSD!
-- Bill Davidsen davidsen@tmr.com "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.**org/mailman/listinfo/usershttps://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/**Mailing_list_guidelineshttp://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Sergio Augusto Vladisauskis wrote:
Look this topic: http://thessdreview.com/Forums/linux/225-post2940.htm#post2940 I using Fedora 17 with this options.
PS: my logs put in other HD.
Always good to get another view, however I would like to see a better explanation of what those changes do before just telling people to do them (him, not you).
in no order:
deadline scheduler works for SSD (and most types of RAID) but I did't see any big gain so I general l don't bother.
Having /tmp be really temporary can lead to having to find a better place to put stuff you need for a few days, and putting it in RAM requires enough memory to match what you would use on disk. In my case that's a few GB, but everyone has a different idea of what it should do, so understand the results before you decide faster is always better.
I want to test what setting fifo_batch is going to do before I comment on that. There is no such value in RHEL5 or FC17 on my machines: ls -lG /sys/block/sda/queue/iosched/ total 0 -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_max -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_penalty -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_async -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 group_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 low_latency -rw-r--r--. 1 root 4096 Jan 22 13:38 quantum -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async_rq -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 target_latency so I want to go look at the kernel code and description to see what that does and what side effects it might have.
Changing the elevator=deadline option on the kernel command line will change it for all drives, not just the SSD. That may really not what you want for performance on non-RAID drives.
The techniques are good to know, but I hope people do understand the side effects of some of these things.
Do not forget the finite number of writes SSDs have. For instance I would keep /temp out of the SSD.
----- Original Message ----- Sergio Augusto Vladisauskis wrote:
Look this topic: http://thessdreview.com/Forums/linux/225-post2940.htm#post2940 I using Fedora 17 with this options.
PS: my logs put in other HD.
Always good to get another view, however I would like to see a better explanation of what those changes do before just telling people to do them (him, not you).
in no order:
deadline scheduler works for SSD (and most types of RAID) but I did't see any big gain so I general l don't bother.
Having /tmp be really temporary can lead to having to find a better place to put stuff you need for a few days, and putting it in RAM requires enough memory to match what you would use on disk. In my case that's a few GB, but everyone has a different idea of what it should do, so understand the results before you decide faster is always better.
I want to test what setting fifo_batch is going to do before I comment on that. There is no such value in RHEL5 or FC17 on my machines: ls -lG /sys/block/sda/queue/iosched/ total 0 -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_max -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_penalty -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_async -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 group_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 low_latency -rw-r--r--. 1 root 4096 Jan 22 13:38 quantum -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async_rq -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 target_latency so I want to go look at the kernel code and description to see what that does and what side effects it might have.
Changing the elevator=deadline option on the kernel command line will change it for all drives, not just the SSD. That may really not what you want for performance on non-RAID drives.
The techniques are good to know, but I hope people do understand the side effects of some of these things.
On 01/22/2013 10:51 AM, Bill Davidsen issued this missive:
Sergio Augusto Vladisauskis wrote:
Look this topic: http://thessdreview.com/Forums/linux/225-post2940.htm#post2940 I using Fedora 17 with this options.
PS: my logs put in other HD.
Always good to get another view, however I would like to see a better explanation of what those changes do before just telling people to do them (him, not you).
in no order:
deadline scheduler works for SSD (and most types of RAID) but I did't see any big gain so I general l don't bother.
Having /tmp be really temporary can lead to having to find a better place to put stuff you need for a few days, and putting it in RAM requires enough memory to match what you would use on disk. In my case that's a few GB, but everyone has a different idea of what it should do, so understand the results before you decide faster is always better.
I want to test what setting fifo_batch is going to do before I comment on that. There is no such value in RHEL5 or FC17 on my machines: ls -lG /sys/block/sda/queue/iosched/ total 0 -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_max -rw-r--r--. 1 root 4096 Jan 22 13:38 back_seek_penalty -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_async -rw-r--r--. 1 root 4096 Jan 22 13:38 fifo_expire_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 group_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 low_latency -rw-r--r--. 1 root 4096 Jan 22 13:38 quantum -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_async_rq -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_idle -rw-r--r--. 1 root 4096 Jan 22 13:38 slice_sync -rw-r--r--. 1 root 4096 Jan 22 13:38 target_latency so I want to go look at the kernel code and description to see what that does and what side effects it might have.
Changing the elevator=deadline option on the kernel command line will change it for all drives, not just the SSD. That may really not what you want for performance on non-RAID drives.
The techniques are good to know, but I hope people do understand the side effects of some of these things.
And please, PLEASE make sure you have a reliable and consistent backup procedure. I like SSDs, but when they die they generally die catastrophically and completely (at least in my experience) and you may not be able to recover anything from them.
Standard drives tend to get "flakey" as they spiral down the drain and you may have enough time to get a backup off them before they completely croak.
Just saying...... ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If Windows isn't a virus, then it sure as hell is a carrier! - ----------------------------------------------------------------------
Rick Stevens ricks@alldigital.com writes:
And please, PLEASE make sure you have a reliable and consistent backup procedure. I like SSDs, but when they die they generally die catastrophically and completely (at least in my experience) and you may not be able to recover anything from them.
You can do rsyncs from /etc/cron.daily onto a spare, normally unmounted and spun-down, disk. That way if your SSD ever goes south, you lose at most a day's work. When I got my ssd I wasn't sure what to expect, so I figured I'd play it safe. The only time I needed the daily backup was a goof that did involve the ssd, but was the result of confusion as to which directory I was in. The incredible speed of the SSD allowed me to delete a few thousand pictures in approximately a second. SSD's: allowing you to make mistakes faster than ever before. ;-)
-wolfgang
I have one of these but on my windows 8 laptop :-
http://www.dabs.com/products/samsung-250gb-840-series-sata-6gb-s-2-5--solid-...
Its a good deal but SSD's are coming down in price dramatically.
Aaron
On 24 January 2013 14:38, Wolfgang S. Rupprecht < wolfgang.rupprecht@gmail.com> wrote:
Rick Stevens ricks@alldigital.com writes:
And please, PLEASE make sure you have a reliable and consistent backup procedure. I like SSDs, but when they die they generally die catastrophically and completely (at least in my experience) and you may not be able to recover anything from them.
You can do rsyncs from /etc/cron.daily onto a spare, normally unmounted and spun-down, disk. That way if your SSD ever goes south, you lose at most a day's work. When I got my ssd I wasn't sure what to expect, so I figured I'd play it safe. The only time I needed the daily backup was a goof that did involve the ssd, but was the result of confusion as to which directory I was in. The incredible speed of the SSD allowed me to delete a few thousand pictures in approximately a second. SSD's: allowing you to make mistakes faster than ever before. ;-)
-wolfgang
g+: https://plus.google.com/114566345864337108516/about
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
How to maximise SSD performance with Linux: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm
-- Sergio Augusto Vladisauskis -> Oportunix IT Services Brasil - ME -> Site: http://www.facebook.com/oportunix -> Fone: +55 (11) 4221-8163 -> Móvel: +55 (11) 9-5308-7965 [Vivo] -> Skype: oportunix -> Registered Linux User: 305281
2013/1/26 Aaron Gray aaronngray.lists@gmail.com
I have one of these but on my windows 8 laptop :-
http://www.dabs.com/products/samsung-250gb-840-series-sata-6gb-s-2-5--solid-...
Its a good deal but SSD's are coming down in price dramatically.
Aaron
On 24 January 2013 14:38, Wolfgang S. Rupprecht < wolfgang.rupprecht@gmail.com> wrote:
Rick Stevens ricks@alldigital.com writes:
And please, PLEASE make sure you have a reliable and consistent backup procedure. I like SSDs, but when they die they generally die catastrophically and completely (at least in my experience) and you may not be able to recover anything from them.
You can do rsyncs from /etc/cron.daily onto a spare, normally unmounted and spun-down, disk. That way if your SSD ever goes south, you lose at most a day's work. When I got my ssd I wasn't sure what to expect, so I figured I'd play it safe. The only time I needed the daily backup was a goof that did involve the ssd, but was the result of confusion as to which directory I was in. The incredible speed of the SSD allowed me to delete a few thousand pictures in approximately a second. SSD's: allowing you to make mistakes faster than ever before. ;-)
-wolfgang
g+: https://plus.google.com/114566345864337108516/about
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 01/31/2013 05:05 PM, Sergio Augusto Vladisauskis wrote:
How to maximise SSD performance with Linux: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm
A better title would have been: "How to have a SSD and not use it". It explains how to not use it for swap, tmp files, logs, browser cache, ...
It will also make you lose any accesstime reporting, as relatime is replaced with noatime,nodiratime.
And it suggests messing with the disk scheduler, which will not improve anything (noop can actually make the system slower).
And it suggests to enable trim, which, even if it is something to consider, is not enabled by default for some good (performance) reasons.
The only good advice is to align the partitions, but this has probably been already done during the system installation; if not, good luck shifting everything a few blocks.
Here are my personal recommendations for SSD: 1) replace the HDD with the SSD 2) there is no step 2
:-)
-
Aaron Gray -
Andrew Haley -
Bill Davidsen -
ergodic -
Phil Meyer -
Rick Stevens -
Robert P. J. Day -
Roberto Ragusa -
Sergio Augusto Vladisauskis -
Wolfgang S. Rupprecht