From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-154106-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 47F4D138EFA
	for <garchives@archives.gentoo.org>; Sat, 22 Feb 2014 15:24:44 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 0D50FE0BD4;
	Sat, 22 Feb 2014 15:24:39 +0000 (UTC)
Received: from uberouter3.guranga.net (unknown [78.25.223.226])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id D18D1E0B8A
	for <gentoo-user@lists.gentoo.org>; Sat, 22 Feb 2014 15:24:37 +0000 (UTC)
Received: from [192.168.151.11] (localhost [127.0.0.1])
	by uberouter3.guranga.net (Postfix) with ESMTP id 63135829D1
	for <gentoo-user@lists.gentoo.org>; Sat, 22 Feb 2014 15:24:35 +0000 (GMT)
Received: from 192.168.151.47
        (SquirrelMail authenticated user thegeezer@thegeezer.net)
        by 192.168.151.11 with HTTP;
        Sat, 22 Feb 2014 15:24:36 -0000
Message-ID: <93fe011c7457eb300ff8c41d0d6a0fa5.squirrel@192.168.151.11>
In-Reply-To: <1806267.JHXjO8X3Xa@wstn>
References: <1806267.JHXjO8X3Xa@wstn>
Date: Sat, 22 Feb 2014 15:24:36 -0000
Subject: Re: [gentoo-user] SSD success - I think
From: thegeezer@thegeezer.net
To: gentoo-user@lists.gentoo.org
User-Agent: SquirrelMail/1.4.22
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Archives-Salt: 7438f2ff-5f44-4833-bb36-f6225a47772b
X-Archives-Hash: 40b9e7aed13e26341a8bbf98a11b79a1

> Hello list,
>
> A week ago the 2.5" drive on my Atom LAN mini-server failed, so I decided
> to
> bite the bullet and replace it with an SSD. Interesting times!
>
> Today I took the box off-line and backed up the entire, newly built system
> to
> external USB2 disk. The 3GB took four minutes, a third or a quarter of the
> previous time on the spinning disk. Good news!
>
> I find though that fstrim can't operate on /boot, which is a separate ext2
> file
> system. It reports:
> 	fstrim: /boot: FITRIM ioctl failed: Inappropriate ioctl for device
> Is this because it's an ext2 partition, not ext4 like the rest of them?

Yes this is correct.
trim basically requires the FS to mark inodes as ready for deletion [1]
a good intro to ssd trim is here [2] though i use online trim not offline
on my laptopp.


> Man
> fstrim makes no mention of file-system types.
>
> Maybe I've not laid out the partitions properly. I used gparted from a
> recent
> System Rescue CD (http://sysresccd.org), which said it was leaving 1MB
> unused
> before /dev/sda1.
>
> While I'm here, would anyone like to suggest suitable parameters to mkfs
> for
> any of my file-systems? Here's the fstab:
>
> /dev/sda1       /boot                   ext2    noauto,relatime         1
> 2
> /dev/sda2       none                    swap    sw                      0
> 0
> /dev/sda5       /                       ext4    relatime                0
> 1

you might want this to read relatime,discard to handle the trim
automagically.  if you are concerned about writes i'd suggest noatime for
all of these

> /dev/sda6       /var                    ext4    relatime                0
> 2
> /dev/sda7       /home                   ext4    relatime                0
> 2
> /dev/sda8       /var/cache/squid        ext4    relatime                0
> 3
> /dev/sda9       /usr/portage            ext4    relatime                0
> 3
> /dev/sda10      /usr/portage/packages   ext4    relatime                0
> 4
> /dev/sda11      /usr/local              ext4    relatime                0
> 2
> proc            /proc                   proc    defaults                0
> 0
> tmpfs           /tmp                    tmpfs   nodev,nosuid            0
> 0
> tmpfs           /var/tmp                tmpfs   nodev,nosuid            0
> 0
> shm             /dev/shm                tmpfs   nodev,nosuid,noexec     0
> 0
>
> I created all the ext4 file-systems with -O ^has_journal to avoid
> concentrated
> wear. Is this still a good idea nowadays? I'm happy to sacrifice the
> comfort of
> journalling since recovering this small box from backup is so quick and
> easy.
> Of course I did plenty of googling before doing anything and picked out
> what
> still seemed appropriate, but I could easily have missed something
> important.
>

my 2c is that if you have this little box lose power for any reason, if
you have a journal and have data ordered you will have a relatively
consistent drive.   without a journal corruption is missed until you need
it.
e2fsck with journal also much faster.
just depends what the box is doing - if you are expecting many writes (i
notice squidcache there) use a journal.
if it is a router only, or media pc then you can worry less, and just
format the squidcache partition if needed.

> --
> Regards
> Peter
>
>
>
[1] http://en.wikipedia.org/wiki/Trim_(computing)
[2] http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html