From: Nebojsa Trpkovic <trx.lists@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: Re: Ext4 on SSD Intel X25-M
Date: Sun, 27 Jun 2010 19:47:46 +0200 [thread overview]
Message-ID: <4C278EC2.1080903@gmail.com> (raw)
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
next reply other threads:[~2010-06-27 17:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 17:47 Nebojsa Trpkovic [this message]
2010-06-29 13:56 ` Ext4 on SSD Intel X25-M tytso
2010-06-29 14:35 ` Nebojsa Trpkovic
2010-06-29 15:12 ` Nebojsa Trpkovic
-- strict thread matches above, loose matches on Subject: below --
2009-11-12 13:59 Renato S. Yamane
2009-11-12 15:11 ` Eric Sandeen
2009-11-12 15:30 ` Theodore Tso
2009-11-12 20:06 ` Renato S. Yamane
2009-11-13 11:39 ` Andi Kleen
2009-11-13 14:13 ` Theodore Tso
2009-11-13 22:03 ` Florian Weimer
2009-11-15 21:15 ` Renato S. Yamane
2009-11-15 21:18 ` Florian Weimer
2009-11-15 21:30 ` Eric Sandeen
2009-11-15 21:46 ` Renato S. Yamane
2009-11-15 22:11 ` Theodore Tso
2009-11-15 22:18 ` Renato S. Yamane
2009-11-16 18:40 ` Theodore Tso
2009-11-16 19:00 ` Renato S. Yamane
2009-11-15 22:01 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C278EC2.1080903@gmail.com \
--to=trx.lists@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).