Mailinglist Archive: opensuse-factory (439 mails)

< Previous Next >
Re: [opensuse-factory] Adding SSDs?
  • From: Jason <relentropy@xxxxxxxxx>
  • Date: Thu, 13 Mar 2014 01:11:50 -0400
  • Message-id: <1415505.JaR6S5Q459@host.laptop>
Hi Greg,

On Tuesday, March 11, 2014 13:18:24 Greg Freemyer wrote:
On Tue, Mar 11, 2014 at 9:11 AM, Jason <relentropy@xxxxxxxxx> wrote:
Hey, not the OP, but thanks for the info!

AFAIK btrfs has SSD mode but that only applies to how it writes the data,
fstrim is still applicable though I wouldn't recommend it for daily chron.

fstrim is a fairly lightweight process that adds no wear and tear to
the SSD. It does impact everything else trying to write to the disk
at the same time, but for a home PC/laptop it should be easy enough to
schedule fstrim during downtime. (For laptops, maybe it could be
called at either hibernate or wake-up time.)

Since fstrim does not know what the SSDs view of any of the data
blocks/pages is all it does is:

- Walk the filesystem allocation bitmap and send trim commands to the
SSD for all unallocated block ranges.

- The SSD then evaluates each range, if it is already tagged as
trimmed, there is nothing to do. If it is currently tagged as in use,
it tags it stale/unallocated. At that point, the garbage collector
can start to do it's thing.

Since all that is happening is flags are being updated for the benefit
of the garbage collector, it is extremely fast and it really doesn't
add any wear and tear to run fstrim nightly.

Weekly should suffice if you're not running hp databases off of it.

Database writes to existing tables replace the valid data in general,
they don't transition any filesystem data blocks/pages from allocated
to unallocated. Therefore fstrim would have no effect at all on SSD
hosting only rapidly updated database tables.

Note that the standard SSD garbage collection and wear-levelling gets
a heavy workout from a heavy database update load. It is just the
trim functionality that adds little or no value.
The exception is if the database is creating and deleting tables at a
high-rate and each table is stored in its own file. Then the
table/file deletes need to eventually trigger a trim.

Thank you for your insight, it's very valuable and thorough!

btw, your mails might as well be copy/pasted to the wiki:)


Greg

Kind regards,
Jason

--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups