Mailinglist Archive: opensuse-factory (345 mails)
< Previous | Next > |
Re: [opensuse-factory] SSD detection when creating first time fstab ?
- From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
- Date: Thu, 2 Jun 2011 11:32:42 -0400
- Message-id: <BANLkTik0E__p8XbKytAxgxE6ffq+xQR_Pg@mail.gmail.com>
On Thu, Jun 2, 2011 at 10:43 AM, Vincent Lejeune <vljn@xxxxxxx> wrote:
Vincent,
Give this a read:
http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support
I wrote most of that. It's about 6 or 9 months out of date, so the
discussion of FITRIM is deficient (or missing). FITRIM is a kernel
ioctl which was just added to the kernel last fall. (2.6.36? 2.6.37?)
I for one sincerely hope "mount -discard" is not an automatic feature
of 12.1. In all honesty, I wish it was dropped from the kernel
altogether. I still haven't seen any real world drive that gets
improved performance by interlacing trims into the middle of the
normal i/o traffic. But the kernel devs won't drop it because "there
are devices in the lab that benefit from it". I've been hearing that
for 2 or 3 years now. But the devices never get out of the lab.
Also, it was assumed 9 months ago that Windows 7 did it that way. But
since then one of the kernel devs got a sata protocol analyser and
monitored how Windows 7 is doing it. Not like "mount -discard" at
all, so that whole paradigm seems like a rat hole to me.
On the other hand, I would like to see the FITRIM ioctl called via
cron in the middle of the night in 12.1. The userspace tool that
calls that is fstrim. It is part or 11.4 I believe (I know its in
Tumbleweed). So calling fstrim via cron would be great. And if the
drive or block layer doesn't handle trim commands, the FITRIM ioctl
should just drop the discards on the ground. That is really the best
option in my mind right now.
Note FITRIM is still not as good as what Windows 7 is doing. The
claim is aggregating multiple trim ranges into one ATA command is hard
for the kernel to do, so it is still on the wish list, not the done
list.
Anyway, FITRIM does show performance benefit for real world drives and
it does the interrogation of the drive / block stack to see discard is
supported. Thus, openSUSE 12.1 would not need to know in advance if a
drive supported discard or not, it would just call fstrim on every
filesystem.
So, if you create a openfate entry to have 12.1 call fstrim via cron,
I for one would likely vote for it.
Note: There is still discussion on the kernel lists about the best way
to handle discard. So for 12.2 it maybe back to being a kernel mount
option which triggers a kernel thread to run and maintain a background
free block scavenger. It really is up in the air. So one could argue
that it is still premature to put a real fix in 12.1 just to see it
removed in 12.2 in favor of a totally different fix.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
Hi,
The setup process of opensuse creates a /etc/fstab according to partition
settings on the SSD/hard drive.
However there is no detection of the type (ie SSD or hard drive) during this
process.
I discovered that the TRIM functionnality was not supported by default on
ext4 file system.
TRIM aims at extending duration of SSD by delaying some write/delete
operations ; besides it improves performance of SSD.
To get TRIM support on ext4, the partition must be mounted with the "discard"
option in /etc/fstab.
Would it be possible for 12.1 to make the detection script able to spot a SSD
and add this option at the setup step of openSUSE installation ?
I think that SSD users are not always aware that they need to tweak their
/etc/fstab to preserve their drive...
I have no idea if TRIM support can be retrieved from SSD information at the
kernel level.
Vincent
Vincent,
Give this a read:
http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support
I wrote most of that. It's about 6 or 9 months out of date, so the
discussion of FITRIM is deficient (or missing). FITRIM is a kernel
ioctl which was just added to the kernel last fall. (2.6.36? 2.6.37?)
I for one sincerely hope "mount -discard" is not an automatic feature
of 12.1. In all honesty, I wish it was dropped from the kernel
altogether. I still haven't seen any real world drive that gets
improved performance by interlacing trims into the middle of the
normal i/o traffic. But the kernel devs won't drop it because "there
are devices in the lab that benefit from it". I've been hearing that
for 2 or 3 years now. But the devices never get out of the lab.
Also, it was assumed 9 months ago that Windows 7 did it that way. But
since then one of the kernel devs got a sata protocol analyser and
monitored how Windows 7 is doing it. Not like "mount -discard" at
all, so that whole paradigm seems like a rat hole to me.
On the other hand, I would like to see the FITRIM ioctl called via
cron in the middle of the night in 12.1. The userspace tool that
calls that is fstrim. It is part or 11.4 I believe (I know its in
Tumbleweed). So calling fstrim via cron would be great. And if the
drive or block layer doesn't handle trim commands, the FITRIM ioctl
should just drop the discards on the ground. That is really the best
option in my mind right now.
Note FITRIM is still not as good as what Windows 7 is doing. The
claim is aggregating multiple trim ranges into one ATA command is hard
for the kernel to do, so it is still on the wish list, not the done
list.
Anyway, FITRIM does show performance benefit for real world drives and
it does the interrogation of the drive / block stack to see discard is
supported. Thus, openSUSE 12.1 would not need to know in advance if a
drive supported discard or not, it would just call fstrim on every
filesystem.
So, if you create a openfate entry to have 12.1 call fstrim via cron,
I for one would likely vote for it.
Note: There is still discussion on the kernel lists about the best way
to handle discard. So for 12.2 it maybe back to being a kernel mount
option which triggers a kernel thread to run and maintain a background
free block scavenger. It really is up in the air. So one could argue
that it is still premature to put a real fix in 12.1 just to see it
removed in 12.2 in favor of a totally different fix.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
< Previous | Next > |