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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.