Message-ID: <4C2A0D4A.6040808@gmail.com>
Date:	Tue, 29 Jun 2010 17:12:10 +0200
From:	Nebojsa Trpkovic <trx.lists@...il.com>
To:	Nebojsa Trpkovic <trx.lists@...il.com>
CC:	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: Ext4 on SSD Intel X25-M

just to give an example of reading "host writes" from SSD S.M.A.R.T
attribute:

###################################

tnt ~ # smartctl -A /dev/sda|grep 225
225 Load_Cycle_Count        0x0030   200   200   000    Old_age
Offline      -       6939
tnt ~ # dd if=/dev/zero of=somefile.tmp bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 0.0708615 s, 1.9 GB/s
tnt ~ # smartctl -A /dev/sda|grep 225
225 Load_Cycle_Count        0x0030   200   200   000    Old_age
Offline      -       6939
tnt ~ # sync
tnt ~ # smartctl -A /dev/sda|grep 225
225 Load_Cycle_Count        0x0030   200   200   000    Old_age
Offline      -       6943
tnt ~ #

###################################




On 06/29/10 16:35, Nebojsa Trpkovic wrote:
>> On 06/29/10 15:56, tytso@....edu wrote:
>> On Sun, Jun 27, 2010 at 07:47:46PM +0200, Nebojsa Trpkovic wrote:
>>> My best guess is that host itself uses a lot of optimisation to reduce
>>> writing to NAND itself.
>>
>> Possible, although if the counter is defined as "host writes", that
>> should be before the NAND writes, since "host writes" would expect
>> means the actual write commands coming from the host -- i.e., coming
>> incoming SATA write commands.
> 
> That's true. Maybe Intel gave wrong name to that variable, as they are
> trying to keep track of NAND wear, not SATA write commands. Then again,
> maybe it's just amount of SATA writes.
> 
>>> Besides that, I've noticed that my commit=100 mount option helps also.
>>> Changing (just for testing) to something realy big, like commit=9000,
>>> gave even further improvement, but not worth staying with risk of losing
>>> (that much) data. It seems that ext4 writes a lot to filesystem, but
>>> many of those writes are overwrites. If we flush them to host just once
>>> in 100 seconds, we're getting a lot of saving.
>>
>> What metric are you using when you say that this "helps"?  The ext4
>> measurement, the SSD counter which you are using, or both?
> 
> I've made graph with rrdtool to track both lifetime_write_kbytes and
> host writes from SSD. It looks like this:
> http://img130.imageshack.us/img130/6905/systemg29year.png
> with lifetime_writes_kbytes decreasing on unclean shutdown.
> "host writes" counter read from SSD starts at bigger value because I've
> done some testing with SSD before I've made sda1 and formated it.
> Since then, trend is quite obvious. Differences in line slopes are due
> different type of usage from time to time.
> 
>>> As I wanted to make even my swap TRIMable, I've put it in the file on
>>> ext4 instead of separate partition. I've made it using dd with seek=500
>>> bs=1M options. ext4's lifetime_write_kbytes increased by 500MB, and host
>>> writes did not incrase at all, even after 100 seconds. Ok, I know that
>>> ext4 did not write 500MB of data to filesystem, but this is one more
>>> thing why one should not trust lifetime_write_kbytes.
>>
>>> So, the moral of my story would be not to trust lifetime_write_kbytes,
>>> but to read host writes from SSD.
>>
>> If you wrote 500MB to a swap file in ext4 using dd, why are you sure
>> ext4 didn't write 500MB of data to the disk?  In fact, this would
>> imply to me that that your "host writes" shouldn't be trusted.
> 
> I've used dd with bs=1M, seek=500 and count=1 option, making file of
> 500MB but writting just last megabyte of it to avoid unnecessary SSD
> writes during swap-file cration.
> 
>>> I noticed that Intel's Solid State Drive Toolbox software (running in
>>> Windows) gives the amount of Host Lifetime Writes that equales to
>>> S.M.A.R.T attribute 225 (Load_Cycle_Count) multiplied with 32MB.
>>> That's the way I track it in Linux.
>>
>> According to the S.M.A.R.T startd, Load_cycle_count is supposed to
>> mean the number of times the platter has spun up and spin down.  It's
>> not clear what it means for SDD's, so it may be that they have reused
>> it for some other purpose.  However, it would be surprising to me that
>> it was just host lifetime writes divided by 32MB.  It may be that you
>> have noticed this correlation in Windows because Windows is very
>> "chunky" in how it does its writes.
> 
> I've found out about that S.M.A.R.T value by constant comparing of "host
> writes" that I see in Intel's SSD Toolbox and my calculated graph of
> "host writes" (32MB * SMART value 225).
> Everytime I reboot my box and boot Windows 7 residing on external HDD, I
> start Intel SSD Toolbox that gives me "host writes" amount using nice
> looking GUI. Whenever I rebooted in Windows, I've seen those values to
> match. I guess that Intel just missuses S.M.A.R.T. value not needed for
> theier SSD violating S.M.A.R.T. standard, but at least, I can get that
> info in Linux without Intel SSD toolbox.
> 
>> However, if you write 500MB to a file in ext4 using dd, and ext4's
>> lifetime_write_kbytes in /sysfs went up by 500MB, but the
>> Load_Cycle_Count attribute did not go up, then I would deduce from
>> that that your interpretation of Load_Cycle_Count is probably not
>> correct...
> 
> I've explained this before. Maybe I'm wrong, but in my opinion
> 
> dd if=/dev/zero of=somefile bs=1M seek=500 count=1
> 
> should make 500MB file with just 1MB writen to disk. Even df should not
> register absence of 500MB of free space.
> 
> Nebojsa
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists