From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: fstrim and SSDs and cron; was: Re: cron-service Date: Wed, 18 May 2016 07:09:04 +0200 Message-ID: <20160518070904.6bd08446@scratchpost.org> References: <20160430192744.1fbe081f@scratchpost.org> <871t5lc432.fsf@gnu.org> <20160517192857.0bab0560@scratchpost.org> <87zirotm2n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2tjP-00035x-FN for guix-devel@gnu.org; Wed, 18 May 2016 01:09:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2tjJ-0005SA-FE for guix-devel@gnu.org; Wed, 18 May 2016 01:09:14 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Thompson, David" Cc: guix-devel Hi, > FWIW, I use SSDs in all my computers and have never run fstrim. Feels > a lot like the "defragment your hard drive" days. If you would run it now then it would free many gigabytes. What it does and why it's needed: Traditionally filesystems on hard disks would just reuse sectors once they are not needed by the filesystem anymore. For example to delete a file it would just remove the filename and update the usage bitmap metadata. That's it. It wouldn't do anything to the payload sectors. Later on, the payload sector could maybe be used for another file's payload. For SSDs this is bad since they are trying to do wear levelling. SSDs work by providing an "hard-drive-like" interface to (many) flash blocks in hardware. A flash block can be written (actually: erased) only a limited number of times (< 5000). So there's an algorithm in the drive fireware which makes sure to evenly use all the flash blocks. If you keep writing the same sector, it will eventually move and remap it to another formerly-empty flash block. The problem with that is the "empty" in the last sentence. Which one is empty? As I said, the traditional filesystem wouldn't do anything to mark the payload setors as empty on the drive itself. Therefore, a command called "TRIM" was added to the SATA protocol (and other things). fstrim will send the command to the drive, informing it about sectors that are actually unused now. In this way the SSD has more possible targets to move stuff to. if you don't do it at all, the SSD will eventually run out of spare blocks and won't move stuff away anymore - which means one of the blocks is going to fail very soon (the ones that are written often - which are probably filesystem metadata blocks - maybe the usage bitmap). Of course it can still shuffle around used blocks - and probably does. Otherwise it would turn out to be very bad. There's also the "discard" mount option which automatically trims - but documentation says that it's caused longevity problems in the past for some drives (probably because it sends the TRIM command too often).