Re: About to format the whole laptop, need some partitioning advice.
butsu butsu butsu butsu ...
On Wed, Feb 5, 2014 at 3:33 PM, Anubhav Yadav <anubhav1691@gmail.com> wrote:
> Hello list,
>
> I have an Asus laptop, with 720 gigs hardisk and i5 processor.
> Right now I have a dual boot of Windoze (only for playing fifa
> and assassins creed) and debian wheezy 64 bit.
Someone suggested VMs, and I'll second that suggestion, except reverse
the idea about making MSWindows the primary domain.
Don't mean offense to whoever posted that, but it does not make any
sense to me. Use the system you have confidence in as your primary
domain.
You should not be using the primary domain on a day-to-day basis, BTW.
Any way you look at it, if you're doing VMs, you want the system you
work in to be a VM instance. makes things much easier to manage. But
the advice below does not fully take that kind of thing into account.
Do you have install media for your MSWindows? (The answer to that also
changes some of the rest of the advice ever-so-slightly.)
> Debian takes a lots of time for booting up and some folks on irc
> said that I should be trying systemd. I did that but there was no
> improvement. So some people also suggested that my partitions
> are somehow not right.
IRC can get good information and bad information. Same here, of course.
30 seconds after login with Gnome 3 is not that bad, especially with a
5400 RPM notebook-class HD.
Someone asked how much RAM you have. How much? 1G is not enough with Gnome 3.
More than 4G is more than is necessary under many "normal" loads, but
if you don't have 4G, 4G is reasonable. If you can add memory or
replace what you have and have the money to spare.
The reason that "4G" of RAM is based on powers of two where "720G" of
HD is based on powers of ten has to do with the way RAM is laid out in
the semiconductor and the way tracks are laid out on disks, BTW. (Not
that you seem to be worried about the distinction between GB and GiB
in the modern parlance of marketing.)
> So now since I am about to partition I would like to know what should
> be the ideal partitioning scheme.
>
> Here is the screenshot of my current partitions.
> http://i.imgur.com/YI4a1oU.png
What are Neo and Workstation for? (May I ask?)
Some of the numbers look like a bit of overkill in some respects, but
they shouldn't really be causes of slow boots (in and of themselves).
The sizes, mixed with other issues could, however, induce issues.
> There was a tool which gave the read-write speeds of my hdd,
> that was mentioned by the guys in irc, I cant remember now, and
> the speeds were very low.
Did that tool also have diagnostics? Was it the ASUS provided tool?
Did you run some tool to check that your HD is not having smartdrive
issues? (Ergo, not dying an untimely death.)
> So these are the questions:
>
> 1) What partitioning scheme should I choose now, If I want to have
> /home, /var, /usr, /tmp on different partitions and I just want a windoze
> partition of 50-60 gb.
Suggestions from me (and no reasons to trust me more than anyone else, perhaps):
/ (root partition) should be at least large enough to handle a /var
gone out of control if /var doesn't mount, or if you don't have a
separate /var. Minimum 4G (base ten or base two, either way). I'd go
with 8G, since you're starting with a drive bigger than 120G. Larger
if you do choose to combine /usr and /var, and so forth, with the root
partition.
/etc? I've seen recommendations to separate /etc as a partition. It's
a bit of a trap for a home-use machine, don't do it this time around.
Keep /etc with /.
/bin? /sbin? /ilb? Keep these combined with / unless you like to
confuse the kernel when it i trying to boot and can't find any of the
standard tools or even some of the libraries it needs to boot even to
single-user mode these days.
/usr? There are strange things that happen to Red Hat (Fedora, etc.)
style machines during boot that indicate against /usr being separate.
I've been bitten by them on Fedora, which is one of the reasons I am
using Debian now.
I keep /usr separate because it tends to change a lot when you install
and remove packages. It's that simple.
However, you don't need more than 32G for /usr unless you really go
crazy installing (literally) every package available, and installing a
lot of packages is one good way to slow your machine down on boot and
login. (Of course, if you don't install lots of stuff, you never get
to play with it and discover new tools. :-/)
Well, be a bit careful what you install beyond what you know you
need, but not too careful. Anyway, 32G for /usr should not be
overkill, and won't be too time consuming when it has to be fsck-ed.
fsck demonstrates one good reason to keep partitions small. Large
partitions take longer on fsck and similar maintenance.
And if you ever have to search for lost text files with testdisk or
such, larger than 32G can be a real, serious show stopper. (I gave up
when I lost two-days' work to a bad Makefile just two weeks back,
because the files were text files and too small for testdisk to see in
the partition they were in. Could have resorted to lower-level
techniques like grep /dev/sda3 or hexdump -C | grep, but I decided it
would be faster to use my gray-matter and type the stuff in from
scratch. It was. (First time took two days to produce the files,
second time took four hours, and was good for checking my work.
Programming is like that in a lot of cases. 8-o)
Unfortunately, /usr/bin, /usr/sbin, and /usr/lib may contain stuff
that the boot-up process wants to use, and may thus cause problems if
they can't be mounted. As I say, I saw that on Fedora. Not on Debian.
That says something about the differences between the two, I think.
(Fedora folks keep themselves busy inventing solutions to problems of
their own making, it seems to me. That's okay for them. Maybe someday
in the distant future, the side-tour on systemd will bear meaningful
fruit. I don't expect it to happen this year or next, and that's
another reason I'm using Debian now. They can have their fun. I need
to focus on other things, myself.)
So, for Debian, I recommend a separate /usr, 32G since you have it.
/tmp? Some say it is not used any more. I say give it at least 8G. 16G
since you have a big HD to start with. I've used it on odd occasions,
and making it too small is bad news. Keeping it separate, so that you
can separate the stuff that changes from the stuff that doesn't is
still a good idea.
/var? Similar to my advice on /tmp, separate partition to separate the
stuff that changes a lot from the stuff that doesn't change as much.
But /var tends to stay around, where /tmp is supposed to be cleared
(or clear-able) on boot. So, I'd recommend 16G or even 32G for /var.
/var gets really hammered on system updates. /var/log gets filled up
quickly when things go south.
And there is /var/tmp which gets used more than /tmp these days. (Both
still get used, even though there are those who claim that ramdisk
temporary files make more sense. Such arguments tend to ignore certain
real-world issues and practices.)
On Fedora, I'd recommend a separate 16G partition for /var/tmp, but
separating /var/tmp is not necessary on Debian.
/home -- 32G. Yes, that will get filled up. That's a good thing,
because you then see what you have that needs to be backed up and what
you have that just needs to be deleted.
If you have reason to host your own http or ftp servers, you might
wish to allocate the base directories for those as /var/ftp and
/var/www or the like. Oh, yeah, samba (or whatever Redmond says that
should be called these days) and nfs shares, too. (And netatalk?) If
you do host services, you probably want to mount their base
directories as separate partitions.
That leaves you with a huge unallocated piece of your hard disk. This
is a good thing. It helps you see what you are using, where, and why.
And when you need to adjust things, you have unused disk space to
partition a bit more out of and mount somewhere (such as, say,
/var/www).
su -h and df -h are good tools to help you see what's being used
where. Check the man pages for them out.
LVM versus DOS extended? I like both. Probably not on the same
machine. LVM has flexibility, since, if you discover that 16G for /var
won't carry you through a system upgrade, you can simply add space to
/var instead of copying sub-directories to their own partitions. Be
aware, however, that too much playing with LVM to adjust your
partition sizes will definitely slow your file system down.
Oh, and if you leave yourself a lot of unallocated disk space, that
leaves more room for VMs, later.
> 2) [...(has been answered)]
One more BTW -- You do want to purchase an external HD for backup.
You'll be much less stressed out when things don't do what you expect
them to, and, if you are studying engineering stuff, you have to get
used to the idea that things don't happen the way you expect.
The creativity you learn when you have no backup and the system
doesn't boot for some semi-trivial reason is good, but backup is
usually better.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: