I have Win 7 x64 installed on C:\ a 120G SSD drive. I had FSX installed on its own dedicated 128 Gb SSD as E:\. That drive has now failed and will have to be replaced.

What do I need to do now? I can't uninstall stuff on my FSX drive since it's broken. Can I just reinstall everything on the new drive which will also be E:\ ? Or will I mess up the registry in that way ?

You should be fine to reinstall on E new drive.

note: did you check the cables on that drive: e-sata and power. Particularly the e-sata cables, some have clips others don't, and some drive do not have clip retainers etc...It happened to me, just thought I'd mention it.

Pierre

wait a sec - you might have some issues here.

First - if you are restoring from an image backup of your old E: drive, you are good to go. However , if you are doing a fresh INSTALL of FSX and add-ons you are going to run into some issues. On FSX and some of the add ons, the installer will see the registry entries and think that it is already installed. Hopefully the installer will give you the option of uninstalling and reinstalling automatically. Others will just install anyway and that is good. It's not a 'panic time' thing but something you should be aware of. If you have acceleration installed - you will have to uninstall Acceleration, then uninstall FSX and then reinstall in reverse order.

 

Vic

First - if you are restoring from an image backup of your old E: drive, you are good to go. Howeveradd ons, the installer will see the registry entries and think that it is already installed.

 

Actually I have regained contact with the drive although it doesn't work flawless. So I tried backing up the whole FSX directory. It worked with one reservation. About 10-20 files was not possible to backup. I wonder what might give the biggest problem? Using this partly flawed backup or reinstalling?

I might also mention that I have encountered a similar situation before. My OS drive failed and I had FS9 on another non OS drive. After reinstalling Win 7 and running a registry fix for FS9 it worked apart from some addons which I reinstalled and then they worked. An example of this was Leonardo Maddog Pro.

I'd restore hat you have and try an FSX repair install. If that doesn't clean up the missing files, they probably belong to an add-on and you can try them one by one and see what fails. It saves time over a complete reinstall but a reinstall would be cleaner.

 

Vic

I have tried another FSX backup and now I have figured out which files that were not copied. They were 13 in total giving the message 'Can't read from source file or disk' and selecting Try again didn't help in any case. Out of these only one file seem to be FSX native and that is voronoi.dat. The other files belongs to one of the following addons, MyTraffic ORBX scenery or PMDG 737NGX.

Good luck with this it may be best to start over completely. This is why I'm pretty committed for my next build to put both the OS and FSX on one larger SSD. This way a complete clone can be done on a cheap HDD for a quick fix when disaster strikes. I'm thinking from what I've read higher end SSD's will support OS and FSX on one drive much better than HDD's do. Right now I have OS and FSX on separate HDD's and quite frankly have not done well w/ make backups of BOTH drives at the same time. Cloning one drive is much easier to do.

I do not understand why there is a reluctance to have FSX and Windows on the same SSD. I thought that for FSX getting scenery data it applied to Windows to actually deal with the SSD. The bottom line is that FSX does not access the SSD in reality.

Two possible reasons.

 

- Parallel, independent data paths.. this means that WIndows can do it's thing and FSX can do it's thing without interfering with one another. This mainly comes from the HDD days where there was physical movement of the actuator arm involved.

 

- Good Housekeeping... a clean FSX drive can be updated, defragged etc independently of the C: drive.

 

For all practical purposes, FSX does access the SSD directly.

That is the whole point. FSX never accesses the disk directly. It asks Windows to perform that task. That way FSX never knows what kind of storage system you have and all the specialized interface code resides in Windows. Further I would guess that the code, in Windows, resides in memory as part of the initial boot/load process. Thus there should be no additional disk access by Windows to talk to a disk whether it be RAID, single 7200rpm drive, a 10000 rpm drive or a simple stick of flash memory in a USB port. FSX does not care and does not know these details and quirks of each device. So, FSX NEVER access a disk. It has Windows do that. Thus if they co-exist on the same SSD there should be no change in performance for normal FSX operation. The data pathway through the Bridge device is only used by Windows.

 

I believe this is the way it works today. I have not coded operating systems for a very long time. Then all that stuff was a design goal. It could be a lot different than I imagine. So take the ramblings of the elderly with a grain of salt.

Technically, you are 100% correct, but who executes the low level disk access is not really what I was thinking of..

 

Windows has it's own processes that it likes to execute, irrespective of what FSX needs it to do.

 

Just watch a Procmon trace and see how Windows processes suddenly decide to do stuff, and access the C: disk..

 

It is nice to have those OS processes operate on a separate device from the FSX disk which

is busy enough with scenery loading etc..

We're splitting nanoseconds here but simplistically what I think we are looking at is the difference between inline and parallel processing. If OS & FSX reside on the same drive, and both the OS and FSX send a command to that drive, one of them will have to wait until the other process is through. However, if both are on different devices, they can be processed in parallel essentially and both execute at the same time. that is a large generalization but might give food for thought.

 

Vic

That is pretty much it for SSDs.

 

For HDDs, the mechanical actuator has to be moved to satisfy the request and that is tens of milliseconds, not nanoseconds.

that is tens of milliseconds, not nanoseconds.

 

I shall change your name to Bert Picky, Picky, Picky!

 

Works for me!

 

B)