Re: Clone OS to HD via DOS and Clean Install XP?

From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 21:22:30 +0200

On Tue, 30 Mar 2004 11:21:53 +1000, "Rod Speed" <rod_speed@yahoo.com>
>cquirke (MVP Win9x) <cquirkenews@nospam.mvps.org> wrote

>> Partitioning certainly can speed things up,

>Hardly ever. The main time you get much of an effect there
>is if the drive is partitioned with the rarely used files on the
>slowest part of the drive, so head movements tend to be
>reduced in terms of the number of tracks moved on average.

Of course - that's exactly what I have in mind!

>> with all of the above factors in mind. The trick
>> is to be clueful about what goes where, and how
>> you size and order your partitions and volumes.

>> Let's say you have a 120G HD that contains 4G of core OS and
>> app code, about 2G tops or swap and temp (having slashed the
>> web cache to 20M), and 90G of assorted movies, MP3, games
>> etc. that you use from time to time. On one big C:, the OS may
>> *try* to put things in sensible places, but it's quite likely to mess up.

>Bull*** on that 'quite likely'

See later. Do you have a write-up on exactly how the OS decides what
goes where? Without that, it's a "beauty contest", i.e. all we are
debating is how much faith we have in the coders not to screw up. But
by limiting the damage this can do, the answer matters less.

>> So let's say you put the "hot" 4G + 2G in an 8G C:, crucial
>> data in a 2G D: (safely away from all C:'s write traffic)

>Mad. The only thing that makes any sense is to ensure
>that the 'crucial data' is always fully backed up.

Ah, "backup". The cure-all that makes live adat irrelevant.

There's a problem inherent in the backup concept:
  - backup must be so up-to-date that no recent data is lost
  - backup must pre-date the changes/losses you want to undo

Nothing works 100%, so anything that partially works has value. File
system corruption occurs when the drive is written to; no writes, no
corruption risk. So if your data is on a volume that sees writes only
when you are saving data, it's that much safer.

This is the concept behind not allowing pedestrians on freeways.

>> and everything else after that on a big E:. Let's say you reserve
>> the last 2G for a small F:, which contain auto-backups of D:.

>Makes a hell of a lot more sense
>to have auto backups off that drive.

"Auto" and "off that drive" don't really work together, as most
off-drive storage requires removable media to be inserted - so it
isn't "auto" anymore. Exceptions: Backup pulls via LAN (which I do
use in automated fashion) and uploading data to an Internet repository
somewhere. The latter doesn't make much sense to me, given you are
now relying on someone else's privacy and server management.

Backup's usually a stretch between 3 apices of a triangle:
  - scope; what range of disasters does it hedge against?
  - convenience; how likely is it to be done?
  - capacity; how much can I back up?

It sounds as if you are focusing on the first, to the exclusion of
others. IOW if it doesn't cover against all eventualities, it's not
worth doing. By that logic, the only backups we';d do would be
off-system and located outside of the building - and how often is that
going to get done? Many disasters don't require that full-scope
protection to undo, so a "shallowed" backup done more often reduces
the work lost when restoring in these cases.

In practice, on small LANs, I use a holographic auto-backup:
  - 02:00, each PC backups up its own data set elsewhere on HD
  - 03:00+, other PCs pull most recent backup to themselves
  - user then manually dumps collected backups to CDRW
  - backup CDRWs rotated so one is always off-site

"Most recent"? Yes, as the local backup keeps the last 5 backups,
purging the oldest by nameslot rather than date logic (so as to be Y2k
or flat-CMOS-battery proof).

If the building burns down, they fall back to the last off-site CDRW
If the whole LAN gets stolen, then fall back to last CDRW
If all but one PC are stolen, they fall back one day
If problem missed for < 5 days, local backups "deep" enough to undo

BTW, any backup that depends on removable disks is often abandoned for
months when disks become unavailable. That would "never happen" in a
professionally-administered installation, I know, but trust me; out
there in small self-administered peer-to-peer land, it's common.

>> Now it doesn't matter how clueless defrag is - not matter where
>> it splatters the contents of C:, it's always in the first 8G of the HD.

>Makes a hell of a lot more sense to not defrag at all.

Eh? Well, put it this way:
  - defrag's not a drag when the always-in-use volumes are small
  - not defragging doesn't hurt much if intelligently partitioned

Looks like a win-win to me :-)

>Bet you wouldnt be able to pick between the system that is
>defragged and the one that isnt, otherwise identical, in a
>proper double blind trial without being able to use a frag display.

Not sure about that either way. There are other benefits, though,
when it comes to things like data recovery, and routine maintenance is
lot less tedious when you "have somewhere to stand on"

>> And as most of the tinme you're using C: and D:,

>Depends entirely on how much the large files in E are
>used. Plenty have music particularly running all the time.

If there's music running all the time, then there is a single file on
E: being accessed all the time.

>> the system is as fast as if you'd just bought
>> it and hadn't gunked it up with 90G of stuff!

>More mindlessly superficial silly stuff. The 90G
>wont necessarily slow it down if it isnt used much.

Yes it will, because it will act as a sandbar between the front of the
HD (where Windows code is paged back in) and the fringe of the file
set (where new files are created). Defrag logic that intentionally
leaves holes before "seldom used" material seeks to address that
problem - in essence, to do automatically what intelligent
partitioning casts in stone.

>> Also, when you have to ChkDsk after a bad
>> exit, or defrag, C: is fast, because it's so small.

>Its stupid obsessively defragging modern systems.

True; I defrag after large uninstalls/deletes or before big installs,
but the rest of the time I don't bother. I'm not of the "give us each
day out daily defrag" school of maintenance either.

Post-bad-exit file system checks will always be with us, however.

>And that particular partition is more likely to get
>fragged when its got so much less free space
>than a single partition for the whole physical drive.

No. It's only when the file wave hits the end of the volume and
bounces back that the system will really start creating new files in
the gaps within the bulk of the file load. A volume that's always
500M from the end of the volume is just as clean as one that's always
100G away from the end of the volume.

If a volume is destined to have no more than, say, 20G on it, then a
file positioning strategy that places some material at the end of the
volume and other material in the middle of the volume will be slower
in one big 120G C: than in, say, a 32G volume on that 120G

>> If you need to ChkDsk E: as well, you can do so when
>> it suits; just don't use anything there until you've done so.

>Most real world systems dont chkdsk that much and if
>there is much of that, the cause needs to be fixed instead.

True - that's why I prefer "auto" checks to stop on errors and ask
user for decsions, and why I prefer an easily-accessible log to be
appended rather than overwritten.

But because checking a 120G volume takes so long, the temptation to
skip the test for later is huge. Doing so defeats the purpose of the
auto-check, i.e. it leaves Windows to bash away at an at-risk file
system. Partitioning helps in two ways; by keeping your data out of
the main risk area, and by allowing the always-in-use volumes to be
speedily checked and the bulk of the drive to be checked later.

>>>> A separate disk is better re head repositioning time over multiple partitions,

>> A separate disk is a luxury, and has downsides. For example,
>> one 120G would cost less than 2 x 40G and run faster too.

>And it makes no sense to go that route with the swap file anyway.
>Makes a lot more sense to spend that extra on more physical
>ram so the swap file doesnt get used much except at boot time.

Yep. For the same money, I'd nearly always choose one big HD + RAM
over two smaller HDs. The only exceptions I can think of is where you
want to unlink system vs. data head travel (streaming media
development) or to RAID 1 or other two-HD strategies for data safety.

>>> BUT XP normally does its own thing moving files around
>>> in an attempt to speed things up anyway, so there is
>>> more involved than just fragrmention of system files.

>> Yep. It's annoying to see a 120G "big C:" with an 8G total file set,

>Mindlessly superficial and irrelevant case.

Nope; often the first part of a new PC's life is lived exactly like
that. Big HDs are not much more costly than small ones (until > 120G)
so I do NOT build PCs with puny HDs because I thing the user "won't
need the capacity". Holding a given file set in fewer cylinders means
large HDs are faster too - as long as you don't let clueless file
positioning spread everything from one end of the HD to the other.

>> and find half the stuff is stuck in the middle of the HD. IMO,
>> better to keep that in a smaller C: so that even if the OS does
>> decide to spread things out, it can only do so within a small part
>> of the HD. Then de-bulk the "engine room" to other volumes.

>No thanks. I bet you wouldnt be able to pick between
>those two configs either in a proper double blind trial.

In which case it doesn't matter which of us is "right", does it? But
as I mentioned, there are reasons other than speed to go this route.

>Makes a hell of a lot more sense to go for the simpler
>single partition for physical drive config and not get bitten
>when you inevitably find that the partition sizes are wrong.

It's seldom that I've needed to reshape partitions - usually, once
every 3-5 years, if that. Usually by that time, the total HD capacity
is a problem anyway, and that one addresses by not using puny little
HDs. Vendors are building PCs today with Pentium 4 overspend and 40G
HDs; the motherboards are typically Micro-ATX trash with no AGP slot.

>If you do a full backup of that physical drive before adjusting
>the partition sizes, you've wasted FAR more time than
>you will have gained if you even gain anything at all.

Yep. As I say; between 0 and 1 times in 5 years <shrug> ...the odds
of HD failure and data recovery are, in my experience, between 3 and 5
times as high; perhaps the biggest payoff for smart partitioning.

>-------------------- ----- ---- --- -- - - - -
    Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -