Mailinglist Archive: opensuse-project (479 mails)

< Previous Next >
Re: [opensuse-project] openSUSE 11.3, disk expert needed (SSD + hdparm/wiper.sh error: /usr/sbin/rdev needed but not found)
  • From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
  • Date: Wed, 12 Jan 2011 13:21:26 -0500
  • Message-id: <AANLkTimXE-6XFbmJDXY3wwXnF=vjW_XYwwb2TQ_2NY1K@mail.gmail.com>
On Wed, Jan 12, 2011 at 12:43 PM, Greg KH <gregkh@xxxxxxx> wrote:
On Wed, Jan 12, 2011 at 06:33:26PM +0100, Johannes Nohl wrote:
2011/1/12 Greg KH <gregkh@xxxxxxx>:
On Wed, Jan 12, 2011 at 05:29:58PM +0100, Johannes Nohl wrote:
I'd like to ask for feedback. How do you treat your SSD running
openSUSE 11.3?

Like a normal disk, not worrying about any TRIM crud or anything else
like that.  You should not have to ever send those types of commands to
the disk unless you feel like potentially causing problems :)

Great, but why does
http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support suggest to
use a tool like wiper.sh then? I would prefer to not interact with the
disk by intention at all.

I do not know at all.  But realize, these disks are designed to work in
systems that do not have TRIM support at all in them (i.e. some other
operating system), so not running these commands on your Linux system is
just fine.

thanks,

greg k-h

Greg,

Windows 7 has near real-time trim support and lots of laptops run that by now.

A kernel developer traced windows 7 with a SATA bus analyzer to see if
Windows 7 was doing the same thing as the linux kernel or not. I
believe to his surprise, Windows 7 was more sophisticated in its
handling.

As to linux kernel's "mount --discard" implementation, it is highly
non-optimized and has no real world net gain use cases. In theory
there are some NDA only pre-production units that show it as a net
benefit. But I've been hearing that for a couple years now, and from
the same people each time.

Thus the need for wiper.sh in a linux environment. It's been in
openSUSE since 11.2.

opensuse 11.4 should have a new kernel based batched discard (2.6.37
required), but it offers little that wiper.sh doesn't already have.
The latest util-linux has a small userspace app to call the new ioctl.
A cron job or similar will still be need to call the new userspace
app.

The main advantage of the new kernel code is eventually the DM and MD
portions of the block layer will add trim range translation support,
but until that happens, wiper.sh is superior from a performance
perspective because it handles bigger trim range payloads and it
handles more translations!

fyi: The performance difference between wiper.sh and the new kernel
patched discard support is not enough for both to be supported for the
long term in my opinion, but in a opensource world, you never know.
Redhat people wrote the new kernel logic, so they will likely ensure
it is supported long term.

Greg
--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups