i'm about to install f19 new on an ASUS G74S laptop with:
* primary 240G SSD drive * secondary 750G regular HD
as well as 16G RAM, so i'm open to suggestions as to the best way to do this for efficiency, protecting the SSD from constant activity, and wanting to be able to do all this at installation time if possible. finally, i'd like to have LVM in the mix somewhere, even if only for the ability to experiment with it and get some practice.
as i see i, first, if i want LVM, i want to restrict it to the second drive. i don't see much value in LVM on the SSD, and i certainly don't want to have a single volume group spanning both drives as that just gives LVM the opportunity to create LVs mixing SSD and non-SSD PVs, and i'm pretty sure i want to avoid that.
so, as a first impression, i'm tempted to partition the SSD drive using standard partitions:
* small /dev/sda1 for /boot * another small regular partition for swap? * remainder for root partition, with the understanding that anything under root that represents constant activity will be partitioned off to the secondary drive.
so what goes on the second drive? i'd turn it into one PV, and define a single VG based on that, then define a number of LVs, the biggest one being /home, perhaps 500G. but what else deserves to be an LV? i might create a /srv LV for serving content, but what about things like /tmp, /var, /run, etc. some are of type tmpfs, what should i do with those? if they run totally out of RAM, then i don't care. in short, / and /boot aside, what other top-level directories merit their own LV on the second drive?
and, finally, can i do all of this at install time? i suspect so, just want to make sure.
rday
On 12/02/2013 10:30 AM, Robert P. J. Day wrote:
i'm about to install f19 new on an ASUS G74S laptop with:
- primary 240G SSD drive
- secondary 750G regular HD
as well as 16G RAM
I have been running a similar configuration for 18 months on a laptop (256GB, 500GB, 16GB).
as i see i, first, if i want LVM, i want to restrict it to the second drive. i don't see much value in LVM on the SSD, and i certainly don't want to have a single volume group spanning both drives as that just gives LVM the opportunity to create LVs mixing SSD and non-SSD PVs, and i'm pretty sure i want to avoid that.
Even with a single VG on both drives, you can specify where your LVs must go. And you can move them in any moment (pvmove).
so, as a first impression, i'm tempted to partition the SSD drive using standard partitions:
- small /dev/sda1 for /boot
Ok.
- another small regular partition for swap?
Not too small. Go for 25GB, so you can suspend to disk at SSD speeds.
- remainder for root partition, with the understanding that anything
under root that represents constant activity will be partitioned off to the secondary drive.
Basic consideration: if there is constant activity, it IS well suited to the SSD. Do you want to use your SSD or just keep it there doing nothing while the disk works?
The paranoia about SSD wearing out is exaggerated. It can die, ok, but every disk can die. Just backup regularly.
so what goes on the second drive? i'd turn it into one PV, and define a single VG based on that, then define a number of LVs, the biggest one being /home, perhaps 500G. but what else deserves to be an LV? i might create a /srv LV for serving content, but what about things like /tmp, /var, /run, etc. some are of type tmpfs, what should i do with those? if they run totally out of RAM, then i don't care. in short, / and /boot aside, what other top-level directories merit their own LV on the second drive?
I think /home should be on the SSD (do you want a fast grep in your files?) And /tmp and /run are already tmpfs based. And I don't see a point in relegating just /var to the disk.
My approach has been: everything on the SSD, with the HD being just a big data repository of big and infrequently accessed files (media stuff, isos, ...), as a sort of "external disk" which is always available.
and, finally, can i do all of this at install time? i suspect so, just want to make sure.
Of course you can.
Quoting Roberto Ragusa mail@robertoragusa.it:
On 12/02/2013 10:30 AM, Robert P. J. Day wrote:
i'm about to install f19 new on an ASUS G74S laptop with:
- primary 240G SSD drive
- secondary 750G regular HD
as well as 16G RAM
I have been running a similar configuration for 18 months on a laptop (256GB, 500GB, 16GB).
as i see i, first, if i want LVM, i want to restrict it to the second drive. i don't see much value in LVM on the SSD, and i certainly don't want to have a single volume group spanning both drives as that just gives LVM the opportunity to create LVs mixing SSD and non-SSD PVs, and i'm pretty sure i want to avoid that.
Even with a single VG on both drives, you can specify where your LVs must go. And you can move them in any moment (pvmove).
ah, and you can do this at *installation* time in fedora 19? in all honesty, i was teaching a first-level RH admin class last week and one of the students had had some experience with the installation program for f19 and he was utterly unimpressed -- said it was massively non-intuitive compared to previous versions and after playing with it, i'm tempted to agree.
that said, i might still be tempted to go with two VGs -- one for "system" (OS), the other "data" (/home, etc.), since i'd probably want to mess with them independently.
so, as a first impression, i'm tempted to partition the SSD drive using standard partitions:
- small /dev/sda1 for /boot
Ok.
- another small regular partition for swap?
Not too small. Go for 25GB, so you can suspend to disk at SSD speeds.
i have 16G of RAM and, if memory serves (which it might not), i think i *rarely* have to resort to swap given that much RAM. if i was using swap constantly, i'd probably put it on the regular HD, but in this case, yes, putting it on SSD would make more sense under the assumption that i'd rarely need it except for suspend.
- remainder for root partition, with the understanding that anything
under root that represents constant activity will be partitioned off to the secondary drive.
Basic consideration: if there is constant activity, it IS well suited to the SSD. Do you want to use your SSD or just keep it there doing nothing while the disk works?
The paranoia about SSD wearing out is exaggerated. It can die, ok, but every disk can die. Just backup regularly.
another possibly dumb question since this is my first foray into SSDs -- is there a utility that will show me current wear levels? i suspect you're right -- i'll probably wear out the laptop before i wear out the SSD.
so what goes on the second drive? i'd turn it into one PV, and define a single VG based on that, then define a number of LVs, the biggest one being /home, perhaps 500G. but what else deserves to be an LV? i might create a /srv LV for serving content, but what about things like /tmp, /var, /run, etc. some are of type tmpfs, what should i do with those? if they run totally out of RAM, then i don't care. in short, / and /boot aside, what other top-level directories merit their own LV on the second drive?
I think /home should be on the SSD (do you want a fast grep in your files?) And /tmp and /run are already tmpfs based. And I don't see a point in relegating just /var to the disk.
My approach has been: everything on the SSD, with the HD being just a big data repository of big and infrequently accessed files (media stuff, isos, ...), as a sort of "external disk" which is always available.
and, finally, can i do all of this at install time? i suspect so, just want to make sure.
Of course you can.
ok, i'll keep reading. i see a couple more responses to my query, i'll get to those shortly.
rday
On 03.12.2013 13:00, Robert P. J. Day wrote:
ah, and you can do this at *installation* time in fedora 19? in all honesty, i was teaching a first-level RH admin class last week and one of the students had had some experience with the installation program for f19 and he was utterly unimpressed -- said it was massively non-intuitive compared to previous versions and after playing with it, i'm tempted to agree.
To understand something, first you have to understand, and only then you can understand how to use it.
poma
On Dec 2, 2013, at 2:30 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
- another small regular partition for swap?
Swap on the SSD if you will need to use swap regularly, including if you want faster recovery from sleep. Otherwise put it on the HDD. Make it as big as you plan on memory being in the life of this install so you don't have to figure out how to recreate a bigger one.
/, /boot, /home can all go on the SSD so they don't even need to be separate partitions. Just make one big partition for all of them.
so what goes on the second drive?
Big files, like movies, music, and photos.
You can do this by adding a mountpoint for a partition located on the HDD. Something like /home/chris/bigfiles if you want it only accessible in your user directory. Or you can put it at /home/bigfiles. Or you can put it at /data. The installer's Manual Partitioning will let you do this.
i'd turn it into one PV, and define a single VG based on that, then define a number of LVs, the biggest one being /home, perhaps 500G. but what else deserves to be an LV? i might create a /srv LV for serving content, but what about things like /tmp, /var, /run, etc. some are of type tmpfs, what should i do with those? if they run totally out of RAM, then i don't care. in short, / and /boot aside, what other top-level directories merit their own LV on the second drive?
It's almost not worth strategizing, I'd put everything, including apps on the SSD, and put big files on the HDD.
Down the road with F21, you'll have an install time option to turn the SSD into a cache for the HDD, so they'll look like one logical volume, but bcache will locate hot files on the SSD automatically, with everything ultimately stored on the HDD.
and, finally, can i do all of this at install time? i suspect so, just want to make sure.
Yes.
Just create a new mount point with the + button, then type in the custom mountpoint name, e.g. /home/chris/bigfiles and then specify the size. You might need to click on the tool icon, which presents a dialog letting you choose on what device these partitions are located. But this will create the file system, and add it to fstab so that it's automatically available.
Chris Murphy
On 12/02/2013 02:23 PM, Chris Murphy wrote:
Swap on the SSD if you will need to use swap regularly, including if you want faster recovery from sleep. Otherwise put it on the HDD. Make it as big as you plan on memory being in the life of this install so you don't have to figure out how to recreate a bigger one.
Conventional wisdom used to be that your swap should be twice the size of your RAM. Has that changed?
/, /boot, /home can all go on the SSD so they don't even need to be separate partitions. Just make one big partition for all of them.
I'd still suggest putting /home on its own partition, so that it will survive a re-install. (Of course you have a backup, but doing it this way simplifies things considerably.)
On Dec 2, 2013, at 3:43 PM, Joe Zeff joe@zeff.us wrote:
On 12/02/2013 02:23 PM, Chris Murphy wrote:
Swap on the SSD if you will need to use swap regularly, including if you want faster recovery from sleep. Otherwise put it on the HDD. Make it as big as you plan on memory being in the life of this install so you don't have to figure out how to recreate a bigger one.
Conventional wisdom used to be that your swap should be twice the size of your RAM. Has that changed?
Oops, yeah the installer is using this: https://git.fedorahosted.org/cgit/blivet.git/tree/blivet/devicelibs/swap.py
So for most people I suspect swap = memory, but could be either twice memory or half memory.
/, /boot, /home can all go on the SSD so they don't even need to be separate partitions. Just make one big partition for all of them.
I'd still suggest putting /home on its own partition, so that it will survive a re-install. (Of course you have a backup, but doing it this way simplifies things considerably.)
On a smaller drive like an SSD, it can be a fit to then figure out how much space to reserve for /home and / rather than just having that limited space be combined between them, and dealing with /home migration some other time. There's some chance with a reinstall that the layout will change also.
Another approach the blends both, is Btrfs subvolume for /home and /, which means they share the storage pool but are also essentially separate file systems.
Chris Murphy
Allegedly, on or about 02 December 2013, Joe Zeff sent:
Conventional wisdom used to be that your swap should be twice the size of your RAM.
If you want to be able to suspend to hard drive, then swap *needs* to be bigger than RAM.
Consider whether you will be increasing the size of your RAM in the future, and take that into account when allocating swap space. For instance, if you currently had 2 gig, but your motherboard can handle 8 gig, it might be worth making your swap at least 8 gig, so you don't have to change swap if you add more RAM.
On Dec 3, 2013, at 7:52 AM, Tim ignored_mailbox@yahoo.com.au wrote:
Allegedly, on or about 02 December 2013, Joe Zeff sent:
Conventional wisdom used to be that your swap should be twice the size of your RAM.
If you want to be able to suspend to hard drive, then swap *needs* to be bigger than RAM.
Maybe.
https://bugzilla.redhat.com/show_bug.cgi?id=1037472
FYI anaconda isn't currently computing the swap partition size needed for hibernation.
The computation depends on how much memory you have. Since the OP said the laptop has 16GB RAM, that means it's mem + mem / 2 or 24GB recommended for swap. That's probably more than sufficient. A kernel dev wrote elsewhere that swap is compressed, so a swap amount less than memory might work. But if it's the same as memory it should always work.
https://git.fedorahosted.org/cgit/blivet.git/tree/blivet/devicelibs/swap.py
The formula there has swap anywhere from 1.5x to 3x memory, to configure for hibernation.
Chris Murphy
Tim:
If you want to be able to suspend to hard drive, then swap *needs* to be bigger than RAM.
Chris Murphy:
Maybe.
https://bugzilla.redhat.com/show_bug.cgi?id=1037472
FYI anaconda isn't currently computing the swap partition size needed for hibernation.
If you read the response on that bugzilla, it says Anaconda isn't configuring a system to be be able to hibernate. That does not equate to not needing to set up adequate space to be able to hibernate.
If hibernating is going to be a memory dump to hard drive, then the hard drive space (it's using the swap file/partition) *needs* to be big enough. Doing something that *might* work, doesn't fit the definition of doing what *needs* to be done, to make it work.
Compression isn't always possible. Attempting to rely on something that might work is pretty much guaranteed to bite you on the bum at the time you needed it to work.
On 12/04/2013 05:07 AM, Tim wrote:
If hibernating is going to be a memory dump to hard drive, then the hard drive space (it's using the swap file/partition) *needs* to be big enough. Doing something that *might* work, doesn't fit the definition of doing what *needs* to be done, to make it work.
Compression isn't always possible. Attempting to rely on something that might work is pretty much guaranteed to bite you on the bum at the time you needed it to work.
Then, you must also consider that some swap space could be already used when you hibernate. You need to have enough _free_ swap space.
(It happened to me in the past to have to close some applications to fit the hibernation image into the available swap space, it's annoying,...)
BTW, I'm not sure about compression; I remember a time when tuxonice supported compression (and saved cache), while the mainline hibernation did not have compression (and discarded cache). Maybe things have changed.
Allegedly, on or about 04 December 2013, Roberto Ragusa sent:
Then, you must also consider that some swap space could be already used when you hibernate. You need to have enough _free_ swap space.
(It happened to me in the past to have to close some applications to fit the hibernation image into the available swap space, it's annoying,...)
It's probably the reasoning behind make swap twice as big as RAM. It should leave enough room for RAM to fit into swap, and the wiggle room for the OS to tidy up swap as it hibernates things.
On 12/04/2013 03:21 PM, Tim wrote:
It's probably the reasoning behind make swap twice as big as RAM. It should leave enough room for RAM to fit into swap, and the wiggle room for the OS to tidy up swap as it hibernates things.
Sorry, but I have to inform you that you're putting the cart before the horse. The rule of thumb I mentioned about making swap twice the size of RAM goes back to the early days of MS-DOS, long before there were such things as hibernate or sleep for computers.
On Dec 4, 2013, at 4:29 PM, Joe Zeff joe@zeff.us wrote:
On 12/04/2013 03:21 PM, Tim wrote:
It's probably the reasoning behind make swap twice as big as RAM. It should leave enough room for RAM to fit into swap, and the wiggle room for the OS to tidy up swap as it hibernates things.
Sorry, but I have to inform you that you're putting the cart before the horse. The rule of thumb I mentioned about making swap twice the size of RAM goes back to the early days of MS-DOS, long before there were such things as hibernate or sleep for computers.
Well there's more than one rule of thumb even on linux. And the paging method on DOS is different than NT, so it's surely different than linux, BSD, or OS X. Case in point, OS X has never had the idea of user configurable swap. The dynamic_pager process creates and destroys swapfiles on demand as needed.
On linux, there have been periodic swap code changes, which can be found by doing an lkml search. New in 3.12 is a different block allocation algorithm for swap on SSD, for the 3.11 kernel is zswap, and frontswap has been in since 3.5 kernel.
The anaconda/blivet code suggests upwards of 3x memory if you have less than 4GB RAM and hibernation applies. Whereas for 8GB or more, the suggestion is 1.5x memory if hibernation applies. If hibernation doesn't apply suggested swap is between 0.5x and 2x RAM.
Chris Murphy
On 12/04/2013 07:25 PM, Chris Murphy wrote:
Well there's more than one rule of thumb even on linux. And the paging method on DOS is different than NT, so it's surely different than linux, BSD, or OS X. Case in point, OS X has never had the idea of user configurable swap. The dynamic_pager process creates and destroys swapfiles on demand as needed.
Very true. That's why I specified the origins of the rule I gave, so that people could judge for themselves if it were applicable to them or not.
Quoting Chris Murphy lists@colorremedies.com:
On Dec 2, 2013, at 2:30 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
- another small regular partition for swap?
Swap on the SSD if you will need to use swap regularly, including if you want faster recovery from sleep. Otherwise put it on the HDD. Make it as big as you plan on memory being in the life of this install so you don't have to figure out how to recreate a bigger one.
/, /boot, /home can all go on the SSD so they don't even need to be separate partitions. Just make one big partition for all of them.
i'm not sure i'd put /home on the SSD, as i do all my development under /home, and part of that development is constantly building very large (30-40G) output directories using openembedded and the yocto project. yes, builds would be way faster, but that's a lot of constant activity under /home -- not sure how well that would work out.
rday
-
Chris Murphy -
Joe Zeff -
poma -
Robert P. J. Day -
Roberto Ragusa -
Tim