Hi,
[please, leave me on cc because I'm not subscribed on this ML]
I'm using Intel SSD X25-M on my laptop, and I always hear that is not a
good idea use journal on SSD (it decrease the life time).
I ask Intel about this, but I don't receive any answer.
So, I would like to know if is possible disable Journal on EXT4.
I'm using Debian Testing (squeeze).
Regards,
Renato S. Yamane
Renato S. Yamane wrote:
> Hi,
>
> [please, leave me on cc because I'm not subscribed on this ML]
>
> I'm using Intel SSD X25-M on my laptop, and I always hear that is not a
> good idea use journal on SSD (it decrease the life time).
>
> I ask Intel about this, but I don't receive any answer.
>
> So, I would like to know if is possible disable Journal on EXT4.
It is possible, mkfs with "-O ^has_journal" but then of course you ...
have no journaling.
However, Intel has always said, I think, that you should treat their
SSDs just like you would treat any other hard drive, so I probably would
not hesitate to leave the journal intact.
There is a write lifetime of course, but I think it's much better than
if you were writing to, say, a securedigital card.
-Eric
> I'm using Debian Testing (squeeze).
>
> Regards,
> Renato S. Yamane
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 12, 2009 at 11:59:50AM -0200, Renato S. Yamane wrote:
> Hi,
>
> [please, leave me on cc because I'm not subscribed on this ML]
>
> I'm using Intel SSD X25-M on my laptop, and I always hear that is not a
> good idea use journal on SSD (it decrease the life time).
>
> I ask Intel about this, but I don't receive any answer.
>
> So, I would like to know if is possible disable Journal on EXT4.
It is possible to create an ext4 file system without a journal. It
would mean that unclean shutdowns would require a full fsck, which on
a freshly created file system on an SSD isn't _that_ bad. Depending
on how full/fragmented your filesystem happens to be, it will probably
be under 10 seconds.
That being said, though, it shouldn't be necessary to avoid using a
journal on the Intel SSD. Intel says that laptop will last at least 5
years with 10GB worth of writes per day, and that's a huge amount. I
have an X25-M SSD in my laptop, using an ext4 file system and with the
journal enabled, and since the file system was created 266 days ago,
when I put my X25-M into service, the drive has seen 570GB worth of
writes, so I'm averaging 2.14 GB writes per day. That's well under
the 20GB of writes/per day upon which Intel based its 5 year lifetime
(and most hard drives, and heck, most laptops generally aren't in
service for that long before they are replaced.)
I have done a few things to reduce needless disk utilization, such as
using tmpfs for /tmp and configuring firefox to place its cache in
/tmp, but the bottom line is I wouldn't really worry that much about
the journal. If you really want to run without a journal, you can use
"mke2fs -t ext4 -O ^has_journal /dev/XXX" to format an ext4 filesystem
without a journal. But there will be some distinct tradeoffs with
omitting the journal, including possibility that sometimes on an
unclean shutdown you will need to do a manual e2fsck pass.
Best regards,
- Ted
On 12-11-2009 13:30, Theodore Tso wrote:
> On Thu, Nov 12, 2009 at 11:59:50AM -0200, Renato S. Yamane wrote:
>> [please, leave me on cc because I'm not subscribed on this ML]
>>
>> I'm using Intel SSD X25-M on my laptop, and I always hear that is not a
>> good idea use journal on SSD (it decrease the life time).
>>
>> I ask Intel about this, but I don't receive any answer.
>>
>> So, I would like to know if is possible disable Journal on EXT4.
>
> It is possible to create an ext4 file system without a journal. It
> would mean that unclean shutdowns would require a full fsck, which on
> a freshly created file system on an SSD isn't _that_ bad. Depending
> on how full/fragmented your filesystem happens to be, it will probably
> be under 10 seconds.
>
> That being said, though, it shouldn't be necessary to avoid using a
> journal on the Intel SSD. Intel says that laptop will last at least 5
> years with 10GB worth of writes per day...
Woww! Thank you so much Theodore and Eric!
I will keep using journal on my SSD X25-M.
Regards,
Renato S. Yamane
Theodore Tso <[email protected]> writes:
>
> I have done a few things to reduce needless disk utilization, such as
> using tmpfs for /tmp and configuring firefox to place its cache in
> /tmp,
OT, but these two together seems rather pointless, could as well
keep it in its own memory then when it's in memory anyways. That will
be faster.
-Andi (who generally disables firefox disk caching)
--
[email protected] -- Speaking for myself only.
On Fri, Nov 13, 2009 at 12:39:55PM +0100, Andi Kleen wrote:
> Theodore Tso <[email protected]> writes:
> >
> > I have done a few things to reduce needless disk utilization, such as
> > using tmpfs for /tmp and configuring firefox to place its cache in
> > /tmp,
>
> OT, but these two together seems rather pointless, could as well
> keep it in its own memory then when it's in memory anyways. That will
> be faster.
Well, technically it's not the same, since tmpfs is swappable --- but
in my case where I have 4GB of memory in my laptop and swap is
disabled (and perhaps for most users), you're right, it's probably
better to increase firefox's memory cache and disable it's disk cache
entirely.
- Ted
* Theodore Tso:
> That being said, though, it shouldn't be necessary to avoid using a
> journal on the Intel SSD. Intel says that laptop will last at least 5
> years with 10GB worth of writes per day, and that's a huge amount. I
> have an X25-M SSD in my laptop, using an ext4 file system and with the
> journal enabled, and since the file system was created 266 days ago,
> when I put my X25-M into service, the drive has seen 570GB worth of
> writes, so I'm averaging 2.14 GB writes per day.
That really depends on the software you use. Just fetching mail on my
machine causes about 500 MB of data written to disk. That's because
I'm using Gnus with nnml and slightly large mail folders and Gnus
rewrites those index files from scratch each time new mail for a
folder arrives. I should really consider this a bug and fix it, but I
haven't yet found a good solution.
On 13-11-2009 20:03, Florian Weimer wrote:
> * Theodore Tso:
>> That being said, though, it shouldn't be necessary to avoid using a
>> journal on the Intel SSD. Intel says that laptop will last at least 5
>> years with 10GB worth of writes per day, and that's a huge amount. I
>> have an X25-M SSD in my laptop, using an ext4 file system and with the
>> journal enabled, and since the file system was created 266 days ago,
>> when I put my X25-M into service, the drive has seen 570GB worth of
>> writes, so I'm averaging 2.14 GB writes per day.
>
> That really depends on the software you use. Just fetching mail on my
> machine causes about 500 MB of data written to disk. That's because
> I'm using Gnus with nnml and slightly large mail folders and Gnus
> rewrites those index files from scratch each time new mail for a
> folder arrives. I should really consider this a bug and fix it, but I
> haven't yet found a good solution.
So sorry for this stupid question, but...
How can I know the average writes per day?
I try run smart, but it not help me:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
3 Spin_Up_Time 0x0000 100 000 000 Old_age
Offline - 0
4 Start_Stop_Count 0x0000 100 000 000 Old_age
Offline - 0
5 Reallocated_Sector_Ct 0x0002 100 100 000 Old_age
Always - 0
9 Power_On_Hours 0x0002 100 100 000 Old_age
Always - 229
12 Power_Cycle_Count 0x0002 100 100 000 Old_age
Always - 62
192 Power-Off_Retract_Count 0x0002 100 100 000 Old_age Always
- 48
232 Unknown_Attribute 0x0003 100 100 010 Pre-fail Always
- 0
233 Unknown_Attribute 0x0002 099 099 000 Old_age Always
- 0
225 Load_Cycle_Count 0x0000 200 200 000 Old_age
Offline - 44867
226 Load-in_Time 0x0002 255 000 000 Old_age Always
- 0
227 Torq-amp_Count 0x0002 000 000 000 Old_age Always
- 0
228 Power-off_Retract_Count 0x0002 000 000 000 Old_age Always
- 0
Reagards,
Renato S. Yamane
* Renato S. Yamane:
> How can I know the average writes per day?
I used iostat (part of sysstat). Perhaps I should have checked first
if it is accurate. 8-/
Florian Weimer wrote:
> * Renato S. Yamane:
>
>> How can I know the average writes per day?
>
> I used iostat (part of sysstat). Perhaps I should have checked first
> if it is accurate. 8-/
If you're running ext4, you can look at:
/sys/fs/ext4/sdXX/lifetime_write_kbytes and
/sys/fs/ext4/sdXX/session_write_kbytes
too.
-Eric
On 15-11-2009 19:30, Eric Sandeen wrote:
> Florian Weimer wrote:
>> * Renato S. Yamane:
>>> How can I know the average writes per day?
>>
>> I used iostat (part of sysstat). Perhaps I should have checked first
>> if it is accurate. 8-/
>
> If you're running ext4, you can look at:
> /sys/fs/ext4/sdXX/lifetime_write_kbytes and
> /sys/fs/ext4/sdXX/session_write_kbytes
smartctl show me 229h Power_On_Hours (I buy it one month ago).
And /sys/fs/ext4/sdXX/lifetime_write_kbytes show me 19940467
So:
229h = 9,54 days
19940467 kbytes / 9,54 days = 2Gb/day
I think that it is too much. I use it on my laptop only to see my
e-mails (Thunderbird) and use OpenOffice.org on my work environment.
Regards and thanks for all!
Renato S. Yamane
On Sun, Nov 15, 2009 at 03:30:55PM -0600, Eric Sandeen wrote:
> Florian Weimer wrote:
>> * Renato S. Yamane:
>>
>>> How can I know the average writes per day?
>>
>> I used iostat (part of sysstat). Perhaps I should have checked first
>> if it is accurate. 8-/
>
> If you're running ext4, you can look at:
>
> /sys/fs/ext4/sdXX/lifetime_write_kbytes and
> /sys/fs/ext4/sdXX/session_write_kbytes
For an umounted filesystem, you can also do this:
dumpe2fs -h /dev/XXX | grep "Lifetime writes"
dumpe2fs -h /dev/XXX | grep "Filesystem created"
Then use a handy-dandy date calculator to figure the number of days
between the file system creation date and today, and then divide...
- Ted
On Sun, Nov 15, 2009 at 07:46:21PM -0200, Renato S. Yamane wrote:
> On 15-11-2009 19:30, Eric Sandeen wrote:
>> Florian Weimer wrote:
>>> * Renato S. Yamane:
>>>> How can I know the average writes per day?
>>>
>>> I used iostat (part of sysstat). Perhaps I should have checked first
>>> if it is accurate. 8-/
>>
>> If you're running ext4, you can look at:
>> /sys/fs/ext4/sdXX/lifetime_write_kbytes and
>> /sys/fs/ext4/sdXX/session_write_kbytes
>
> smartctl show me 229h Power_On_Hours (I buy it one month ago).
> And /sys/fs/ext4/sdXX/lifetime_write_kbytes show me 19940467
>
> So:
> 229h = 9,54 days
> 19940467 kbytes / 9,54 days = 2Gb/day
>
> I think that it is too much. I use it on my laptop only to see my
> e-mails (Thunderbird) and use OpenOffice.org on my work environment.
If you've only had the disk for a short while, then the initial writes
to install your system is probably biasing your results. So far you
have approximately 19GB of disk writes. I'm guessing that at least
3-4GB is from the initial installation of software on your system.
Also, if you are turning off your laptop at night, treating 229 hours
as 9.5 days isn't really fair. If you installed the SSD a month ago,
then treat that as 30 days, and we get:
16GB / 30 == 0.533 GB
This is well under the rated 20GB/day upon which Intel guarantees a
five year life --- and most people don't keep their laptop and/or hard
drives that long anyway.
- Ted
On 15-11-2009 20:11, Theodore Tso wrote:
> Renato S. Yamane wrote:
>> Eric Sandeen wrote:
>>> Florian Weimer wrote:
>>>> Renato S. Yamane wrote:
>>>>> How can I know the average writes per day?
>>>>
>>>> I used iostat (part of sysstat). Perhaps I should have checked first
>>>> if it is accurate. 8-/
>>>
>>> If you're running ext4, you can look at:
>>> /sys/fs/ext4/sdXX/lifetime_write_kbytes and
>>> /sys/fs/ext4/sdXX/session_write_kbytes
>>
>> smartctl show me 229h Power_On_Hours (I buy it one month ago).
>> And /sys/fs/ext4/sdXX/lifetime_write_kbytes show me 19940467
>>
>> So:
>> 229h = 9,54 days
>> 19940467 kbytes / 9,54 days = 2Gb/day
>>
>> I think that it is too much. I use it on my laptop only to see my
>> e-mails (Thunderbird) and use OpenOffice.org on my work environment.
>
> If you've only had the disk for a short while, then the initial writes
> to install your system is probably biasing your results. So far you
> have approximately 19GB of disk writes. I'm guessing that at least
> 3-4GB is from the initial installation of software on your system.
>
> Also, if you are turning off your laptop at night, treating 229 hours
> as 9.5 days isn't really fair. If you installed the SSD a month ago,
> then treat that as 30 days, and we get:
>
> 16GB / 30 == 0.533 GB
>
> This is well under the rated 20GB/day upon which Intel guarantees a
> five year life --- and most people don't keep their laptop and/or hard
> drives that long anyway.
Wow! You are really right!
Thank you so much Theodore, Eric and Florian!
I'm very happy with this SSD! It's really faster!
Regards,
Renato S. Yamane
On Sun, Nov 15, 2009 at 05:11:46PM -0500, Theodore Tso wrote:
> If you've only had the disk for a short while, then the initial writes
> to install your system is probably biasing your results. So far you
> have approximately 19GB of disk writes. I'm guessing that at least
> 3-4GB is from the initial installation of software on your system.
I just did a default Ubuntu Karmic x86_64 install, and it writes a
approximately ten and a half GB to the root partition. It also (for
no explicable reason) apparently zero's out the swap partition, which
(a) takes a long time, and (b) results in useless, pointless writes to
the SSD. Someone should complain to Ubuntu about that... the
workaround is to not configure swap during the Ubuntu install process,
and to manually configure it yourself later.
(Or to not use swap at all, if you have enough memory in your system.)
In any case, given that means that only 8.5GB worth of data was
written to your system, so over 30 days, your usage levels is
averaging to 0.283 GB per calendar day.
- Ted
On 16-11-2009 16:40, Theodore Tso wrote:
> Theodore Tso wrote:
>> If you've only had the disk for a short while, then the initial writes
>> to install your system is probably biasing your results. So far you
>> have approximately 19GB of disk writes. I'm guessing that at least
>> 3-4GB is from the initial installation of software on your system.
>
> I just did a default Ubuntu Karmic x86_64 install, and it writes a
> approximately ten and a half GB to the root partition. It also (for
> no explicable reason) apparently zero's out the swap partition, which
> (a) takes a long time, and (b) results in useless, pointless writes to
> the SSD. Someone should complain to Ubuntu about that... the
> workaround is to not configure swap during the Ubuntu install process,
> and to manually configure it yourself later.
>
> (Or to not use swap at all, if you have enough memory in your system.)
>
> In any case, given that means that only 8.5GB worth of data was
> written to your system, so over 30 days, your usage levels is
> averaging to 0.283 GB per calendar day.
I'm working with my laptop by 9h right now (this is my tipical business
day) and /sys/fs/ext4/sda1/session_write_kbytes show me "324732"
So, I think that you is really right.
Renato S. Yamane
Hello.
I've found this old thread
http://thread.gmane.org/gmane.comp.file-systems.ext4/16386/focus=16444
and wanted to contribute a piece of my exiriance.
As I don't know if putting right subject will be enough to make reply on
right thread, I'm putting to BCC addresses of all coresponders in old
thread.
I've noticed that there is a difference between
/sys/fs/ext4/sdXX/lifetime_write_kbytes
and host writes read from SSD itself.
I'll put aside issue of losing lifetime_write_kbytes accuracy after
unclean reboot/shutdown:
http://thread.gmane.org/gmane.comp.file-systems.ext4/19734
Guess that session_write_kbytes doesn't succed to be added to
lifetime_write_kbytes in that particular case.
In normal desktop operation "host writes" counter on SSD increases at
roughly ~2/3 compared to lifetime_write_kbytes.
My best guess is that host itself uses a lot of optimisation to reduce
writing to NAND itself.
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.
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.
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.
Nebojsa Trpkovic
On Sun, Jun 27, 2010 at 07:47:46PM +0200, Nebojsa Trpkovic wrote:
> I've noticed that there is a difference between
> /sys/fs/ext4/sdXX/lifetime_write_kbytes
> and host writes read from SSD itself.
>
> In normal desktop operation "host writes" counter on SSD increases at
> roughly ~2/3 compared to lifetime_write_kbytes.
How are you measuring the "host writes" counter from the SSD?
> 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.
> 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?
> 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 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.
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...
- Ted
> On 06/29/10 15:56, [email protected] 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
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, [email protected] 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
