3:30 a.m.
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
10:38 p.m.
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.
9:25 p.m.
On Dec 4, 2013, at 4:29 PM, Joe Zeff <joe(a)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
5:29 p.m.
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.
5:21 p.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
11:41 a.m.
On Dec 3, 2013, at 7:52 AM, Tim <ignored_mailbox(a)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
6:05 a.m.
Quoting Chris Murphy <lists(a)colorremedies.com>:
On Dec 2, 2013, at 2:30 AM, Robert P. J. Day <rpjday(a)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
2:02 a.m.
On Dec 2, 2013, at 3:43 PM, Joe Zeff <joe(a)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
4:43 p.m.
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.)
3:50 p.m.
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.
--
Roberto Ragusa mail at robertoragusa.it
4:23 p.m.
On Dec 2, 2013, at 2:30 AM, Robert P. J. Day <rpjday(a)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
8:52 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
6 a.m.
Quoting Roberto Ragusa <mail(a)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
10:07 p.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
5:55 a.m.
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.
--
Roberto Ragusa mail at robertoragusa.it
7:53 a.m.
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
3795
days inactive
3798
days old
15 comments
6 participants
participants (6)
-
Chris Murphy -
Joe Zeff -
poma -
Robert P. J. Day -
Roberto Ragusa -
Tim