Here's a patch series that ends up with creating a /home by default. The algorithm is basically:
- VG < 50 GB: make /boot, swap, rest as / - VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest as /home
Let the arguing begin.
- Chris
This prevents LVs from being named things like "lv__home". --- storage/__init__.py | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/storage/__init__.py b/storage/__init__.py index 382411a..f369bf3 100644 --- a/storage/__init__.py +++ b/storage/__init__.py @@ -799,7 +799,11 @@ class Storage(object): if mountpoint == '/': lvtemplate = 'lv_root' else: - template = "lv_%s" % (mountpoint,) + if mountpoint.startswith("/"): + template = "lv_%s" % mountpoint[1:] + else: + template = "lv_%s" % (mountpoint,) + lvtemplate = safeLvmName(template) else: if swap:
--- storage/partspec.py | 37 ++++++++++++++++++++++++++++++++++++- 1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/storage/partspec.py b/storage/partspec.py index 21544de..8ad81ca 100644 --- a/storage/partspec.py +++ b/storage/partspec.py @@ -21,7 +21,29 @@
class PartSpec(object): def __init__(self, mountpoint=None, fstype=None, size=None, maxSize=None, - grow=False, asVol=False, weight=0): + grow=False, asVol=False, weight=0, requiredSpace=0): + """ Create a new storage specification. These are used to specify + the default partitioning layout as an object before we have the + storage system up and running. The attributes are obvious + except for the following: + + asVol -- Should this be allocated as a logical volume? If not, + it will be allocated as a partition. + weight -- An integer that modifies the sort algorithm for partition + requests. A larger value means the partition will end up + closer to the front of the disk. This is mainly used to + make sure /boot ends up in front, and any special (PReP, + appleboot, etc.) partitions end up in front of /boot. + This value means nothing if asVol=False. + requiredSpace -- This value is only taken into account if + asVol=True, and specifies the size in MB that the + containing VG must be for this PartSpec to even + get used. The VG's size is calculated before any + other LVs are created inside it. If not enough + space exists, this PartSpec will never get turned + into an LV. + """ + self.mountpoint = mountpoint self.fstype = fstype self.size = size @@ -29,3 +51,16 @@ class PartSpec(object): self.grow = grow self.asVol = asVol self.weight = weight + self.requiredSpace = requiredSpace + + def __str__(self): + s = ("%(type)s instance (%(id)s) -- \n" + " mountpoint = %(mountpoint)s asVol = %(asVol)s\n" + " weight = %(weight)s fstype = %(fstype)s\n" + " size = %(size)s maxSize = %(maxSize)s grow = %(grow)s\n" % + {"type": self.__class__.__name__, "id": "%#x" % id(self), + "mountpoint": self.mountpoint, "asVol": self.asVol, + "weight": self.weight, "fstype": self.fstype, "size": self.size, + "maxSize": self.maxSize, "grow": self.grow}) + + return s
This allows us to disregard certain requests when there's not enough space in the VG for the request to make any sense. --- storage/partitioning.py | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/storage/partitioning.py b/storage/partitioning.py index 1e2ee40..f785b0e 100644 --- a/storage/partitioning.py +++ b/storage/partitioning.py @@ -129,6 +129,8 @@ def _scheduleLVs(anaconda, devs): vg = anaconda.id.storage.newVG(pvs=pvs) anaconda.id.storage.createDevice(vg)
+ initialVGSize = vg.size + # # Convert storage.autoPartitionRequests into Device instances and # schedule them for creation. @@ -138,6 +140,9 @@ def _scheduleLVs(anaconda, devs): if not request.asVol: continue
+ if request.requiredSpace and request.requiredSpace > initialVGSize: + continue + if request.fstype is None: request.fstype = anaconda.id.storage.defaultFSType
This modifies the default partitioning as follows:
(1) For VGs <= 50 GB, we will continue to make swap and / as normal. (2) For VGs >= 50 GB, / will cap at 50 GB and /home will consume the rest.
50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user. --- installclass.py | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/installclass.py b/installclass.py index 7143f6a..1e1d9b8 100644 --- a/installclass.py +++ b/installclass.py @@ -178,7 +178,10 @@ class BaseInstallClass(object):
def setDefaultPartitioning(self, storage, platform): autorequests = [PartSpec(mountpoint="/", fstype=storage.defaultFSType, - size=1024, grow=True, asVol=True)] + size=1024, maxSize=50*1024, grow=True, + asVol=True), + PartSpec(mountpoint="/home", fstype=storage.defaultFSType, + size=100, grow=True, asVol=True, requiredSpace=50*1024)]
bootreq = platform.setDefaultPartitioning() if bootreq:
--- platform.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/platform.py b/platform.py index ca4bf9e..62260da 100644 --- a/platform.py +++ b/platform.py @@ -161,7 +161,7 @@ class Platform(object):
def setDefaultPartitioning(self): """Return the default platform-specific partitioning information.""" - return [PartSpec(mountpoint="/boot", fstype=self.defaultBootFSType, size=200, + return [PartSpec(mountpoint="/boot", fstype=self.defaultBootFSType, size=250, weight=self.weight(mountpoint="/boot"))]
@property
On Thu, Oct 29, 2009 at 11:58:19 -0400, Chris Lumens clumens@redhat.com wrote:
This modifies the default partitioning as follows:
(1) For VGs <= 50 GB, we will continue to make swap and / as normal. (2) For VGs >= 50 GB, / will cap at 50 GB and /home will consume the rest.
50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user.
If you install all of the different language stuff and all of the games, 50 GB is very tight. That is probably unusual, but I used 50GB / the last time I resized things and now I am thinking I should have made / a bit bigger.
50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user.
If you install all of the different language stuff and all of the games, 50 GB is very tight. That is probably unusual, but I used 50GB / the last time I resized things and now I am thinking I should have made / a bit bigger.
Is that a fact? Well, I guess I might either have to revise my initial suggestion or remove the "appease the Everything install people" as part of my rationale for the 50 GB number. I think once we start talking about getting / up over or around 70 GB, it's starting to get a little ridiculously large.
I should probably do an Everything install and see what happens.
- Chris
On Fri, Oct 30, 2009 at 09:39:03 -0400, clumens@redhat.com wrote:
Is that a fact? Well, I guess I might either have to revise my initial suggestion or remove the "appease the Everything install people" as part of my rationale for the 50 GB number. I think once we start talking about getting / up over or around 70 GB, it's starting to get a little ridiculously large.
I should probably do an Everything install and see what happens.
I suspect that even the everything install people don't install all of the locale addons for packages. I like to, because sometimes conflicts only hit some of the locales and I can report bugs.
Also when you have a lot of stuff installed and you do an update, you might need a significant amount of space in /var to hold the downloaded packages and to do the install.
I found that with a 50 GB / and all games and all locale variants of things like moodle and open office and some rpmfusion stuff (including a few more large games), I was having trouble doing large updates. (This was with a local mirror of rawhide on another partition, cutting the amount of space needed for yum on / .) So I removed some of the locale stuff to get down to using about 40 GB out 50 GB to leave space for doing updates. When I went from F11 to F12 via yum I had to still break up the updates even with about 10GB available for scratch space that wasn't needed for the rpm files.
I think this is an extreme situation and you might still want to use 50 GB.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 Oct 2009, Chris Lumens wrote:
Here's a patch series that ends up with creating a /home by default. The algorithm is basically:
- VG < 50 GB: make /boot, swap, rest as /
- VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest as /home
Let the arguing begin.
I like the idea of creating a /home by default, but I'm not a fan of the 50GB number. I understand it's slightly over the current Everything install, which makes sense, but I think about my systems:
1) Over time, your /home directory will probably contain more data than / what with music, movies, pictures, code, saved email with eBay outbid notices, 0-day warez, video game emulators, and other things. My home directory is 27GB and / is only taking up 5.5GB.
2) /home is also a good place for people to tar up /etc, /root, and other things if they want to do a fresh install of Fedora. At least I always use it for that when I do a fresh Fedora install.
3) WWSD[1] and WWFD[2] tell us that / should be minimal and most available space should go to either /export/home or /usr/home (maybe it's just /home now on FreeBSD).
I'm also thinking of what people would be expecting during an install. If I have a 250GB disk and 50GB is allocated to / by default, I'm going to change that. I still want a 10GB / and the rest for /home. What are other people's thoughts on this?
I'm in favor of a /home by default, but I'd like to see the / value lowered from 50GB.
Some other ideas...
1) For live installs, we know the size of what's going to /, so we could use that as the basis for sizing /, then make /boot, swap, and /home.
2) x86 may have a smaller / requirement than x86_64, should that be considered?
3) Let's say "f the FHS" and change /home to /users.
[1] What Would Solaris Do? [2] What Would FreeBSD Do?
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
I like the idea of creating a /home by default, but I'm not a fan of the 50GB number. I understand it's slightly over the current Everything install, which makes sense, but I think about my systems:
- Over time, your /home directory will probably contain more data than / what
with music, movies, pictures, code, saved email with eBay outbid notices, 0-day warez, video game emulators, and other things. My home directory is 27GB and / is only taking up 5.5GB.
- /home is also a good place for people to tar up /etc, /root, and other
things if they want to do a fresh install of Fedora. At least I always use it for that when I do a fresh Fedora install.
- WWSD[1] and WWFD[2] tell us that / should be minimal and most available
space should go to either /export/home or /usr/home (maybe it's just /home now on FreeBSD).
Well, there were a couple of reasons why I wanted to go with these numbers:
(1) Accomodate the crazy Everything install people now.
(2) Provide enough room to store packages when doing yum upgrade or preupgrade.
(3) Make it big enough so we don't have to worry about bumping the size up every release as the distribution gets bigger.
(4) We're not recommending a separate /opt, /usr/local, /var, or /tmp right now so we need enough space for all the things people could do with those filesystems.
I'm also thinking of what people would be expecting during an install. If I have a 250GB disk and 50GB is allocated to / by default, I'm going to change that. I still want a 10GB / and the rest for /home. What are other people's thoughts on this?
I'm in favor of a /home by default, but I'd like to see the / value lowered from 50GB.
The way I see it, things are moving in two different directions right now: disks are getting smaller (netbooks, etc.) and disks are getting larger (everyone else). For the smaller case, we don't need to worry about this because we're throwing out the /home case there. For larger, disks are really giant these days. If we're suggesting 50 GB for / and that leaves 500 GB for /home, I don't think most people are going to care about what space they might be losing there.
I really don't think it's g oing to be an issue, but keep in mind that these are just recommendations and the user always has the option to change things in the partitioning UI. We don't need to be perfect - just good enough.
Having said that, I'm not completely tied to this 50 GB number. I did just kind of pull it out of thin air.
- For live installs, we know the size of what's going to /, so we could use
that as the basis for sizing /, then make /boot, swap, and /home.
True, we could be smarter here. That would have to involve setting this default partition in the backend and might be a little difficult. However, it could be a decent refinement.
- x86 may have a smaller / requirement than x86_64, should that be
considered?
Eh, I don't know that it's too important. But it would be easy enough to take into account with the Platform module.
- Let's say "f the FHS" and change /home to /users.
Only if we can call it /Users.
- Chris
I'm nobody, but here's my 2 cents.
Don't mount it as /home, or /export/home, but something more generic, and make 'home' (or 'Users' or whatever) a directory inside that mountpoint so the 1 large pool of space can be shared got multiple purposes.
I never understood Sun's use of /export/home, but I found it useful to mount the remaining space as just /export, and then I made directories inside it for home, groups, projects, tools, etc. The one generic name doesn't need to be /export but that worked well for me since all the things I put in there were exported via NFS. (and automounted to /import/... - even locally) Your milage may vary though.
Of course it seems strange to have hour home dir hidden in /export/home on a single user machine, but then by default Sun did use the automounter loopback mount that to /home so you never knew.
I'm not suggesting using the mouintpoints I do, I'm only suggesting that you don't lock down what the space is used for by mounting it as something labeled 'home' or 'users' - Make it a conatiner and put 'home' in there. :)
-Kyle
Chris Lumens wrote:
I like the idea of creating a /home by default, but I'm not a fan of the 50GB number. I understand it's slightly over the current Everything install, which makes sense, but I think about my systems:
- Over time, your /home directory will probably contain more data than / what
with music, movies, pictures, code, saved email with eBay outbid notices, 0-day warez, video game emulators, and other things. My home directory is 27GB and / is only taking up 5.5GB.
- /home is also a good place for people to tar up /etc, /root, and other
things if they want to do a fresh install of Fedora. At least I always use it for that when I do a fresh Fedora install.
- WWSD[1] and WWFD[2] tell us that / should be minimal and most available
space should go to either /export/home or /usr/home (maybe it's just /home now on FreeBSD).
Well, there were a couple of reasons why I wanted to go with these numbers:
(1) Accomodate the crazy Everything install people now.
(2) Provide enough room to store packages when doing yum upgrade or preupgrade.
(3) Make it big enough so we don't have to worry about bumping the size up every release as the distribution gets bigger.
(4) We're not recommending a separate /opt, /usr/local, /var, or /tmp right now so we need enough space for all the things people could do with those filesystems.
I'm also thinking of what people would be expecting during an install. If I have a 250GB disk and 50GB is allocated to / by default, I'm going to change that. I still want a 10GB / and the rest for /home. What are other people's thoughts on this?
I'm in favor of a /home by default, but I'd like to see the / value lowered from 50GB.
The way I see it, things are moving in two different directions right now: disks are getting smaller (netbooks, etc.) and disks are getting larger (everyone else). For the smaller case, we don't need to worry about this because we're throwing out the /home case there. For larger, disks are really giant these days. If we're suggesting 50 GB for / and that leaves 500 GB for /home, I don't think most people are going to care about what space they might be losing there.
I really don't think it's g oing to be an issue, but keep in mind that these are just recommendations and the user always has the option to change things in the partitioning UI. We don't need to be perfect - just good enough.
Having said that, I'm not completely tied to this 50 GB number. I did just kind of pull it out of thin air.
- For live installs, we know the size of what's going to /, so we could use
that as the basis for sizing /, then make /boot, swap, and /home.
True, we could be smarter here. That would have to involve setting this default partition in the backend and might be a little difficult. However, it could be a decent refinement.
- x86 may have a smaller / requirement than x86_64, should that be
considered?
Eh, I don't know that it's too important. But it would be easy enough to take into account with the Platform module.
- Let's say "f the FHS" and change /home to /users.
Only if we can call it /Users.
- Chris
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, 2009-11-03 at 13:47 -0500, Chris Lumens wrote:
I don't believe we have the ability to express sizes of requests this complex, even after the thing I added in this patch. I also think this is a fairly difficult change to make - at least in a clean and generic way.
I know it's supposed to be a world of arbitrary LBA, but ensuring slices (partitions) are on perfect cylinder boundaries is ideal, and should be the default. I guess one could give the option to use an alternative heads/sector size in the "druid," but I'd default to what the disk uses (in the case it does not already have a disk label / partition table, which we already respect if it does).
On Tue, 2009-11-03 at 14:32 -0500, Bill Nottingham wrote:
64GB is a (somewhat) stock SSD size.
Just remember that 64GB = 59.6GiB. And then there are also spare cells.
Of course, if we're going to start talking SSDs, we should _avoid_ creating swap on a SSD while we're at it. ;)
On Thu, 2009-10-29 at 21:04 -0400, Kyle McDonald wrote:
I never understood Sun's use of /export/home
Whether it's /export or some other TLD than /home, the idea is to always have the "source" located outside of /home, because /home may be automounted. To this day, I still use the nomenclature ...
/export/(server)/(resource) -> /home/(domain)/(resource)
The "server" in the /export source tells me the server. The "domain" in the /home mount where all the automounter maps for that domain will will mount. In the server itself, I will use a local automounter map with a bind mount to override the domain automounter map that uses a network filesystem protocol when the store is local to the server itself.
On Thu, 2009-10-29 at 21:04 -0400, Kyle McDonald wrote:
but I found it useful to mount the remaining space as just /export
As a fallback, such as on any workstation, I just create (and bind mount): /export/local -> /home/local
On Tue, 2009-11-03 at 14:46 -0500, Bryan J Smith wrote:
Whether it's /export or some other TLD than /home, the idea is to always have the "source" located outside of /home, because /home may be automounted. To this day, I still use the nomenclature ...
FYI, my point was that people will differ on what to use /export for. I don't think we should be creating a default /export at all. Just create a default /home. Those who prefer otherwise will create it.
The idea here is that people should keep their user data separate by default. A default /home is a great way to do that. Making suggestions outside of /home will invoke a lot of differing opinion.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 Oct 2009, Chris Lumens wrote:
I like the idea of creating a /home by default, but I'm not a fan of the 50GB number. I understand it's slightly over the current Everything install, which makes sense, but I think about my systems:
- Over time, your /home directory will probably contain more data than / what
with music, movies, pictures, code, saved email with eBay outbid notices, 0-day warez, video game emulators, and other things. My home directory is 27GB and / is only taking up 5.5GB.
- /home is also a good place for people to tar up /etc, /root, and other
things if they want to do a fresh install of Fedora. At least I always use it for that when I do a fresh Fedora install.
- WWSD[1] and WWFD[2] tell us that / should be minimal and most available
space should go to either /export/home or /usr/home (maybe it's just /home now on FreeBSD).
Well, there were a couple of reasons why I wanted to go with these numbers:
(1) Accomodate the crazy Everything install people now.
That is a good point. Better to handle everything in Fedora rather than only a subset (even though the subset is what the majority of users will ever have installed).
(2) Provide enough room to store packages when doing yum upgrade or preupgrade.
Also a good point.
(3) Make it big enough so we don't have to worry about bumping the size up every release as the distribution gets bigger.
We can say that now, but we'll still have to keep an eye on this number just like we have to keep an eye on the size for /boot.
(4) We're not recommending a separate /opt, /usr/local, /var, or /tmp right now so we need enough space for all the things people could do with those filesystems.
True.
I'm also thinking of what people would be expecting during an install. If I have a 250GB disk and 50GB is allocated to / by default, I'm going to change that. I still want a 10GB / and the rest for /home. What are other people's thoughts on this?
I'm in favor of a /home by default, but I'd like to see the / value lowered from 50GB.
The way I see it, things are moving in two different directions right now: disks are getting smaller (netbooks, etc.) and disks are getting larger (everyone else). For the smaller case, we don't need to worry about this because we're throwing out the /home case there. For larger, disks are really giant these days. If we're suggesting 50 GB for / and that leaves 500 GB for /home, I don't think most people are going to care about what space they might be losing there.
I really don't think it's g oing to be an issue, but keep in mind that these are just recommendations and the user always has the option to change things in the partitioning UI. We don't need to be perfect - just good enough.
Having said that, I'm not completely tied to this 50 GB number. I did just kind of pull it out of thin air.
For the standard hard disk size we see now, 50GB is nothing. Netbooks present a different use case. Are those users interested in a separate /home by default? Should we care?
I'll agree that 50GB is fine for the normal sized hard disk use case, but maybe we should break this in to a few different cases:
- The regular hard disk, which for the sake of argument is 250GB or larger by default. - The netbook user or someone with 8GB to 64GB of storage available. - The live CD user, where we already know what will go to / before we get to partitioning setup.
At least the first and last ones there seem like ones worth tackling. The netbook use case may be harder to define. Netbooks now have hard disks as well as SSD. We have a netbook here with a 250GB hard disk in it and my Thinkpad from RH has a 64GB SSD in it. Go figure.
- For live installs, we know the size of what's going to /, so we could use
that as the basis for sizing /, then make /boot, swap, and /home.
True, we could be smarter here. That would have to involve setting this default partition in the backend and might be a little difficult. However, it could be a decent refinement.
Given how hard the live install concept is sold, I think it would be worth our time to do something for this use case.
- x86 may have a smaller / requirement than x86_64, should that be
considered?
Eh, I don't know that it's too important. But it would be easy enough to take into account with the Platform module.
On second thought, this is probably a waste of time. I don't know what the size differences are between an everything x86 and everything x86_64 install. Maybe it's not that great.
- Let's say "f the FHS" and change /home to /users.
Only if we can call it /Users.
Not "/Documents and Settings"?
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
Hi,
On 10/30/2009 02:19 AM, David Cantrell wrote:
<snip>
For the standard hard disk size we see now, 50GB is nothing. Netbooks present a different use case. Are those users interested in a separate /home by default? Should we care?
Yes (for example to only crypt /home, which is a nice performance boost given netbook's speed, also for all the some reasons not netbook users are interested in a separate /home)
So I would like to propose the following instead: If the VG > 30 GB (32 GB - 2GB for /boot and overhead), do a split /home and split things between home and /, 50/50 until / grows over 50 GB at which point we start only growing /home
Given how hard the live install concept is sold, I think it would be worth our time to do something for this use case.
Hmm, then again live installers may end up installing tons of stuff, like openoffice, development tools, ... I don't really see the space needs here being that much different after a couple of months of use.
Regards,
Hans
For the standard hard disk size we see now, 50GB is nothing. Netbooks present a different use case. Are those users interested in a separate /home by default? Should we care?
Yes (for example to only crypt /home, which is a nice performance boost given netbook's speed, also for all the some reasons not netbook users are interested in a separate /home)
The problem with this is that coming up with the split values when you only have 8 GB or 10 GB or 15 GB is way harder, and the consequences of getting it even a little wrong are much larger. If the user's got 200 GB to work with and we end up making / 5 GB too large, probably not a problem. If they've only got 10 GB to work with and we make / 2 GB too large, that's probably a much bigger problem.
So I would like to propose the following instead: If the VG > 30 GB (32 GB - 2GB for /boot and overhead), do a split /home and split things between home and /, 50/50 until / grows over 50 GB at which point we start only growing /home
Well, see my previous comments about how we don't recommend a separate /var, /usr/local, etc. by default and also needing enough space for preupgrade. If they only have 30 GB to work with, we're giving them a 15 GB home. Is that enough for an installed system, and another whole system's worth of packages, plus whatever other crud the user may have laying around?
Given how hard the live install concept is sold, I think it would be worth our time to do something for this use case.
Hmm, then again live installers may end up installing tons of stuff, like openoffice, development tools, ... I don't really see the space needs here being that much different after a couple of months of use.
True, the user could add a bunch of other stuff later. However, one good thing about the livecd case is that we know the size of the payload up front, so we can at least make slightly smarter suggestions. I'm not completely sold on this idea yet but it's worth thinking about.
- Chris
Well, there were a couple of reasons why I wanted to go with these numbers:
(1) Accomodate the crazy Everything install people now.
That is a good point. Better to handle everything in Fedora rather than only a subset (even though the subset is what the majority of users will ever have installed).
I'm really only a little concerned about the Everything case. Perhaps that should not have been my lead-off point.
(2) Provide enough room to store packages when doing yum upgrade or preupgrade.
Also a good point.
This one I am much more concerned about, and I think that someone doing even a half-Everything install is likely to bump into the size limit of / on preupgrade if we set it too small.
(3) Make it big enough so we don't have to worry about bumping the size up every release as the distribution gets bigger.
We can say that now, but we'll still have to keep an eye on this number just like we have to keep an eye on the size for /boot.
Yep, agreed. Guess what we'll periodically forget to do.
For the standard hard disk size we see now, 50GB is nothing. Netbooks present a different use case. Are those users interested in a separate /home by default? Should we care?
They may be interested in a separate /home, but as I told Hans elsewhere, I don't think we're going to be able to reasonably come up with a split for them. It's just too tight. I am willing to punt on this, unless someone is really clever.
I'll agree that 50GB is fine for the normal sized hard disk use case, but maybe we should break this in to a few different cases:
- The regular hard disk, which for the sake of argument is 250GB or larger by default. - The netbook user or someone with 8GB to 64GB of storage available. - The live CD user, where we already know what will go to / before we get to partitioning setup.
At least the first and last ones there seem like ones worth tackling. The netbook use case may be harder to define. Netbooks now have hard disks as well as SSD. We have a netbook here with a 250GB hard disk in it and my Thinkpad from RH has a 64GB SSD in it. Go figure.
I'd agree with this breakdown. I just think I've got them pretty well covered.
- For live installs, we know the size of what's going to /, so we could use
that as the basis for sizing /, then make /boot, swap, and /home.
True, we could be smarter here. That would have to involve setting this default partition in the backend and might be a little difficult. However, it could be a decent refinement.
Given how hard the live install concept is sold, I think it would be worth our time to do something for this use case.
Given how easy it is for the user to install extra stuff, do the two use cases really end up being all that different in their space requirements?
I suppose server installs are less likely to be done via livecd and they have different space requirements than desktop installs. But, we're not making and server vs. desktop decisions in anaconda at all right now.
- x86 may have a smaller / requirement than x86_64, should that be
considered?
Eh, I don't know that it's too important. But it would be easy enough to take into account with the Platform module.
On second thought, this is probably a waste of time. I don't know what the size differences are between an everything x86 and everything x86_64 install. Maybe it's not that great.
I believe the CD set for x86-64 frequently ends up being one CD larger than the i386 set. So at maximum, we can say that today the x86-64 install is one CD's worth of exploded packages larger. That's probably not more than 1 GB of extra stuff, so it doesn't seem like worrying about too much.
Was that enough handwaving?
Only if we can call it /Users.
Not "/Documents and Settings"?
I think that's more of a subdirectory:
/Users/Chris Lumens/Documents and Settings
- Chris
On Thu, Oct 29, 2009 at 10:46:07AM -1000, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 Oct 2009, Chris Lumens wrote:
Here's a patch series that ends up with creating a /home by default. The algorithm is basically:
- VG < 50 GB: make /boot, swap, rest as /
- VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest as /home
Let the arguing begin.
I think you'll have problems with 51 or 64 GB disks. You don't want a /home that is only 1 GB or 14 GB. It might make sense to do this instead:
VG < 50 GB: make /boot, swap, rest as / 100 GB >= VG >= 50GB: make /boot, swap, split rest between / and /home VG > 100 GB: make /boot, swap, / with 50 GB max, rest as /home
That keeps /home from being too small in the separate /home case. The smallest a separate /home could be is 25.5 or 26 GB.
I think you'll have problems with 51 or 64 GB disks. You don't want a /home that is only 1 GB or 14 GB. It might make sense to do this instead:
VG < 50 GB: make /boot, swap, rest as / 100 GB >= VG >= 50GB: make /boot, swap, split rest between / and /home VG > 100 GB: make /boot, swap, / with 50 GB max, rest as /home
That keeps /home from being too small in the separate /home case. The smallest a separate /home could be is 25.5 or 26 GB.
I don't believe we have the ability to express sizes of requests this complex, even after the thing I added in this patch. I also think this is a fairly difficult change to make - at least in a clean and generic way.
We have the ability to do 50/50 splits by giving the requests the same minimum size. And we have the ability to cap requests out at some maximum size. And with my patch we can give requests a minimum size that must exist for the request to even be used. But, I don't think we can combine those together to cover the 50 <= size <= 100 case.
Anyway, do you think that really matters? How many users are going to fall into the 51 GB or 64 GB cases here? See my other mail where I said that we don't even spend this much effort making sure / is a minimum useful size.
- Chris
Chris Lumens (clumens@redhat.com) said:
Anyway, do you think that really matters? How many users are going to fall into the 51 GB or 64 GB cases here? See my other mail where I said that we don't even spend this much effort making sure / is a minimum useful size.
64GB is a (somewhat) stock SSD size.
Bill
Anyway, do you think that really matters? How many users are going to fall into the 51 GB or 64 GB cases here? See my other mail where I said that we don't even spend this much effort making sure / is a minimum useful size.
64GB is a (somewhat) stock SSD size.
For a 64 GB disk, the partitioning's going to end up looking like this:
/boot - 250 MB swap - 1 GB, or whatever / - 50 GB /home - 13 GB
- Chris
On Thu, 2009-10-29 at 11:58 -0400, Chris Lumens wrote:
Here's a patch series that ends up with creating a /home by default. The algorithm is basically:
- VG < 50 GB: make /boot, swap, rest as / - VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest as /home
Let the arguing begin.
I think creating a separate /home is a good idea in many cases. I also think that this approach seems pretty reasonable in general.
How does the split end up looking for some test cases? I'd be curious how it looks for VG sizes of 50G, 60G, 80G, 100G, and 200G.
Dave
- Chris
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
I think creating a separate /home is a good idea in many cases. I also think that this approach seems pretty reasonable in general.
How does the split end up looking for some test cases? I'd be curious how it looks for VG sizes of 50G, 60G, 80G, 100G, and 200G.
Quick tests with the disks I've got readily available:
VG size / /home swap ------- ------- ------- ------- 47 GB 43 GB none 4 GB 81 GB 51 GB 26 GB 4 GB 205 GB 51 GB 148 GB 4 GB
I can't find a combination that adds up to 60 and 100, but I can guess that they'd be 51/5/4 and 51/45/4, respectively.
- Chris
On Thu, Oct 29, 2009 at 11:58:15 -0400, Chris Lumens clumens@redhat.com wrote:
Here's a patch series that ends up with creating a /home by default. The algorithm is basically:
- VG < 50 GB: make /boot, swap, rest as / - VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest as /home
Let the arguing begin.
I think you want a minimum size for /home. Maybe something like: - VG < 70 GB: make /boot, swap, rest as / - VG >= 70 GB: make /boot, swap, / with a 50 GB max, rest as /home
I think you want a minimum size for /home. Maybe something like: - VG < 70 GB: make /boot, swap, rest as / - VG >= 70 GB: make /boot, swap, / with a 50 GB max, rest as /home
I don't think this is that important. Right now, we only guarantee that / will be a minimum of 1 GB, and then later check that the package set is small enough to fit on that. Surely guaranteeing a minimum on the size of /home is of less importance than /, and we don't do that.
Besides, this really only matters in the case where you have a VG between 50 GB (or whatever) and 70 GB. I don't think that'll impact all that many people.
- Chris
On Thu, 2009-10-29 at 11:58 -0400, Chris Lumens wrote:
- VG < 50 GB: make /boot, swap, rest as / - VG >= 50 GB: make /boot, swap, / with a 50 GB max, rest
as /home
So this can lead you into some situations where you have a 50 gig /, and a 20, or 10 or even smaller gig /home which seems counter productive.
Wouldn't it be better to only do the splitting if you have a VG that is 100G or more? (Keep the other numbers, max of 50 /, rest as /home, that's a different argument for a different time)
anaconda-devel@lists.stg.fedoraproject.org