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

From: Rod Speed (rod_speed_at_yahoo.com)
Date: 03/30/04 

Date: Wed, 31 Mar 2004 06:37:34 +1000

cquirke (MVP Win9x) <cquirkenews@nospam.mvps.org> wrote in
message news:7ufj605nlg5rj5s4hl2tpcvd56lehgm2k7@4ax.com...
> Rod Speed <rod_speed@yahoo.com> wrote
>> 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!

Trouble is that with modern systems there is very little
effect there anymore, because that mostly happens
auto, particularly with the system files being discussed.

>>> 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.

Completely useless.

> 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.

That aint the only way to decide if its 'quite likely'

The other obvious approach is to see what it does in practice.

> But by limiting the damage this can do,

You aint established any 'damage'

> the answer matters less.

Or you can get real radical and try a proper double
blind trial and discover that you cant actually pick
between the system configured your way.

>>> 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.

Its perfectly feasible to ensure that live data is always
fully backed up if that matters. Doesnt even cost much.

> There's a problem inherent in the backup concept:

Nope.

> - backup must be so up-to-date that no recent data is lost
> - backup must pre-date the changes/losses you want to undo

Its perfectly feasible to ensure that live data is always
fully backed up if that matters. Doesnt even cost much.

> Nothing works 100%,

Bull***. That just costs more with backup.

> so anything that partially works has value.

And there are plenty of alternatives
that are a lot less partial than others.

If the data matters, its completely stupid to have the backup
on the same physical drive as what's being backed up.

> File system corruption occurs when the drive is written to;

Hardly ever.

> no writes, no corruption risk.

Wrong again. The drive can just die.

> So if your data is on a volume that sees writes
> only when you are saving data, it's that much safer.

Wrong again. The risk of data corruption due to writes
is MUCH less than the risk of data loss due to hard drive
failure and so the only thing that makes any sense at all
with data that matters is to not have the backup on the
same physical drive as the data being backed up.

> This is the concept behind not allowing pedestrians on freeways.

Wrong again.

>>> 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,

Wrong again.

> as most off-drive storage requires removable media to be inserted

Wrong again. There are plenty of off drive backup
destinations that dont use removable media.

> - so it isn't "auto" anymore.

It is if it doesnt use removable media.

> Exceptions: Backup pulls via LAN
> (which I do use in automated fashion)

Which makes a lot more sense than
that stupid approach of your drive D

> and uploading data to an Internet repository somewhere.
> The latter doesn't make much sense to me,

Your problem. That approach does mean that
even if the building that houses the lan burns to
the ground, the data that matters doesnt get lost.

> given you are now relying on someone
> else's privacy and server management.

Completely trivial to ensure that they cant access the data.

Completely trivial to ensure that their server
management is working and use more than
one if you need that level of realtime backup too.

> 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?

More waffle. The reality is that your drive D approach is
about the least useful around, only provides protection
against the least likely cause of data loss and there
are plenty of MUCH better approaches to backup.

> It sounds as if you are focusing on
> the first, to the exclusion of others.

Best get your ears tested then.

> IOW if it doesn't cover against all eventualities, it's not worth doing.

Never ever said anything remotely resembling anything like that.

I JUST said that your D drive is about the least useful
approach to backup. Barely better than nothing in fact.

> 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?

As often as you like with net backup.

> Many disasters don't require that full-scope protection to undo,

Duh.

> so a "shallowed" backup done more often reduces
> the work lost when restoring in these cases.

And your D drive is about the least useful
approach. Because the modern reality is that
its mostly hard drive failure that loses data.

> In practice, on small LANs, I use a holographic auto-backup:

Thats not what holographic means.

> - 02:00, each PC backups up its own data set elsewhere on HD

No point in this with the next one.

> - 03:00+, other PCs pull most recent backup to themselves
> - user then manually dumps collected backups to CDRW

Mindlessly crude and unreliable.

> - 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).

Anyone with a clue use NTP for that last.

> 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

And there isnt any point in that original D partition. Like I said.

> BTW, any backup that depends on removable disks is often
> abandoned for months when disks become unavailable.

Only by stupids.

> That would "never happen" in a professionally-administered
> installation, I know, but trust me;

No thanks.

> out there in small self-administered
> peer-to-peer land, it's common.

If its common, its stupid to use it. MUCH better to use net backup
instead. Particularly when the volume isnt like to be high in that case.

>>> 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

Defragging is pointless if you cant pick the defragged system
in a proper double blind trial. You're just increasing the risk
of data corruption for no useful purpose what so ever.

> Looks like a win-win to me :-)

Best get those eyes tested too.

>> 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.

Get real radical and try it.

> There are other benefits, though, when
> it comes to things like data recovery,

Bull***. Backup should ensure that that isnt ever needed.

> and routine maintenance is lot less tedious
> when you "have somewhere to stand on"

Mindless waffle.

>>> 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.

Wrong again head movement wise.

>>> 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,

Nope.

> 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).

Not with a drive that isnt being mindlessly furiously defragged.

> 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.

And if you dont mindlessly furiously defrag...

>>> 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.

Then your 'sandbar' above wont happen.

And you aint achieving anything by the defragging you do do either.

> 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.

Nope, decently implemented systems dont get those much.

>> 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.

Yep.

> 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.

Free block allocation hasnt been as crude as that for years and years now.

> 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.

Wrong.

> 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

Pity none are that crude with any OS that matters anymore.

>>> 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.

All irrelevant to whether the time taken
matters when the system hardly ever does one.

> But because checking a 120G volume takes so long,
> the temptation to skip the test for later is huge.

Not if it hardly ever happens.

> Doing so defeats the purpose of the auto-check, i.e. it
> leaves Windows to bash away at an at-risk file system.

Irrelevant if it hardly ever happens you just let it complete.

> 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.

And has other major downsides, like when the
partition size needs to be manually adjusted.

>>>> 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;

Yep.

> often the first part of a new PC's life is lived exactly like that.

Bull***. Hardly anyone is starting life with a new PC anymore.

> 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".

Sure.

> 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.

Doesnt happen in practice with any OS worth using.

>>> 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?

Corse it does. There isnt any point in your over complex
organisation if it doesnt achieve anything. That produces a
system thats more messy to administer. In spades when the
inevitable happens, the partition sizes turns out to be too small.

> But as I mentioned, there are reasons
> other than speed to go this route.

Pity you havent managed to establish a single one.

>> 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.

Dont believe it. And thats not real life for normal users anyway.
They dont usually have a clue about what sizes are appropriate.

> 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.

The percentage of the market sales that match that is trivial.

>> 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>

Thats not real life for partitioned drives.

> ...the odds of HD failure and data recovery are,
> in my experience, between 3 and 5 times as high;

So having the backup partition on the same physical drive is stupid.

> perhaps the biggest payoff for smart partitioning.

Nope. Anyone with a clue uses a better
approach to backup of the data that matters.