Disk Partitioning

[R. C. White]

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
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Steve Hayes" wrote in message

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.

 

[R. C. White]

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:
RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"choro" wrote in message

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.

 

[Paul]

Hi, Steve.


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


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.


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
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Steve Hayes" wrote in message



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/321/fstab-with-uuid/
http://askubuntu.com/questions/171446/how-to-fix-the-uuid-in-grub-after-restore-from-another-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

 

[Ken Blake]

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.

 

[R. C. White]

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
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"Ken Blake" wrote in message

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.

 

[choro]

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.

 

[Gene E. Bloch]

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]

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]

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]

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]

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]

But here is the proof of the pudding...

See my remarks in

Message-ID: <[email protected]>

addressing another post where you stated the same opinion.

 

[Robin Bignall]

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.

Same with ShadowProtect. But to restore from any given incremental, you
have to have all of the preceding incrementals and the original full
backup that this is an incremental of. I think we're probably saying
the same thing.

 

[Gene E. Bloch]

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.

Same with ShadowProtect. But to restore from any given incremental, you
have to have all of the preceding incrementals and the original full
backup that this is an incremental of. I think we're probably saying
the same thing.

Probably. But you have clarified my remarks for those who didn't read
between the lines to figure out what I should have said

Thanks for the correction.

 

[Ken Blake]

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.

Of course. But if you first backed up and then deleted, you get back
the deleted files. And it's very easy to not remember that you had
deleted them.

 

[Ken Blake]

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.

Nor do I, which is why I didn't try to go onto details.

And I'm not sure if it applies to the final
cluster of a long file, or only to a single-cluster file.

As far as I know, only small, single-cluster files.

Thanks for reminding me.

You're welcome. Glad to help.

 

[Gene E. Bloch]

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.

Of course. But if you first backed up and then deleted, you get back
the deleted files. And it's very easy to not remember that you had
deleted them.

OK, but I didn't think that's what you meant. Also, please note that I
specified "if it was deleted prior to a given backup..."

But of course, all of the above is true of *any* backup method, not just
image backups, incremental or otherwise.

 

[R. C. White]

Hi, Choro.

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.

As an English-only speaking American, I greatly admire people who are fluent
in multiple languages. I took Spanish in college; made A's; couldn't speak
Spanish at the end of the course and still can't, 60 years later. :>(
Picked up a smattering of other languages, but can't read or speak more than
the simplest sentence in any of them. I'm actually picking up more Spanish
now from just reading product labels in both languages. ;<}

Which program(s) are you using to edit and translate the text? Perhaps the
program:
1. Saves both the original and the translation, or at least some of it.
2. Saves notes you might make about ambiguities or other items.
3. Saves notes about the history and progress of the translation.

These features could cause each successive Save to be a little bigger - or
smaller.

Perhaps others here have experience with such software and can add more
insight than I can.

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3508.0205) in Win8 Pro


"choro" wrote in message

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.

 

[mikels]

Long Path Tool works excellent to copy or delete, long path files quickly. It's very easy to use for everyone. You can try it and see the result yourself. good luck!

 

[Randy_Vran]

hi, you can also try “Long Path Tool” it really works for me. It is free and easy to utilize.