RayLopez99 said:
Assume no heavy databases, light gaming, word processing, compiling some code on Visual Studio, Internet surfing, movie watching (which is mostly read not write operations). For my quest to answer the below.
RL
Intel's owns statements about their X25-M SSD, which AnandTech analyzed in 2008 here:
http://www.anandtech.com/show/2614/4 And the conclusion: five years of use under heavy usage. "Note: by the way, some manufacturers give the total amount of data written to the drive as one of the drive lifetime indicators. For example, Intel guarantees that the total of about 37 TB of data will be written to X25-M drives (20 GB per day for 5 years: “The drive will have a minimum of 5 years of useful life under typical client workloads with up to 20 GB host writes per day.”)
The simple answer might be:
fsutil fsinfo statistics C:
which gives
File System Type : NTFS
UserFileReads : 26260631
UserFileReadBytes : 2517118976 <---
UserDiskReads : 26260658
UserFileWrites : 7632546
UserFileWriteBytes : 1891827712 <---
UserDiskWrites : 7632547
MetaDataReads : 32099
MetaDataReadBytes : 131477504
MetaDataDiskReads : 32108
MetaDataWrites : 44450
MetaDataWriteBytes : 200445952
MetaDataDiskWrites : 54390
...
You might say "oh, how wonderful", until you
actually test it.
I read a 77GB file from the partition, recording
the fsutil output before and after. The number
did not say "77GB". It wasn't Original_number+77GB.
In my testing, it seems to indicate "UserFileReadBytes"
uses a 32 bit counter. If I take (original_number+77GB) mod 2^32
I get much closer to the right answer.
So that route appears useless for the task. Braindead.
Maybe, if there's such a thing as "fsutil64", and
the OS is better than my copy of WinXP, you'll get
the right answer.
I think my point is, if testing that util, do a read op
longer than 4GB, to see whether the counter "rolls over"
or not. Maybe on a 64 bit system, the clever designers
at Microsoft can use a *64 bit* counter. (The counter
is likely in the file system, and not FSUTIL, so I'm
not necessarily blaming the author of FSUTIL for this.
You'd think NTFS would be using 64 bits for things
measuring sizes, in keeping with its gargantuan capacity
for things.)
I don't see a reason, why the WMI subsystem would do
any better. If the brain-dead-ness is in the NTFS
design, then no amount of different paths to get
to it, will change the result. Hopefully Vista/Win7/Win8
have fixed this. Maybe the next time I'm in Win8, I'll
test.
*******
If you want to do a dummy read, try this.
http://www.chrysocome.net/dd
http://www.chrysocome.net/downloads/dd-0.6beta3.zip (Windows)
That version has /dev/null support, like this.
dd if=F:\77gbfile.dd of=/dev/null bs=129024
My block size chosen, is divisible into the test
file size of 77,934,495,744 bytes. It's a read block
size of 252 sectors.
The read took around 13 minutes or so, after which
I ran fsutil, to get the new "UserFileReadBytes".
And noticed the counter seems to be mod 2^32. My
OS used for this test was WinXP Pro SP3 x32.
Paul