[conspire] request verification of plans to partition and format external hard drive

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
> Rick Moen <rick <at> linuxmafia.com> writes:

> Fedora is considerably less than 100% immune to the need to reinstall
> from scratch on an upgrade, which would make such a setup far less
> optimal than the same setup on, for example, Debian. Ultimately, it's
> just a matter of personal preference.

Over a long period of time, observing many disputes about partitioning
practices and watching many people experiment with them, I finally
concluded that the best way to find the right partitioning setup is to
try a few.  That's how you find out what poses problems for you, and
then you repartition and attempt to refine your approach.

Consider for example the minimally simplistic 1 swap + 1 data partition
approach:  You put Fedora release N onto it.  You live with that for a
while, and one day decide you want to upgrade to N+1.  Let's say that,
like many RH/Fedora users, you find that you have some compelling reason
to do "install" rather than "upgrade".   You realise you need to store
some of your stuff on a spare partition for safekeeping, and... oops!
Everything is already allocated to a single data partition (plus swap), 
so you don't have any safe harbour for files to be preserved.  You
curse, eventually scare up a spare USB flash drive, and slowly copy
stuff off.

Next round (when building the Fedora N+1 installation), you're mindful
of that problem, and think "Aha!  I'll make sure I don't have that
problem _this_ time by having at least one non-root data partition."
So, you make a separate 6 GB filesystem for /home.  That way, come the
day that you wish to install Fedora N+2, you have a filesystem that
_isn't_ going to be blown away, onto which you can store things for
safekeeping.

The first few times you do this, you are a bit vague about _where_ you
have things that need preservation between rebuilds.  Odds are, you're
going to accidentally delete some of your careful work during the
process of rebuild.  E.g., before you installed Fedora N+2 and blew away
the root partition, did you remember to put a tarball snapshot of the
/etc tree into the /home partition for safekeeping?  You did?  Good for
you.  But, did you remember to make a copy of the root user's home
directory (/root)?  How about the /usr/local/ tree?  /opt?  Your CGI
scripts in /usr/bin/cgi-bin?  Your MySQL _database files_ under /var/lib?

Oops!

Each time you do a system build and try to catch blunders you made last
time, you get a bit better at this.  And then, you start worrying about
other concerns:  You decide that /var/spool should be a separate
partition.  Did you make it big enough?  Isn't it true that, the more
finely you divide up the file tree, the more likely that one of the
subtrees will hit 100% full?  (It's true.  There are remedies.  There
is also planning to avoid it.)  Can you possibly order the subtrees
physically so as to minimise the average likely seek time, during normal
operation?  (Yes.)  Aren't there some subtrees that are better off being
normally mounted read-only, and therefore should be on separate
filesystems from ones normally mounted read/write?  (Yes.)  Aren't there
some subtrees that would benefit from being separate in order to be
mounted noatime, nodev, nosuid, noexec -- or being ext2 rather than ext3
for performance reasons?  (Yes.)  If you use NFS or equivalent, aren't
there some subtrees that should be network-shareable among disparate
OSes, versus others that shouldn't?  (Yes.)  Aren't there subtrees that
tend to grow versus others that tend to be static?  (Yes.)

All of those things are _among_ the considerations that can go into a
partitioning policy, and the best way to work out yours -- in my
experience -- is to try a simple one first, find out where it lacks, 
try again with tweaks to achieve better results, and so on.


> For the same reasons, if you have multiple partitions that all get
> accessed a lot, swap would be better placed in the middle.

Quite.

> Yes, and so is JFS, which rivals it in maturity.

It's mature on AIX.  And on OS/2.  I'm not sure I'd say that about the
Linux implementation.

> ZFS holds a lot of promise, but in the Linux world, it's largely still
> vaporware.

Mostly relevant, in any event, to super-large filesystems that would
otherwise have impossibly long fsck times, etc.  

> Interesting story, which could be repeated with the use of the "n"
> command. Of course, "o" is the correct command to use.

Note that the "o" command is completely unnecessary if you are just
creating partitions the normal way on a disk that doesn't already have 
a non-"PC" partition table (e.g., Sun or BSD disklabel).  Ordinarily, 
the PC-type partition table gets created implicitly.  The "o" command
is a way of forcing creation of the PC-type table.

As it happened, on the occasion I described, I didn't bother looking up
how to do that with /sbin/fdisk:  Instead, I just used the good ol' 
"nuke it from orbit" routine:

#  dd if=/dev/zero of=/dev/sdb bs=512 count=1

There's nothing quite like the assurance that there's _absolutely
nothing there_ because you just wrote a stream of zeroes over it.