Are SSDs always rubbish under winXP?

Yeah, and YOUR pathetic guesses as to what is going on or where or when are off 100% as well, idiot!

There are 2 possibilities.

A 16 or 32 GB disk is practical. It would cost more but it's only part of a system, and it would have the speed and the reliability.

A partial RAM buffer would solve the registry problem, and any similar problem, without needing the drive to understand every filesystem. On a typical day less than 1 GB is modified at all. They could easily have a buffer big enough to avoid writing to any flash for at least a day. That would cut writes to frequently changed files down to nothing, as such files never add up to more than 1 GB.

--

Reply in group, but if emailing add one more
zero, and remove the last word.

[8>>> This is why knowing the intended deployment can come in handy as

But 16-32G is small in the desktop/laptop world (I'm working on designs of handheld/embedded devices with that much "on board")

The "right" way to solve the windows problem is to acknowledge that:

- swap file writes don't need to be to persistent storage

- registry updates needn't be persistent UNTIL POWER FAIL IS IMMINENT!

So, move the swap into a dedicated piece of RAM -- even if you have to locate that RAM in a "disk drive" to get around "issues" in windows configuration.

I don't think Windows has a predictable mechanism for relocating

*just* the registry to a different "filesystem" (which could then be mounted on a different physical device!). E.g., true symlinks could give you this capability without necessitating a special mount point *just* for registry files (MS doesn't think ahead in this respect... \WINDOWS\registry would have made far more sense as it would have isolated those files someplace "convenient" for future manipulation. Oh, I forgot. Putting "MS" and "future" is a silly idea. "Microsoft, bringing 1970's technology to the 21st century!")

If you can move the registry files onto a "ram-disk" and then schedule a process to flush them to the *real* disk at power down, you've solved the problem (except for the inevitable MS crashes that don't proceed through an orderly shutdown!)

There really aren't that many different filesystems in use. When you contrast the number of filesystems with the number of different versions of Windows, Solaris, Linux, FreeBSD, NetBSD, OpenBSD, QNX, Minix, IRIX, DOS, AmigaOS, MacOS, etc. you see how much *easier* it is to support filesystems than rely on OS support!

E.g., accurately modeling a FAT32 filesystem would allow you to use that SSD on most of the above (though perhaps not with all of the bells and whistles that you would like). OTOH, if *only* Windows 7/8 supports TRIM, then how many of the above environments are unusable (if the SSD *relies* on TRIM)?

The problem there is you are (largely) left at the mercy of the OS provider to implement those features. Or, "hacks" like Intel has implemented (which require you to tune how often the hack is invoked based on the sort of disk traffic you encounter).

And forget the ability to run "legacy" OS's using that sort of hardware. Which OS vendor is going to back-port that sort of utility to an older/obsolescent OS?

of a

a a

That

files

That depends quite a bit on what you are doing. In a rather typical desktop environment what you say seems true on the face of it. Edit HD video for a few minutes to a few hours and it is obviously not the case. See also large simulations.

Doable!

Windows also writes a lot of log files just like linux. I think that the registry writes are performance counter data (a damn stupid place to put them). MS should put in some controls to control the write frequency = from several times per second to no more than once a day.

That may be possible, but how frequently do you want it to write to non-volitle memory (disk like)?

?-)

memory

only a

Maybe, depends a bit on how the FW policy is represented. Still pathological write policies from MS are an existing problem.

those.

patterns.

DLT? Googling, Oh HiTC! Well HiTC include both serpentine and helical physical tape layouts.

lots

write

appropriate,

OK, a matter of degree and matching ratios.

access

cheaper

Interesting public misconception, rotating disk does NOT have uniform access times, it is just so fast now that almost nobody notices. Especially with serious OS buffering. Rotating disk does have = effectively transfinite write endurance. Flash does have nearly uniform access time (both read and write), but it is so much faster than rotating disk that only a very few care.

Cheers ?-)

other

better

relatively

works

OK. Unixes and linuxs have only about a dozen reasonable filesystems and only about 5 of them are reasonably popular. Various fats and ntfs with Mac HFS(+). Don't know what Amiga did. Minix has its own file system as does QNX. Hmmm. Still about a dozen of them.

Well at least it could support all the bells and whistles of fat32 which ain't that bad. But if you need real file ownership support fat doesn't cut it, and ntfs ain't much better.

written

OS

for

The same goes for the FS dependant disk algorithms.

in

---------------------------------^^^^^^^^^^^^^^^^^^

Disk is a DASD while tape is SASD.

(Physical) disk access time consists of rotational delay as the platter stack spins around to bring the magnetic domains (assuming a magnetic disk) of interest under the head; plus seek time -- the time to position the head array over the appropriate track.

Rotational delay obviously varies based on where the domains happen to be "at the present time" wrt the head(s). It also is a function of the speed at which the platters are rotating (some media vary their speed based on where the data is located on the medium).

Some disk assemblies eliminated the seek time by incorporating a head per track (cylinder). The RS11 had 128 (?) fixed heads and was *effectively* "word addressable" (256K 16+1b words).

In a DASD, access time is tightly bounded and "very similar" regardless of which data are being accessed. By contrast, in a SASD, access time varies greatly with where the data resides on the medium.

(I wrote a driver for half inch 9T that could be mounted as a block device. Slow as sin but amusing to watch the reels start, stop and reverse on a dime as it chased down the desired "block"!)

No. Flash write times are orders of magnitude slower than read times. This is another reason why you really want to avoid reads.

By contrast, with the exception of the physical access delays necessitated by the rotating medium, a disk's write time is essentially the same as its read time.

Which you do not do on an SSD, IDIOT!

You still need a spinning hard drive for that. ANY editor with half a brain knows that.

A 30 second google search will tell you that they do fail (SSDs). Why exercise it?

Oh and he was talking about system files.

effectively

time

^^^^^ writes

=46alsh write times are still much faster than disk reads/writes. Low =

100's of us (can be a fast as mid 10s of us) versus 3 to 10 ms or so. Depends = a lot on how many seeks, at least two if the filesystem keeps track of modified time (mtime). Keeping track of accessed time (atime) really hurts rotating disk filesystem performance by adding seeks and writes = like crazy.