Author Topic: New Windows install - How should I organize SSD, HDD, user folders? (Read 17279 times)

TucknDar · « **on:** December 28, 2012, 03:37 PM »

Recently bought a new laptop (may be returning because of some pixel errors, but that's another topic...), and I'm installing Windows 8 on it. Not really looking for opinions on choice of OS, but definitely looking for some help in organizing this thing.

It's the first time I have a computer with two drives and Win8 will obviously go on the SSD (120GB), but unsure of pretty much the rest. I'm thinking that program files will go on the SSD (default c:\Program Files\) except portable apps (something like c:\Programs\). But what would you recommend for the user profiles? I'll be the only one using the computer, but should I move the complete Users folder to HDD, only my profile or nothing? There are tons of guides to move and symlink the users folder, but I'm really unsure if that's the best way, especially since having tested this, I get some issues with System Restore (not in itself a deal breaker, but I'm worried that something more important may break eventually).

Should I let Windows do whatever it wants with my user profile, but create my own Docs folder and use this instead of My Documents? What about AppData...?

With my Win7 machine I redirected C:\Users to D:\Users which has technically worked fine, but I'm not sure if there's any point in doing this as opposed to just make cusom Docs folders.

There's some good advice and discussion in this thread: SSD usage recommendations - https://www.donation...ex.php?topic=25795.0
I do wonder, however, if there's any new considerations since that thread was last posted in? Also, I'd love to hear how other Win8 users have their system setup.

Shades · « **Reply #1 on:** December 28, 2012, 05:08 PM »

With a SSD drive I would make sure that the Windows and/or application temp folders are not on it. Althoough this might mean that you lose a little bit of performance, it should add to the longevity of the drive.

This kind of setup makes the most sense (to me at least), given the current price level of these drives. Besides, I don't think the performance-drop of your system will be that much. Depends a bit on what you want to use your system for, I'll guess.

TucknDar · « **Reply #2 on:** December 28, 2012, 05:16 PM »

I've read that newer SSD drives are very durable, so is r/w operations and drive longevity still a valid concern? If I decide to move Temp folders, could these be put in a ram disk? I've got 12GB of RAM, so spending 1GB of RAM on a ramdisk may be a way to do it.

f0dder · « **Reply #3 on:** December 28, 2012, 05:54 PM »

I'd say disable the pagefile (or relocate to your HDD; it shouldn't be hit that much with 12 gigs of ram, so you shouldn't see a speed hit). RAM disk for %TMP% and %TEMP% (both the system and user environment variables) is nice, not only does it reduce wear&tear on the SSD, but can be a nice speed increase of some things. I find that at 1gig ramdisk works pretty well for my TEMP and FireFox profile (backed up, of course). I use SoftPerfect now, persistent disk, and it works pretty well.

As for other stuff, do what suits you best

- I've got my home workstation SSD split in a ~64gig partition for Windows + most applications, and a ~47gig for my documents, sourcecode, et cetera. Makes OS reinstall a bit easier, but with a small SSD micro-managing free space can be annoying. Games and "bulk" data goes on a 300gig (well, 279gig in non-SI units

).

For my work laptop, I have one single partition on my SSD for most stuff, but an I/O busy (and huge!) content repository on the old HDD; the software might benefit somewhat from the (much) faster SSD I/O, but I'm afraid it's so write-busy that the SSD would be worn down too faster.

I've read that newer SSD drives are very durable, so is r/w operations and drive longevity still a valid concern?
-TucknDar (December 28, 2012, 05:16 PM)

I do wonder - haven't heard of any (normal) cases where erase cycles have been used up (which ought to happen gracefully, and still allowing you to read the cells), all the deaths I've seen (and the two I've experienced myself) have been random out-of-the-blue deaths with no warning (HDDs usually start sounding weird, or drop from UDMA to PIO speeds which you will notice).

So when you move to SSD, backups will be even more important than with HDDs. Be sure to use something that runs continuously.

Renegade · « **Reply #4 on:** December 28, 2012, 06:12 PM »

One problem that you cannot escape is that Windows stores all kinds of baggage that cannot be safely removed from the system drive. Your Windows installation becomes more and more bloated over time, so start thinking about that and plan for your system drive to become virtually unusable at some point. It WILL happen. 383 KB here and 68 MB there and another 138 MB here and maybe a GB over there... It all adds up, and you risk destabilizing your system if you start farting around with moving/deleting those files.

I've just replaced a 128 GB SSD with a 256 GB SSD for pretty much that reason. I kept the OS, programs, and a small amount of current work/files on the system drive, with most files being on externals/NAS.

I figure that if at all possible, portable software is the best way to go. This insanity with the way many programs get installed on Windows with fixed paths and all that silliness, well, it just kills any real potential to stay properly organised.

I wouldn't worry about partitioning the SSD though. SSDs don't suffer from fragmentation like HDDs, so you have no worries there. Defragmentation of an SSD is counterproductive. So, you're pretty much left with the best option being just to leave it as a single volume, unless you have some kind of an organizational reason that would override how quickly a Windows installation can get bloated on a small drive.

Oh, do keep in mind that I've had to install some programs that take up multiple GB of space, e.g. Adobe Creative Suite, Visual Studio, etc. So, I kind of trashed a bit of the storage that way.

4wd · « **Reply #5 on:** December 28, 2012, 06:22 PM »

FWIW, over at Xtreme Systems they're doing accelerated endurance, (ie. continuous write/read), testing of a few SSDs.

SSD Write Endurance 25nm Vs 34nm

They got over 6PiB of writes from a 256GB Samsung 830, (post #5393), before it died - I'm guessing that under normal circumstances it will last quite a few years.

It was on continuously for 3775 hours and died after a power cycle, (post #5400), 70% of its spare blocks were still free.

ADDENDUM: For some reason the links to the specific posts just took you to the last page so I've removed them and added the thread post numbers.

f0dder · « **Reply #6 on:** December 28, 2012, 06:52 PM »

I wouldn't worry about partitioning the SSD though. SSDs don't suffer from fragmentation like HDDs, so you have no worries there
-Renegade (December 28, 2012, 06:12 PM)

Fragmentation does reduce performance on SSDs - not nearly as much as on a HDD, but we're still talking significant performance drops. Like, a 240gig Intel-520 that drops from ~512MB/s sequential read to ~25MB/s 4k-random. Such massive drops would obviously require heavily fragmented files, though

I wouldn't defragment an SSD, though. Perhaps defragmenting single heavily-fragmented files (SysInternals' contig.exe is nice). If the entire filesystem ended up heavily fragmented (and performance measuring indicated it needed defragmenting), I would make an image, defrag the image, and transfer it back (caveat: this might mess up the wear allocation stuff unless you happen to find an imaging program that can do something intelligent with the SSD TRIM command. I haven't had the need for filesystem defrag, so I haven't done the research.)

4wd: thanks for the link, lots of data there

. It's scary how the drivers tend to just... die. I wonder if there's a lot of stress on electronics during a power cycle, and whether that's a more likely death cause than wearing out the NAND cells, at least for non-heavy use?

4wd · « **Reply #7 on:** December 28, 2012, 07:52 PM »

4wd: thanks for the link, lots of data there .
-f0dder (December 28, 2012, 06:52 PM)

I changed it to add post numbers since the links didn't work properly.

Buy Samsung

I wonder if there's a lot of stress on electronics during a power cycle, and whether that's a more likely death cause than wearing out the NAND cells, at least for non-heavy use?

Most of my electronic stuff has died at power on over the years - there may have been a slight deterioration of performance, (maybe a bit of snow in the TV picture, PSU gone out of spec, etc), but it always seems to be at power on when something has permanently failed. Being powered on for hours at a time causes component wear, (electrolytics may "dry" out, resistors increase resistance, etc), and repeated power on/off, (with attendant heat/cool cycle), pushes them along to being marginal, so voltages may start creeping up, etc - then at the next power on you have inrush current which is over what the device normally uses and...bang!

Turn it on, leave it on - probably the best way to achieve longevity.

TucknDar · « **Reply #8 on:** December 29, 2012, 01:13 PM »

I've got my home workstation SSD split in a ~64gig partition for Windows + most applications, and a ~47gig for my documents, sourcecode, et cetera. Makes OS reinstall a bit easier, but with a small SSD micro-managing free space can be annoying. Games and "bulk" data goes on a 300gig (well, 279gig in non-SI units ).
-f0dder (December 28, 2012, 05:54 PM)

Hadn't thought of partitioning the SDD. Did you symlink the documents from the system partition, or just use a custom documents folder?

I guess my main concern would be the AppData folder, which I hope to contain within reasonable size, and I'm leaning towards custom My [stuff] folders and add these to the corresponding libraries.

Backup is certainly one reason why I'm looking to get this right from the start, but also to have a fairly good overview over my files. My current system is a mess, and I really don't want to end up with this mess again. I'll probably go with one of the suggested backup procedures found in a few threads on here (Clean System image, System + important software image, monthly system image, daily important file backup to cloud).

Thanks for some good advice, folks

Carol Haynes · « **Reply #9 on:** December 29, 2012, 01:41 PM »

Can I add a question to this ...

I am using an APC UPS to protect my system but the APC software requires having hibernation enabled to work. The free version of the software doesn't come with the ability to use command lines when the UPS is triggered - otherwise I could simply do a force shutdown.

Anyone any idea how to move the hibernation file off the C: drive?

I have managed to reduce the footprint of the hiberfil.sys but it is still 50% of system memory which wastes a lot of space on an SSD.

f0dder · « **Reply #10 on:** December 29, 2012, 06:42 PM »

Tuck, I think I just chose "move folder" for My Documents, can't really remember. For the most part, I leave AppData and the likes in place, but for a few programs that for some unfathomable reason store way too much data there, I've done some NTFS Junctions - either to my SSD data partition, to my Velociraptor (for large stuff), or to my ramdisk (firefox profile, Website Watcher).

Anyone any idea how to move the hibernation file off the C: drive?
-Carol Haynes (December 29, 2012, 01:41 PM)

By choosing another partition as the boot partition

- I'm not sure there's any other way. Haven't done intensive research, but look here - basically, Raymond Chen says it can't be done, and...

Again, it's another chicken-and-egg problem: to load the hibernation file, you need the file system driver, but the file system driver is in the hibernation file. If you keep the hibernation file in the root directory of the boot drive, the miniature file system driver can be used instead.

But perhaps you can do some really black magic with bcdedit?

4wd · « **Reply #11 on:** December 29, 2012, 06:56 PM »

The free version of the software doesn't come with the ability to use command lines when the UPS is triggered - otherwise I could simply do a force shutdown.
-Carol Haynes (December 29, 2012, 01:41 PM)

Use different software, Apcupsd ?

Doesn't Windows detect when an UPS is connected, (via USB) ?

And if so, might there not be an setting you can change under Advanced Power Options to determine what action to take rather than utilise APCs limited software.

Haven't done intensive research, but look here - basically, Raymond Chen says it can't be done, and...
Again, it's another chicken-and-egg problem: to load the hibernation file, you need the file system driver, but the file system driver is in the hibernation file. If you keep the hibernation file in the root directory of the boot drive, the miniature file system driver can be used instead.
-f0dder (December 29, 2012, 06:42 PM)

Beat me to it, was going to point to that

But perhaps you can do some really black magic with bcdedit?

Wouldn't make any difference if you did fiddle around with BCD, it only contains the info concerning reading the hiberfil.sys file, (and apparently editing it won't make it work neither will creating links - it's been tried).

Writing of the hiberfil.sys file is performed by some other function, (ie. hard-coded), so it will always go to the same place.

Carol Haynes · « **Reply #12 on:** December 29, 2012, 07:28 PM »

Thanks - I will check out Advanced Power settings.

Changing the boot drive makes no difference - I currently have a multiboot setup (using BCDedit) with an SSD copy of Windows 7 and another on a hard disk. The hard disk is the boot device in the bios but Windows still insists on having a hiberfil.sys for each windows setup. Frustrating.

You'd think it wouldn't be hard to have a tiny hiberfil.sys on the C: drive for each windows that points to a file on a user defined partition if required.

TucknDar · « **Reply #13 on:** December 30, 2012, 04:14 AM »

Thanks again! I'm getting there

Now just need to look at those pixel errors...

f0dder · « **Reply #14 on:** December 30, 2012, 07:31 AM »

But perhaps you can do some really black magic with bcdedit?
-f0dder (December 29, 2012, 06:42 PM)
Wouldn't make any difference if you did fiddle around with BCD, it only contains the info concerning reading the hiberfil.sys file, (and apparently editing it won't make it work neither will creating links - it's been tried).
-4wd (December 29, 2012, 06:56 PM)

You're probably right - at best, you might have been able to move it to the root of another partition (and/or perhaps changing name) - but the minimal NTFS driver is probably limited to the boot partition as well. Iirc it also is limited to the root directory, and doesn't support anything but filesystem basics (no junctions and symlinks, at least used to not support compression in XP... hardlinks might be supported since they're a very fundemental feature).

Writing of the hiberfil.sys file is performed by some other function, (ie. hard-coded), so it will always go to the same place.
-4wd (December 29, 2012, 06:56 PM)

I wonder what level of NTFS support is available to that code? Perhaps the part can either be hacked to write to some other location, or supports symlinks or junctions?

Changing the boot drive makes no difference - I currently have a multiboot setup (using BCDedit) with an SSD copy of Windows 7 and another on a hard disk. The hard disk is the boot device in the bios but Windows still insists on having a hiberfil.sys for each windows setup. Frustrating.
-Carol Haynes (December 29, 2012, 07:28 PM)

Is the BIOS boot drive the same as the Windows boot drive, though? I would expect the Windows boot drive to be the one that you're booting Windows from

You'd think it wouldn't be hard to have a tiny hiberfil.sys on the C: drive for each windows that points to a file on a user defined partition if required.
-Carol Haynes (December 29, 2012, 07:28 PM)

Except that the hibernation file needs to be loaded pretty early in the boot process, and while a few extra features could probably be squeezed in, you have to strike a balance somewhere - the full NTFS.SYS is ~1.6meg on my system.

I guess I should find the time to read up on the NT boot process, I just realized that I've forgotten exactly what happens at which time

Stoic Joker · « **Reply #15 on:** December 30, 2012, 09:28 AM »

Doesn't Windows detect when an UPS is connected, (via USB) ?

And if so, might there not be an setting you can change under Advanced Power Options to determine what action to take rather than utilise APCs limited software.
-4wd (December 29, 2012, 06:56 PM)

Sure does, that's all I've ever used. The bundled UPS software is usually to bloated and ugly to look at, so I've always just let windows handle the UPS's time to sleep/shutdown battery level events.

Jibz · « **Reply #16 on:** December 31, 2012, 09:56 AM »

I'd say disable the pagefile (or relocate to your HDD; it shouldn't be hit that much with 12 gigs of ram, so you shouldn't see a speed hit). RAM disk for %TMP% and %TEMP% (both the system and user environment variables) is nice, not only does it reduce wear&tear on the SSD, but can be a nice speed increase of some things. I find that at 1gig ramdisk works pretty well for my TEMP and FireFox profile (backed up, of course). I use SoftPerfect now, persistent disk, and it works pretty well.
-f0dder (December 28, 2012, 05:54 PM)

Have you ever run into any problems with installers or windows update like the ones mentioned here and here?

4wd · « **Reply #17 on:** December 31, 2012, 07:28 PM »

Have you ever run into any problems with installers or windows update like the ones mentioned here and here?
-Jibz (December 31, 2012, 09:56 AM)

Interesting, I can't say I've ever hit either of those problems and unlike f0dder, I use a non-persistent RAMdisk - System/User Temp and IE cache directories are located on it and at reboot/shutdown everything just vanishes.

Pale Moon, (Firefox), is set to not use disk based cache at all, (browser.cache.disk.enable = False), and profile remains in the User folder on SSD.

Program installs I've done that required a reboot are few, (Agnitum OSS is the only one I can think of off-hand), but they worked.

f0dder · « **Reply #18 on:** January 02, 2013, 12:56 PM »

Have you ever run into any problems with installers or windows update like the ones mentioned here and here?
-Jibz (December 31, 2012, 09:56 AM)

Nope - installers that fail when %TEMP% is on a different partition than the install folder would be majorly b0rked. Ones that rely on %TEMP% existing across a reboot are also lame, IMHO, but they do exist - doesn't bite me since I use a persistent ramdisk, though.

Only issue I've run into has been lame installers that insist on extracting their (huge) payload to %TEMP% before moving/copying to target folder, instead of extracting directly - the nvidia drivers (damn huge mess, GPU drivers these days are a mini-OS of their own O_o) fall into this category. But that's (at least in case of nvidia setup) fixable by launching the installer with TEMP/TMP pointing to a location with more free space.

Also: the thread from which the specific guru3d post you link is to about storing the pagefile on a ramdisk. This is utterly moronic, unless you're on a 32bit Windows and have memory Windows refuses to use (because of the 4GB-physical memory limit). Being on 32bit Windows with >4GB ram is also pretty moronic, at least if you have enough >4GB ram that you could be interested in putting the pagefile there... <=4GB and you typically wouldn't have enough "shadow" memory that it's safe for pagefile usage.

TucknDar · « **Reply #19 on:** January 27, 2013, 01:33 AM »

Finally got my new computer, now with no pixel errors, thankfully.

I've decided to partition both disks in two, with about ~75GB on the SSD for Windows + apps. I also left a ~40GB partition on the HDD for system images (to be transferred to an external disc eventually).

I'll use the library function for documents, pictures, etc and try to find some sort of system for using both the "data partition" on the SSD and the HDD for my files.

Thanks for the help and also for the mention of RamDisk. I'll try to use that as well