> 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


Reply via email to