I have six hard drives in my system - four internal, and two external that are only powered up occasionally for backups.

My F:> drive is a two-terabyte internal drive that is backed up to my identical external L:> drive. F:> is somehow listed as a system drive. It is entirely data, containing nothing but a few audio books. (Few = 3877 books, 1769 gigabytes. )

Because it is shown as a system drive, it seems to be using up 29GB more space than the L:> drive, and when I run backups it throws errors trying to back up a very few files that apparently are involved in this "system" business. Not a great problem, just annoying.

What do I need to do to convince the computer that the F:> drive is not a system drive?

tanstaafl.

Are either of these drives indexed for searching?

All drives except for "L" and "M" (the two external drives) are indexed. I didn't know if I should index the external drives, since 99% of the time they are not turned on.

tanstaafl.

http://windows.microsoft.com/en-gb/windows/what-are-system-boot-partitions#1TC=windows-7

It has a hidden partition on it used during the boot process.

I don't know how valid any of the advice on this thread is, but it might be helpful:

http://forums.mydigitallife.info/threads/9830-D-drive-status-is-System-Active-why

I don't think it's a hidden partition. Otherwise capacity would/should show differently. Hidden partitions should still show in Disk Manager too.

I don't think that is the case. According to the article you linked, that would apply if:

Your computer has more than one operating system installed...
or
Your computer is set up to run BitLocker Drive Encryption.

Neither is the case with my computer. The F:> and the L:> drives are strictly data drives, both of them WD20EARS 2-TB drives. The only differences I can see in their setup is that one of them shows a status of "System, Active" and the other does not, and the "System, Active" drive has 29 GB less free space. Well, 31GB now, after clearing the recycle bins.

Except for the extra files caused by/created for the "System, Active" status the two drives are byte for byte identical, but several of those files don't get backed up to the L:> drive because of "...file in use.." error. These differences only account for about 55 kilobytes, however, so... perhaps you are right after all, because something is eating up those 31 missing gigabytes.

How would I find a hidden partition?

tanstaafl.

Edit: Possibly this? ? Then I would reformat the drive and copy just the files I want from the backup?

db

Is it possible one of the following is in the internal drive:

MBR
BOOT directory
bootmgr file
pagefile.sys file

?

What is in the drive root if you issue the "dir /a" command?

and also

hiberfil.sys
pagefile.sys
swapfile.sys
Recovery (dir)

F:\dir /a:
LIBRARY
System Volume Information

and that's it.

There was a bootmgr file, and another boot-related file, but they are gone now. I spent an hour and a half with the computer at the computer store today and they were able, with considerable effort and a bit of risk (possibility of having to format the C:> drive and reinstall Windows) change the F:> drive from "System, Active..." to just plain "Healthy Primary Partition" like all the other data drives.

hiberfil.sys, pagefile.sys, swapfile.sys are all on the C:> drive and have been all along.

I disabled hibernation and got rid of the hiberfil.sys file, picked up 5GB of space on my SSD, and am working on moving the pagefile.sys and swapfile.sys files over to my D:> drive. I know it can be done, but so far the instructions I have found have been confusing.

After getting rid of the "System, Active" parameters on the F:> drive, I formatted it and as I type this am restoring it from backup. 1.72 TB takes a long time...

But that brings up another question. After a fresh format on the F:> drive, I immediately checked filespace, and somewhat to my surprise there was 237MB shown as "Used Space". Windows Explorer showed nothing on that drive other than the empty System Volume Information file. Now, that's a big improvement over the 31.4 GB that used to be hiding from me, but I AM a bit curious as to what's eating that 237 MB.

tanstaafl.

Keep in mind disabling hibernation on Windows 8 also disables the fast boot feature.

If you mean that you are planning to move your swap files to a winchester disk instead of the SSD, I think you won't want to do that. If I understand the way SSDs work, I think your computer will work faster if you keep your swap on the SSD.

I would guess that the 237MB "used" is for the data structures required to implement / manage / maintain the filesystem. Block lists, inode equivalents, etc. Normal overhead.

For swap space many, many people say NEVER PUT SWAP ON AN SSD. I don't know much at all about how Microsoft does things, but if I had swap enabled on my Linux machines (I don't, because they have plenty [8GB+] of RAM), then I would definitely put it on the SSDs to avoid major slowdowns.

I guess I don't know much about Swap and SSDs, then. I'd never heard anyone say "don't put swap on SSD" before. I wonder why some people say that?

Also, there are plenty of computers nowadays which come with an SSD as the only disk drive, so you can't avoid that situation on some computers.

So far, Google tells me that the people who say "Don't Put Swap On SSD" are trying to improve the life span of your SSD drive by reducing the number of write cycles.

But others are saying that fears about needing to limit the read/write cycles on SSDs pretty much only apply to older SSDs. Newer SSDs, they say, don't have that problem.

Is that the only reason?

The reason for this is because swap does a lot a small read/writes on the disk, and (because this process was never optimized for SSD) uses the same sectors a lot. This is not a problem for ordinary HD's, but in the case of SSD's, this would mean certain memory cells would wear out faster, effectively shortening the life span of the SSD a great deal. More recent SSD's firmwares contain specific algorythms that try to write to all the cells of the SSD an equal amount of times, while also trying to avoid certain cells getting written more to than others.

In any case swap is not necessary when you have enough RAM, and certainly not when the OS is on an SSD since that's a multitude times faster in terms of speed (and certainly in terms of access times) than an old school hard disk.


Yes.

I keep swap on a winchester even though the machine also has an SSD because I like to get the acoustic indication that it's started swapping...

Peter

Exactly backwards, that "explanation".
On a mechanical HDD, the same sectors do get rewritten over and over in swap space. On an SSD, they don't, because the SSD firmware is continually doing "wear leveling" to prevent it.

Cheers

Yeah, that was the "reason". Newer drives tend to have much larger capacities than the early 4GB, 8GB etc.. models. 128GB is typical today, giving the SSD firmware much more flash memory to distribute the writes across (wear leveling), making it a non-issue.

Yes, this is exactly what I wrote further on in my explanation:

Maybe I should have stressed better that this is only the case for more recent SSD's. The first models didn't have this "wear levelling" feature. That "don't put swap on SSD's"-warning also originated in that pre-wear levelling era and is not such an issue anymore nowadays.

But you knew that, of course.

So, if I'm reading this right, then...

- If Doug is using a Windows computer and thus has no choice but to use swap (which I realize is different in many ways from the Linux version of swap)...

- And Doug is using a fairly new SSD drive with a significant amount of space so that the wear-leveling feature will protect him over a long period of time...

- And SSDs are, in most or all cases, significantly faster than winchester drives....

... Then Doug should leave his swap on the SSD drive for best performance and reliability.

My thinking was to leave more "disk" space free on the SSD by moving those files. And then it occurred to me that I am using less than 30GB on that drive, with more than 80GB still free. I store NO data on that drive, other than a few temporary files. Why was I obsessing over freeing up another gigabyte and a half that I would never use?

tanstaafl.

With the most recent SSD's which support "wear levelling", it shouldn't make any noticeable difference with regards to the lifespan of the SSD, so yes, it should be ok.

On my own system, even though I use a recent SSD, I've put the swap on the data drive (a second disk, which is an ordinary winchester). Just to be sure.

In this case, "most recent SSDs" really means "any SATA SSD ever produced", as well as most CompactFlash cards larger than a few megabytes, etc..

Cheers

I bet wear leveling is why my fragmentation map looks like the attached.

Since there is virtually no penalty in reading fragmented sectors vs contiguous sectors in an SSD, defragging is counter-productive.

And now, for something completely different... I saved the screenshot below with my graphics editor, "Paint.Net", whose default save format is .png. Then I realized I should save it as a .jpg to get reduced file size, and did so. To my surprise, the lossy .jpg turned out to be considerably larger (7x bigger) than the lossless .png.

Odd.

tanstaafl.

It's not really so odd. Different formats for different purposes. JPG was created for use on photographs, which typically have lots of high-frequency data (leaves in trees, sensor noise, etc), and gradual transitions between objects (blurs, etc). PNG was a replacement for GIF images, which were typically graphics (as in graphic design) characterized by high contrast/sharp color transitions, and very little high-frequency data. And don't forget that "lossless" isn't the same as "uncompressed."

Yup, exactly.

That screen shot is characterized by large blocks of flat single colors with no color variation within the block. For instance the white areas are 255/255/255 all the way across, not one data bit is different. Formats like GIF and PNG eat that kind of data for breakfast.

You would probably get similar results by saving it as an uncompressed bitmap and zipping it. Which would be similar to what PNG is doing to begin with, under the covers.

We could get into an even more detailed discussion of types of data compression... run length encoding, Lempel-Ziv-Welch, the various lossy methods, etc, but the shorthand is "flat color computer screen shots"=PNG lossless, "photos or complex color variation"=JPG Lossy, will get you the best compression. The Wikipedia article on PNG is good at explaining.

If only, when they made PNG, they could have made it a truly universal file format:
- The option for lossy or lossless compression, so it could replace JPG instead of supplant it.
- The option for palletized images and animations like GIF.

If they had done that, I think we'd all be using PNG for everything now. Ah well.

Not really. The real reason your frag map looks like scattered rice is because SSDs have a seek time of about zero, so there's less need for data to be stored sequentially in flash for fast access. Not that the frag map shows the real layout in flash anyway.

Cheers

Mark is, as usual, absolutely correct on this. I just thought I'd emphasise this point: the layout of blocks that the OS sees bears little relation to the layout of blocks in flash.

For example, if the OS writes to (what it thinks is) block #12345, which is currently mapped (by the SSD controller) to #98765, and the SSD controller decides it needs some wear leveling, it might move that data to block #50943. The OS still thinks the data's on block #12345, in its view of the world, but it's been moved in flash.

Spinning iron disks actually do something similar for bad sector remapping, and the OS (usually) doesn't know anything about that either. This is not new.

What it means is that what looks like a nicely-defragmented file in the OS's linear view of the disk might actually be scattered all over the flash blocks or physical sectors.