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'
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:
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 and WWFD 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
Well, there were a couple of reasons why I wanted to go with these
(1) Accomodate the crazy Everything install people now.
(2) Provide enough room to store packages when doing yum upgrade or
(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
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.
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.
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.
2) x86 may have a smaller / requirement than x86_64, should that be
Eh, I don't know that it's too important. But it would be easy enough
to take into account with the Platform module.
3) Let's say "f the FHS" and change /home to /users.
Only if we can call it /Users.
Anaconda-devel-list mailing list
Anaconda-devel-list mailing list