Partitioning a 2tb hd for Windows 7 64 bit

[charlie]

Waste of time if you have enough of a clue to only reboot every month
or so, and don’t close apps when you stop using them for a while.


That’s just plain wrong with what gets loaded at boot time.


No point in doing that.


No point in doing that either. It makes more sense
to have the non OS and apps on the outer of the
drive too because they mostly do get used at times.


That makes no sense either.


That makes no sense either.


Easier said than done to do that safely if it’s the only 2TB drive you
have.

The only "safe" thing to do with a 2TB drive is to back it up regularly.
Otherwise, a very large loss of data, etc. is possible.

 

[GreyCloud]

On 5/27/2012 12:53 PM, Rod Speed wrote:

<snip>

Bye, dude. The research was done, yet you ignore the proof.

 

[Rod Speed]

Rod Speed wrote

The only "safe" thing to do with a 2TB drive is to back it up regularly.
Otherwise, a very large loss of data, etc. is possible.

Yeah, that’s what I meant.

 

[Rod Speed]

Rod Speed wrote

Bye, dude.

Good riddance, dud.

The research was done,

Not with the systems I use myself it wasn’t.

yet you ignore the proof.

There is no proof on the systems I use myself.

And its completely trivial to prove that my files don’t get corrupted using
CRCs.

 

[Joseph Terner]

On Sun, 27 May 2012 20:16:54 -0400, charlie wrote:
[Rod's nonsense snipped]

The only "safe" thing to do with a 2TB drive is to back it up regularly.
Otherwise, a very large loss of data, etc. is possible.

Separating data by usage pattern and making backup and restore (!) easier
is the whole point in partitioning such a large drive since decades.

Despite this Windows 7 supports resizing partitions out of the box, so
you can extend partitions as needed.

Joseph

 

[Rod Speed]

charlie wrote

Separating data by usage pattern and making backup and restore (!)
easier is the whole point in partitioning such a large drive since
decades.

Even sillier. There is no point in partitioning when
any decent backup app can do incremental backups.

Despite this Windows 7 supports resizing partitions out
of the box, so you can extend partitions as needed.

And if you are actually stupid enough to do that without an
image of the entire physical drive, you get what you deserve
when it all goes pear shaped.

 

[Mike Tomlinson]

Bye, dude. The research was done, yet you ignore the proof.

You're in a battle of wits with an unarmed man.

Rod Speed FAQ: http://tinyurl.com/883xp7v

 

[Mike Tomlinson]

I never back up the system, only data.

I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.

 

[Mike Tomlinson]

Funny that my pair of old DEC VAX4000s do have this built into the
hardware.

DEC built some lovely kit. Tru64 UNIX has 'memory trolling', which runs
in the background and detects faulty memory.

http://tinyurl.com/btc6evf

It is rather obvious that you don't know what you are talking about.

It is, isn't it. Rod Speed FAQ: http://tinyurl.com/883xp7v

 

[Mike Tomlinson]

If he loves to troll, then he would feel at home in comp.os.linux.advocacy.

They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.

 

[Gene Wirchenko]

They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.

Another group that I have followed for years has had periodic
infestations. I see he has recently been posting there, too.

Sincerely,

Gene Wirchenko

 

[GreyCloud]

You're in a battle of wits with an unarmed man.

Rod Speed FAQ: http://tinyurl.com/883xp7v

I know. These types are best ignored.

 

[GreyCloud]

DEC built some lovely kit. Tru64 UNIX has 'memory trolling', which runs
in the background and detects faulty memory.

http://tinyurl.com/btc6evf

I was wondering how they solved that problem in their unix.

It is, isn't it. Rod Speed FAQ: http://tinyurl.com/883xp7v

He will be thoroughly forgotten.

 

[Gene E. Bloch]

I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.

I don't think DLLs get written back to the disk.

They might be written to the swap file and read back, but they are not
written to the Windows directory tree.

 

[Rod Speed]

I'm not talking about backups. I'm talking about Windows loading
system files into memory - DLLs, the registry, etc. These can be corrupted
by faulty memory and then are written back to disk in a corrupt state.

DLLs arent. And there are checks for corrupted registry too.

 

[GreyCloud]

I don't think DLLs get written back to the disk.

They might be written to the swap file and read back, but they are not
written to the Windows directory tree.

It is a complex situation. If your program requires a function from a
DLL file, it will load the dll into ram. Then it depends on what the
dll function will do... it could be used to write data to a file, and if
the ram that holds the dll got corrupted for any reason (just one bit
not set right) then the file may not get written correctly, but most
likely cause a crash. So it would be hard to say what the outcome would
be. Most of the time nothing is noticed tho. The average consumer will
usually not see anything, but one of the "once-in-a-blue-moon" crash or
freeze can happen.
In UNIX, when ram starts to get flakey, the kernel panic happens. That
means it is time to start replacing ram (95% of the time anyway).
The biggest problem will be backing up a file that is already corrupted.
A checksum that is done on a corrupted file at that point won't do you
anygood. Banking systems and critical data stores take the necessary
steps to make sure that the data is good.

 

[Rod Speed]

It is a complex situation.

Nope, very simple, actually.

If your program requires a function from a DLL file, it will load the dll
into ram. Then it depends on what the dll function will do... it could be
used to write data to a file, and if the ram that holds the dll got
corrupted for any reason (just one bit not set right) then the file may
not get written correctly,

And its completely trivial for code that needs to ensure that
cant happen to check that that hasn't happened to the code.

Even just a CRC on the code in ram before its executed will ensure that.

but most likely cause a crash. So it would be hard to say what the
outcome would e.

Not if you have enough of a clue to do a CRC
on the code before its executed in ram and
compare that with the CRC of the DLL etc.

Most of the time nothing is noticed tho. The average consumer will
usually not see anything, but one of the "once-in-a-blue-moon" crash or
freeze can happen.

And with code that needs to be complete robust, the
DLL will just be loaded again and when its CRC is correct
in ram, it will be executed and there wont be anything
more than an soft error logged.

In UNIX, when ram starts to get flakey, the kernel panic happens. That
means it is time to start replacing ram (95% of the time anyway).

The biggest problem will be backing up a file that is already corrupted.

Trivial to ensure that it cant ever be corrupted.

A checksum that is done on a corrupted file at that point won't do you
anygood.

But a CRC before its corrupted will.

Banking systems and critical data stores take the necessary steps to make
sure that the data is good.

And they arent actually stupid enough to spend anything
like $10K on the hardware when it can all be done in software.

 

[Mike Tomlinson]

I don't think DLLs get written back to the disk.

It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?

 

[Mike Tomlinson]

It is a complex situation. If your program requires a function from a
DLL file, it will load the dll into ram. Then it depends on what the
dll function will do... it could be used to write data to a file, and if
the ram that holds the dll got corrupted for any reason (just one bit
not set right) then the file may not get written correctly, but most
likely cause a crash.

just as an aside (I'm probably teaching granny to suck eggs here)
Windows has "Windows File Protection" which can be invoked by 'sfc
/scannow'. This will check for corrupted system files.

But I agree that in mission critical applications, it's best to do
error-checking in hardware, identifying memory faults *before* they have
the opportunity to cause corruption.

 

[Oscar]

It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?

If a dll is damaged by any mechanism, windows will see it as a corrupted dll
and will abort
when it is used.