[conspire] request verification of plans to partition and format external hard drive
jim at well.com
Fri Jul 20 20:05:11 PDT 2007
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
> 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
> 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
> 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
> 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
> operation? (Yes.) Aren't there some subtrees that are better off
> normally mounted read-only, and therefore should be on separate
> filesystems from ones normally mounted read/write? (Yes.) Aren't
> some subtrees that would benefit from being separate in order to be
> mounted noatime, nodev, nosuid, noexec -- or being ext2 rather than
> 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.
>> 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
> 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
More information about the conspire