Disk Partitioning

choro wrote:
On 16/09/2013 22:23, Ed Cryer wrote:
Ed Cryer wrote:
Juan Wei wrote:
Ed Cryer has written on 9/16/2013 3:26 PM:
Juan Wei wrote:
choro has written on 9/15/2013 3:34 PM:
On 15/09/2013 19:28, wrote:
"Ken Blake" wrote in message

You might want to read this article I've written:
http://www.computorcompanion.com/LPMArticle.asp?ID=326

Nice sensible advice. Thx!

The only problem with imaging a single partition HD is the size of
the
image. Don't you run out of space on the destination drive pretty
quickly? (I've inferred that imaging copies the entire partition
rather
than just the blocks that are in use.)

No; just the used parts.

So the image is smaller than the partition?


Exactly. I have a 1GB C partition. Windows shows it as having 87GB used.
The latest Paragon saved image is 74GB. I have several saved images.
I also take Windows images. The latest is 80GB.

Ed


The images cover all the recovery I could want.
1. They can be mounted as virtual drives; and then I can pick off any
file I like.

Man, why mount drives unless, of course, you can't mount sirens?

My friend the retired professor prefers to mount redheads!

Is he a Lib Dem?

Ed

On Tue, 17 Sep 2013 12:55:02 +0200, Steve Hayes
wrote:


With image backups, you can usually chose between incremental or full backup.

I usually choose full.



I am generally against incremental backup. It backs up only those
things that need to be backed up, and that's good.

But what's bad is that if you restore from it, you get back files
you've deleted. That may not always be a problem, but it can be.

On 17/09/2013 15:16, Ed Cryer wrote:
choro wrote:
On 16/09/2013 22:23, Ed Cryer wrote:
Ed Cryer wrote:
Juan Wei wrote:
Ed Cryer has written on 9/16/2013 3:26 PM:
Juan Wei wrote:
choro has written on 9/15/2013 3:34 PM:
On 15/09/2013 19:28, wrote:
"Ken Blake" wrote in message

You might want to read this article I've written:
http://www.computorcompanion.com/LPMArticle.asp?ID=326

Nice sensible advice. Thx!

The only problem with imaging a single partition HD is the size of
the
image. Don't you run out of space on the destination drive pretty
quickly? (I've inferred that imaging copies the entire partition
rather
than just the blocks that are in use.)

No; just the used parts.

So the image is smaller than the partition?


Exactly. I have a 1GB C partition. Windows shows it as having 87GB
used.
The latest Paragon saved image is 74GB. I have several saved images.
I also take Windows images. The latest is 80GB.

Ed


The images cover all the recovery I could want.
1. They can be mounted as virtual drives; and then I can pick off any
file I like.

Man, why mount drives unless, of course, you can't mount sirens?

My friend the retired professor prefers to mount redheads!

Is he a Lib Dem?

Ed

How should I know? He hasn't even lived in the UK in donkey's years. But
he is a goner on redheads!
--
choro
*****

choro wrote:


How should I know? He hasn't even lived in the UK in donkey's years. But
he is a goner on redheads!

Virile male seeks friend; female, redhead, 36-24-36 figure, nubile &
seductive, no more than 30; for active togetherness.

Ed

Hi, Steve.

I made several attempts to install Linux on my D: drive, but most of them
did not work, and the latest one, which did work, is not recognised as D:
by Windows.

I've already pleaded ignorance regarding Linux (including GRUB). But I
think that Linux, like Windows, has to depend on the Partition Table in the
MBR sector on the currently-defined boot device to define Disk # and
Partition #. Windows assigns "drive" letters to those partitions - not to
the entire disk, of course. But Windows probably does not tell Linux what
letters it has assigned. And vice-versa? And the Partition Table itself
knows NOTHING about drive LETTERS.

When you installed Linux on your "D: drive", which Disk # and Partition #
was that? When you boot Windows and run Disk Management, which letter is
assigned to that Disk#/Partition#?

...a program installed on the E drive keeps its registry on the C drive,

No. A program does not have a Registry. It makes entries into THE Registry
maintained by Windows. It is in the Boot Folder on the Boot Volume, and
this is USUALLY C:\Windows on Drive C:, but it can be on any "drive". It
can very well be E:\Windows, depending on the instructions you gave to
Windows' Setup.exe when you installed Windows - and whether you booted from
the Windows DVD or ran Setup from an existing Windows installation.

but when I restore it from Acronis on a completely new disk with a
different partition size, it still manages to find it.

I've never used a program from Acronis, either. But when you restored
Windows to a new disk, you probably restored the System Partition, too, and
that contains the Boot Configuration Data (BCD), which tells the startup
file (bootmgr) where to find Windows. Changing the SIZE of a partition does
not change the letter that was assigned to it. A 500 GB Drive C: shrunk to
8 or 80 GB is still Drive C:. And it may still be the third partition on
the second HDD, as shown in the Partition Table in the System Partition,
probably partition 1 on Disk 0. Of course, if you restored only to Disk 1,
then the System Partition on Disk 0 has not been touched.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Steve Hayes" wrote in message
...

On Mon, 16 Sep 2013 10:00:11 -0500, "R. C. White" wrote:

Of course, most of this is of little or no interest to most users, who
never
get involved in multiple OSes - but many of us in newsgroups like this DO
get into such adventures. To lump us all together in discussing how, why
and whether to use multiple partitions is to overlook the real world
differences between us.

I found it quite interesting, nevertheless.

I made several attempts to install Linux on my D: drive, but most of them
did
not work, and the latest one, which did work, is not recognised as D: by
Windows.

Since my Drive 0 is now 500 Gigs rather than 8, I thought there was enough
room on it to repartition it, and create a D: drive there which I use only
for
photos.

After I repartitioned it, however the GRUB loader was confused, and would
not
load either OS.

I nearly panicked, then popped in the Lunux (Fedora) DVD, and thought to
reinstall it. I calmed my fears by simply putting on the Grub thingy, after
which everything worked again.

So my sysem of drive letters is historical, based on hardware and the space
available at the time I bought it. And others may have a different history,
and so different needs.

I know that a program installed on the E drive keeps its registry on the C
drive, but when I restore it from Acronis on a completely new disk with a
different partition size, it still manages to find it.


--
Steve Hayes from Tshwane, South Africa

Hi, Choro.

This has got to do with wasted space with each addition or amendment to
the file. I always thought filesize and space taken on HD are two
different things though not necessarily all that far apart in space taken.

"Space on disk" is usually more than the actual file size.

If your file system uses 4 KB clusters (aka allocation units), than a 1-byte
file will take 4 KB of space on disk, although 4,095 of those bytes will be
empty. If you edit that file to 2,000 bytes and save it again, it will
still take 4 KB on disk. If you store a dozen 1-byte files on that disk,
the actual file size will be 12 bytes, but it will take 48 KB of space on
disk.

On average, every file will "waste" 1/2 of a cluster. No matter how many
full clusters it will take, the final cluster will almost always (4095 times
out of 4096) be a partial cluster, but it will use a full cluster on the
disk. So a disk with many small files will waste a lot more space than one
with a few large files, even if the total of the file sizes is the same.

If a 100-byte file is saved, it uses 4 KB. If that file is now edited to
1000 bytes and saved, it will normally go right back into the same 4 KB
cluster - no fragmentation occurs. Even if the file system puts it into a
different location, the 4 KB cluster will be unfragmented in its new
location - and the older file will be deleted, making its space available
for future use. If you edit and re-save a dozen times, with different file
lengths each time, the final file should not be fragmented, whether or not
the clusters are contiguous with each other. Each edit does not actually
edit the cluster byte-by-byte on disk; it reads the full cluster into
memory, makes the edit in memory, and then writes the new version as a full
new cluster to the disk. If the edited version is too big for this cluster,
the file system finds a bigger cluster or more to write the edited file;
this might make the new file non-contiguous.

As Gene said:
A non-contiguous file has the same size as the contiguous version of it.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"choro" wrote in message ...

On 17/09/2013 01:48, Gene E. Bloch wrote:
On Tue, 17 Sep 2013 00:08:23 +0100, choro wrote:

On 16/09/2013 22:17, Ed Cryer wrote:
Juan Wei wrote:
Ed Cryer has written on 9/16/2013 3:26 PM:
Juan Wei wrote:
choro has written on 9/15/2013 3:34 PM:
On 15/09/2013 19:28, wrote:
"Ken Blake" wrote in message

You might want to read this article I've written:
http://www.computorcompanion.com/LPMArticle.asp?ID=326

Nice sensible advice. Thx!

The only problem with imaging a single partition HD is the size of
the
image. Don't you run out of space on the destination drive pretty
quickly? (I've inferred that imaging copies the entire partition
rather
than just the blocks that are in use.)

No; just the used parts.

So the image is smaller than the partition?


Exactly. I have a 1GB C partition. Windows shows it as having 87GB used.
The latest Paragon saved image is 74GB. I have several saved images.
I also take Windows images. The latest is 80GB.

Ed

If I may just add...
An image file is already compressed, isn't it? So, it's got to be
smaller. Mind you the xcopy and xxcopy options I have mentioned in other
places on this thread are definitely NOT imaging. They are copies of the
original files but whereas the original might not be contiguous, the
pasted copy will be a contiguous file. And can therefore take up less
space on the HD. The more you add up something to a file and re-save it
the more defragged it can get.--
choro
*****

A non-contiguous file has the same size as the contiguous version of it.

A four volume book has the same total size whether or not it's put
contiguously on the shelf. The analogy is exact.

Not in MY experience. An original file saved umpteen times each time
with additions to the text may NOT be contiguous. Whereas if that file
is saved under another name and the original deleted it may well take up
less HD space EVEN THOUGH the actual file size might be the same.

This has got to do with wasted space with each addition or amendment to
the file. I always thought filesize and space taken on HD are two
different things though not necessarily all that far apart in space taken.
--
choro
*****

R. C. White wrote:
Hi, Steve.

I made several attempts to install Linux on my D: drive, but most of
them did not work, and the latest one, which did work, is not
recognised as D: by Windows.

I've already pleaded ignorance regarding Linux (including GRUB). But I
think that Linux, like Windows, has to depend on the Partition Table in
the MBR sector on the currently-defined boot device to define Disk # and
Partition #. Windows assigns "drive" letters to those partitions - not
to the entire disk, of course. But Windows probably does not tell Linux
what letters it has assigned. And vice-versa? And the Partition Table
itself knows NOTHING about drive LETTERS.

When you installed Linux on your "D: drive", which Disk # and Partition
# was that? When you boot Windows and run Disk Management, which letter
is assigned to that Disk#/Partition#?

...a program installed on the E drive keeps its registry on the C drive,

No. A program does not have a Registry. It makes entries into THE
Registry maintained by Windows. It is in the Boot Folder on the Boot
Volume, and this is USUALLY C:\Windows on Drive C:, but it can be on any
"drive". It can very well be E:\Windows, depending on the instructions
you gave to Windows' Setup.exe when you installed Windows - and whether
you booted from the Windows DVD or ran Setup from an existing Windows
installation.

but when I restore it from Acronis on a completely new disk with a
different partition size, it still manages to find it.

I've never used a program from Acronis, either. But when you restored
Windows to a new disk, you probably restored the System Partition, too,
and that contains the Boot Configuration Data (BCD), which tells the
startup file (bootmgr) where to find Windows. Changing the SIZE of a
partition does not change the letter that was assigned to it. A 500 GB
Drive C: shrunk to 8 or 80 GB is still Drive C:. And it may still be
the third partition on the second HDD, as shown in the Partition Table
in the System Partition, probably partition 1 on Disk 0. Of course, if
you restored only to Disk 1, then the System Partition on Disk 0 has not
been touched.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Steve Hayes" wrote in message
...

On Mon, 16 Sep 2013 10:00:11 -0500, "R. C. White" wrote:

Of course, most of this is of little or no interest to most users, who
never
get involved in multiple OSes - but many of us in newsgroups like this DO
get into such adventures. To lump us all together in discussing how, why
and whether to use multiple partitions is to overlook the real world
differences between us.

I found it quite interesting, nevertheless.

I made several attempts to install Linux on my D: drive, but most of
them did
not work, and the latest one, which did work, is not recognised as D: by
Windows.

Since my Drive 0 is now 500 Gigs rather than 8, I thought there was enough
room on it to repartition it, and create a D: drive there which I use
only for
photos.

After I repartitioned it, however the GRUB loader was confused, and
would not
load either OS.

I nearly panicked, then popped in the Lunux (Fedora) DVD, and thought to
reinstall it. I calmed my fears by simply putting on the Grub thingy, after
which everything worked again.

So my sysem of drive letters is historical, based on hardware and the space
available at the time I bought it. And others may have a different history,
and so different needs.

I know that a program installed on the E drive keeps its registry on the C
drive, but when I restore it from Acronis on a completely new disk with a
different partition size, it still manages to find it.

Linux can be installed in more than one way.

The install on my USB Flash key, is the closest you'd get to something
you could stick a drive letter on. That's because FAT32 is used for the
partition, and the partition contains a read-only image of sorts. To
handle the dynamic part (need to store things), a separate casper-rw
EXT3 file is kept. And if you install further software, the casper-rw
file is mounted as a loopback file system and used for the storage.
(That's a file that "looks like a disk".)

Now, if I plug that same USB key into my Windows desktop, it'll receive
a drive letter. Because of the FAT32.

If you want a native Linux format to have a drive letter, you'd use EXT2
during the install, then install EXT2IFS in Windows. Then, you can pick
the Linux partition and use the storage there. And a drive letter will be
assigned by Windows. That's because Windows is fooled into thinking the
EXT2 partition is a native Windows format. Without the EXT2IFS driver,
the partition is treated as a foreign one (presence acknowledged but
nothing more than block device access allowed).

http://en.wikipedia.org/wiki/Ext2IFS

*******

In terms of Linux boot characteristics:

1) Linux does not use the "boot flag". Other means are used.
2) Booting references can be either by block device (/dev/sda3)
or by UUID. I think the UUID idea, allows a partition to be
moved in the partition table, without screwing up the GRUB
references. On the downside, when a UUID breaks, it's a pain
to fix. Whereas /dev/sda3 type references, are easy.

http://linux.byexamples.com/archives...tab-with-uuid/
http://askubuntu.com/questions/17144...nother-machine

3) Linux native partitions would be of the EXT2/EXT3/EXT4 family.
Ordinary installs use those, and Windows doesn't recognize them.
But there are also various tricks for loading the OS in a
FAT32 partition, and still getting it to boot. It's just the
OS doesn't typically store things directly in the partition, but
with a layer of indirection (a loopback mounted file).

Linux uses the MBR (440 byte area).
Linux doesn't use the boot flag.
Linux stores stuff in the first track (after the MBR, and Windows doesn't care).
Linux stores stuff in its file system.
And each of those is referred to as a "GRUB stage".

http://en.wikipedia.org/wiki/GNU_GRUB

Paul

On Tue, 17 Sep 2013 14:11:01 -0500, "R. C. White"
wrote:


If your file system uses 4 KB clusters (aka allocation units), than a 1-byte
file will take 4 KB of space on disk, although 4,095 of those bytes will be
empty.


RC, although that used to be true, it no longer always is. For very
small files (don't ask me to define what "very small" means here; I
don't know) the data is not stored in a cluster, but in the MFT. So a
1-byte file takes up no space on the disk.

Hi, Ken.

Yes, I've read a little about that, but I don't understand it fully, so I
didn't try to explain it. And I'm not sure if it applies to the final
cluster of a long file, or only to a single-cluster file.

Thanks for reminding me.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Ken Blake" wrote in message
...

On Tue, 17 Sep 2013 14:11:01 -0500, "R. C. White"
wrote:


If your file system uses 4 KB clusters (aka allocation units), than a
1-byte
file will take 4 KB of space on disk, although 4,095 of those bytes will
be
empty.


RC, although that used to be true, it no longer always is. For very
small files (don't ask me to define what "very small" means here; I
don't know) the data is not stored in a cluster, but in the MFT. So a
1-byte file takes up no space on the disk.

On 17/09/2013 21:50, R. C. White wrote:
Hi, Ken.

Yes, I've read a little about that, but I don't understand it fully, so
I didn't try to explain it. And I'm not sure if it applies to the final
cluster of a long file, or only to a single-cluster file.

Thanks for reminding me.

Look guys, I don't claim to be a computer or computing expert. What I
learned, I learned on my own, by observing and experimenting and
occasional reading.

Files DO take up less space if they are saved in one go as opposed to
being re-edited and saved time and time again. And here is the proof...

One particular file I am working on is the English translation of a
historic novel. The translators have done a good job but the author has
still trusted me to edit the translation. Naturally this is a long,
laborious process. Not only one has to edit the English text but one has
got to compare the translation with the text in the original language
the novel was written it. Hence I have been editing the translation and
resaving it again and again as I go along. Of course I keep a pristine
copy of the original translation as well.

But here is the proof of the pudding...

The version of the file I am working on takes up X+3,520 Bytes of HD
space which. The the version of the file that I have been working on
and which I have just re-saved under a slightly different name takes up
less than X Bytes. In fact the version of the file saved over and over
again and again takes up around 4% MORE space on the HD. Of course this
is an insignificant saving of HD space when re-saving the file in ONE GO
under a different name which names it into a completely different file.

The same happens when xcopying or xxcopying. You DO gain some if
insignificant HD space when you xcopy or xxcopy.

I need no further proof than this little experiment I have just done to
convince me that what I have been saying all along is true. Now,
contiguity is another matter altogether.
--
choro
*****


RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Ken Blake" wrote in message
...

On Tue, 17 Sep 2013 14:11:01 -0500, "R. C. White"
wrote:


If your file system uses 4 KB clusters (aka allocation units), than a
1-byte
file will take 4 KB of space on disk, although 4,095 of those bytes
will be
empty.


RC, although that used to be true, it no longer always is. For very
small files (don't ask me to define what "very small" means here; I
don't know) the data is not stored in a cluster, but in the MFT. So a
1-byte file takes up no space on the disk.

On Tue, 17 Sep 2013 05:07:48 +0100, choro wrote:

A set of images will have several images of a file that has been changed
between incremental backups.

You can get the third one back if you have screwed things up in the last
two versions of a file.

I must admit you've got a point there. But is it worth all the bother
of having to restore one or several (!!!) just to be able to pick up the
right earlier version of a file?

It is not in any way difficult. Or to use your terminology, it is
absolutely no bother. Let me rephrase that: it is trivially easy.

Why not then use a much simpler method.

Because it can't get any simpler than the way it already works.

If you know, for instance, that the file you want is in the previous
incremental, you tell Macrium to mount that one and you now fetch the
file from it. You don't restore anything but the file you want to get
back. You don't even restore that - you just copy it from the mounted
backup, which looks just like a conventional drive. If you don't know
which of several incrementals has what you want, you can mount the
leading suspects and take a look.

Believe or not, any method that has several backups will of necessity
require you to figure out which is the one you want.

And you have completely ignored the fact that if you need an older
version of a file and don't have it, you can't get it back. OK, that
*is* a much simpler method - you just do nothing - but it's not what I
consider useful.

--
Gene E. Bloch (Stumbling Bloch)

On Tue, 17 Sep 2013 08:05:46 -0700, Ken Blake wrote:

I am generally against incremental backup. It backs up only those
things that need to be backed up, and that's good.

But what's bad is that if you restore from it, you get back files
you've deleted. That may not always be a problem, but it can be.

If you restore from an incremental backup, you only get the files that
are in that backup[1]. If it was deleted prior to a given backup, it
will be absent from that backup.

[1] People seem not to have figured this out: when Macrium, at least,
makes an incremental backup, the latest image file includes all the
information needed to completely reconstruct the disk as it existed at
the time of the backup. The latest file only includes changes. Unchanged
stuff is fetched from the earlier incrementals. Deleted stuff is not
fetched.

--
Gene E. Bloch (Stumbling Bloch)

On Tue, 17 Sep 2013 05:18:35 +0100, choro wrote:

On 17/09/2013 01:48, Gene E. Bloch wrote:
On Tue, 17 Sep 2013 00:08:23 +0100, choro wrote:

On 16/09/2013 22:17, Ed Cryer wrote:
Juan Wei wrote:
Ed Cryer has written on 9/16/2013 3:26 PM:
Juan Wei wrote:
choro has written on 9/15/2013 3:34 PM:
On 15/09/2013 19:28, wrote:
"Ken Blake" wrote in message

You might want to read this article I've written:
http://www.computorcompanion.com/LPMArticle.asp?ID=326

Nice sensible advice. Thx!

The only problem with imaging a single partition HD is the size of the
image. Don't you run out of space on the destination drive pretty
quickly? (I've inferred that imaging copies the entire partition rather
than just the blocks that are in use.)

No; just the used parts.

So the image is smaller than the partition?


Exactly. I have a 1GB C partition. Windows shows it as having 87GB used.
The latest Paragon saved image is 74GB. I have several saved images.
I also take Windows images. The latest is 80GB.

Ed

If I may just add...
An image file is already compressed, isn't it? So, it's got to be
smaller. Mind you the xcopy and xxcopy options I have mentioned in other
places on this thread are definitely NOT imaging. They are copies of the
original files but whereas the original might not be contiguous, the
pasted copy will be a contiguous file. And can therefore take up less
space on the HD. The more you add up something to a file and re-save it
the more defragged it can get.--
choro
*****

A non-contiguous file has the same size as the contiguous version of it.

A four volume book has the same total size whether or not it's put
contiguously on the shelf. The analogy is exact.

Not in MY experience. An original file saved umpteen times each time
with additions to the text may NOT be contiguous. Whereas if that file
is saved under another name and the original deleted it may well take up
less HD space EVEN THOUGH the actual file size might be the same.

This has got to do with wasted space with each addition or amendment to
the file. I always thought filesize and space taken on HD are two
different things though not necessarily all that far apart in space taken.

You are talking about how an application saves versions of its file.
This has nothing to do with disk fragmentation, which is a function of
the file system in use.

As the application puts various bits of data into a file, of course it
can make that file grow, but where that file goes on disk, including
whether it is fragmented, is managed by the FS.

To use my analogy, if you put some bookmarks in a book, it will grow
larger, but the total size of the four volumes will still not depend on
where or how they are shelved.

The mass will depend on their velocity, however, especially if they are
accelerated to relativistic speeds.

--
Gene E. Bloch (Stumbling Bloch)

On Tue, 17 Sep 2013 13:05:37 +0100, Ed Cryer wrote:

Gene E. Bloch wrote:
On Mon, 16 Sep 2013 20:07:43 -0400, Juan Wei wrote:

Yes, but it is something aking to a Chinese answer to an English
question. The image has got to be re-interpreted back to what we know as
files (with an S) and folders. One image file is one file of the whole
partition or disk or what have you.

So how is it that the image of a partition is smaller than the partition
itself?

There are only two reasons, both major, one obvious, one already
explained upthread.

1. The unused sectors (allocation blocks) on the source drive are not
copied into the image.

2. Most imaging programs compress the resulting file.


I'll add a 3. One of the reasons I like Paragon is that it ignores
paging and hibernation files; and these can be vast with today's normal
RAM sizes.

Ed

True of Macrium as well, but I didn't think of it :-)

Thanks.

--
Gene E. Bloch (Stumbling Bloch)

On Tue, 17 Sep 2013 12:13:27 +0100, choro wrote:

That would surely depend on the disk you are saving it to.

If it is a newly-formatted CD or DVD, yes, it would be as you say.

But if it is a hard disk with the empty space already fragmented, then the
copied file would be fragmented too.

You have a point there but certainly it would not be as fragmented as a
file saved 50 times with minor alterations.

You have no way of knowing that.

I'm exaggerating, but not by much. It depends utterly on the current
state of the disk, which can be ascertained, but not easily, and not
with the tools you're likely to be using, or for that matter, the ones
that I'm likely to be using.

--
Gene E. Bloch (Stumbling Bloch)