From: Calvin Walton <calvin.walton@kepstin.ca>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Julian Andres Klode <jak@jak-linux.org>, 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 11:29:25 -0400 [thread overview]
Message-ID: <1378999765.28638.59.camel@hp-a6734f> (raw)
In-Reply-To: <5231DB33.9090104@redhat.com>
On Thu, 2013-09-12 at 10:18 -0500, Eric Sandeen wrote:
> On 9/12/13 9:54 AM, Calvin Walton wrote:
> > 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.
>
> No, that's not correct.
> Nope. ;) strace it and see, it does nothing like this - it calls a special
> ioctl to ask the fs to find and issue discards on unused blocks.
>
> # strace -e open,write,fallocate,unlink,ioctl fstrim mnt/
> open("/etc/ld.so.cache", O_RDONLY) = 3
> open("/lib64/libc.so.6", O_RDONLY) = 3
> open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
> open("mnt/", O_RDONLY) = 3
> ioctl(3, 0xc0185879, 0x7fff6ac47d40) = 0 <=== FITRIM ioctl
>
> (old hdparm discard might have done what you say, but that was a hack).
Alright, you got me there :) To be honest, I got the name 'fstrim'
confused with the old 'wiper.sh' script that used to be the only way to
do this, and did in fact function as I said.
Having this all integrated into the filesystem itself is quite a nice
change for the better - the old way was definitely a hack! I suppose
this was added sometime in the 2011 timeframe?
--
Calvin Walton <calvin.walton@kepstin.ca>
next prev parent reply other threads:[~2013-09-12 15:29 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
2013-09-12 15:03 ` Julian Andres Klode
2013-09-12 15:18 ` Eric Sandeen
2013-09-12 15:29 ` Calvin Walton [this message]
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=1378999765.28638.59.camel@hp-a6734f \
--to=calvin.walton@kepstin.ca \
--cc=jak@jak-linux.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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