From: Calvin Walton <calvin.walton@kepstin.ca>
To: Julian Andres Klode <jak@jak-linux.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Please help: Is ext4 counting trims as writes, or is something killing my SSD?
Date: Thu, 12 Sep 2013 10:54:03 -0400 [thread overview]
Message-ID: <1378997643.28638.53.camel@hp-a6734f> (raw)
In-Reply-To: <20130912141856.GA17640@jak-x230>
On Thu, 2013-09-12 at 16:18 +0200, Julian Andres Klode wrote:
> Hi,
>
> I installed my new laptop on Saturday and setup an ext4 filesystem
> on my / and /home partitions. Without me doing much file transfers,
> I noticed today:
>
> jak@jak-x230:~$ cat /sys/fs/ext4/sdb3/lifetime_write_kbytes
> 342614039
>
> This is on a 100GB partition. I used fstrim multiple times. I analysed
> the increase over some time today and issued an fstrim in between:
<snip>
> So it seems that ext4 counts the trims as writes? I don't know how I could
> get 300GB of writes on a 100GB partition -- of which only 8 GB are occupied
> -- otherwise.
The way fstrim works is that it allocates a temporary file that fills
almost the entire free space on the partition. I believe it does this
with fallocate in order to ensure that space for the file is actually
reserved on disc (but it does not get written to!). It then looks up
where on disc the file's reserved space is, and sends a trim command to
the drive to free that space. Afterwards, it deletes the temporary file.
So what you are seeing means means that it's probably just an issue with
the write accounting, where the blocks reserved by the fallocate are
counted as writes.
> My smart values for my SSD are:
>
> SMART Attributes Data Structure revision number: 1
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 241 Total_LBAs_Written 0x0003 100 100 000 Pre-fail Always - 1494
You should be able to confirm this by checking the 'Total_LBAs_Written'
attribute before and after doing the fstrim; it should either not go up,
or go up only be a small amount. Although to be honest, I'm not sure
what this is counting - if that raw value is actually LBAs, that would
only account for 747KiB of writes! I guess it's probably a count of
erase blocks or something - what model is the SSD?
--
Calvin Walton <calvin.walton@kepstin.ca>
next prev parent reply other threads:[~2013-09-12 14:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 14:18 Please help: Is ext4 counting trims as writes, or is something killing my SSD? Julian Andres Klode
2013-09-12 14:26 ` Julian Andres Klode
2013-09-12 14:54 ` Calvin Walton [this message]
2013-09-12 15:03 ` Julian Andres Klode
2013-09-12 15:18 ` Eric Sandeen
2013-09-12 15:29 ` Calvin Walton
2013-09-12 15:33 ` Eric Sandeen
2013-09-12 15:32 ` Julian Andres Klode
2013-09-12 15:52 ` Eric Sandeen
2013-09-12 18:47 ` Theodore Ts'o
2013-09-13 13:41 ` Ric Wheeler
2013-09-13 13:38 ` Ric Wheeler
2013-09-12 15:19 ` Julian Andres Klode
2013-09-12 15:28 ` Theodore Ts'o
2013-09-12 15:29 ` Lukáš Czerner
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=1378997643.28638.53.camel@hp-a6734f \
--to=calvin.walton@kepstin.ca \
--cc=jak@jak-linux.org \
--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).