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

[jim stockford]

i often make lots of partitions, too many some
say.... one trick i have is not to use all cylinders:
I leave maybe 20% of the (inner, aka last)
cylinders unused so's to make more partitions
when i get to the oops moment.

On Jul 20, 2007, at 7:50 PM, Rick Moen wrote:

> 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.
>
>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>