I see couple good arguments at present, against RAIDing SSDs for FS.First and foremost is that the TRIM command--needed to communicate empty block info from the OS file system to the SSD firmware--doesn't work with RAID configurations. I don't know of any at this point that can pass TRIM commands from the OS through the RAID controller to the drives. That's a huge negative.Second, RAID is most useful for increased throughput, because it spreads the data in parallel across several I/O channels. FS doesn't generally make use of that very well, as its file activity is predominantly large numbers of smallish files. What FS needs to shine is low random access time, and RAID configs are actually a bit slower in their random access numbers than single drives because of the interdevice syncing that has to occur to move data across the bus. It should also be noted that many of the high-capacity SSDs are (internally) RAID-like configs being controlled by a common controller chip...they are typically better performers in the access department than independent PCIe devices RAIDed together. They are also TRIM-capable.The one notable exception is those using humongous photoreal scenery databases--the increased throughput of a RAID array can be helpful moving massive photoscenery files.

Yes, you're quite right, forgot about the TRIM command not running on RAID arrays.And for the reasons you state I also believe individual SSDs as opposed to RAID Arrays are the way to go for FSX.Cheers,- jahman.

I see couple good arguments at present, against RAIDing SSDs for FS.Second, RAID is most useful for increased throughput, because it spreads the data in parallel across several I/O channels. FS doesn't generally make use of that very well, as its file activity is predominantly large numbers of smallish files. What FS needs to shine is low random access time, and RAID configs are actually a bit slower in their random access numbers than single drives because of the interdevice syncing that has to occur to move data across the bus. It should also be noted that many of the high-capacity SSDs are (internally) RAID-like configs being controlled by a common controller chip...they are typically better performers in the access department than independent PCIe devices RAIDed together. They are also TRIM-capable.The one notable exception is those using humongous photoreal scenery databases--the increased throughput of a RAID array can be helpful moving massive photoscenery files.

Hi Bob, am I correct in calculating file size by taking the properties of my FSX scenery file at 17.4GB and dividing by number of files 42,328 = .421 of a megabyte approximate? Reason I ask is that I was told that FSX uses large random file reads and I am trying to clarify reasoning behind my use of a controller card set at a 512K-stripe and 64k-cluster.

Hi Bob, am I correct in calculating file size by taking the properties of my FSX scenery file at 17.4GB and dividing by number of files 42,328 = .421 of a megabyte approximate? Reason I ask is that I was told that FSX uses large random file reads and I am trying to clarify reasoning behind my use of a controller card set at a 512K-stripe and 64k-cluster.

Average file size calculated in such a method is not representative of actual file size, and as such has no bearing on expected performance. You would actually need to look at individual file sizes to determine the best stripe and cluster sizes.

Average file size calculated in such a method is not representative of actual file size, and as such has no bearing on expected performance. You would actually need to look at individual file sizes to determine the best stripe and cluster sizes.

That being the case,it would make it a whole-bunch of small files as the Colonel, stated.Thank you.

That being the case,it would make it a whole-bunch of small files as the Colonel, stated.Thank you.

A few years ago I ran filemon during an FSX session and then did a histogram of the sizes of the files in the log that FSX was accessing. For the life of me I can't find the data from that experiment (I think it may have gone to data heaven on a drive that crashed last year), but the conclusion I drew was that FSX was thrashing the file system with a lot of small file access activity. I also noted that FSX seems to have a pretty decent scenery caching scheme, and that the real benefits to fast random access in the disk system are to those scenery files being accessed for the first time (i.e. when loading a new tile or coming into range and loading up scenery objects at an airport). After the first time, FSX is hitting them often enough to keep them in the system's disk cache (RAM) while in use.

A few years ago I ran filemon during an FSX session and then did a histogram of the sizes of the files in the log that FSX was accessing. For the life of me I can't find the data from that experiment (I think it may have gone to data heaven on a drive that crashed last year), but the conclusion I drew was that FSX was thrashing the file system with a lot of small file access activity. I also noted that FSX seems to have a pretty decent scenery caching scheme, and that the real benefits to fast random access in the disk system are to those scenery files being accessed for the first time (i.e. when loading a new tile or coming into range and loading up scenery objects at an airport). After the first time, FSX is hitting them often enough to keep them in the system's disk cache (RAM) while in use.

Thank you Col. Bob.

A few years ago I ran filemon during an FSX session and then did a histogram of the sizes of the files in the log that FSX was accessing. For the life of me I can't find the data from that experiment (I think it may have gone to data heaven on a drive that crashed last year)...

FileMon has been superseeded by Process Monitor since Win 2KSP4. ProcessMonitor can be downloaded here.Cheers,- jahman.

FileMon has been superseeded by Process Monitor since Win 2KSP4. ProcessMonitor can be downloaded here.Cheers,- jahman.

OK, then the program I used to create the file access log was probably the newer ProcMon rather than the old FileMon...the details are a bit fuzzy now that some years have passed.

OK, then the program I used to create the file access log was probably the newer ProcMon rather than the old FileMon...the details are a bit fuzzy now that some years have passed.

Bob, I didn't mean to correct you, rather I thought you might be looking to download FileMon and (since its no longer available) couldn't find it. Cheers,- jahman.

Bob, I didn't mean to correct you, rather I thought you might be looking to download FileMon and (since its no longer available) couldn't find it. Cheers,- jahman.

Naw, I didn't take it that way. I still call ProcMon "FileMon" out of habit...sorta like I call C++ and C# just "C" Old dog...new tricks and all that. I'm thinking about running a similar experiment to check out some cache configurations and utilities. I'm toying with writing a utility that would read (and thereby pre-load) FSX files so that they'd be in cache already for first-use by FSX. I hate that big stutter you get when approaching a complex add-on airport.