Hi Greg, Thanks for the information. On 26/08/10 00:29, Greg Freemyer wrote:
[...] I have started a reference page on the wiki. It needs further elaboration, but it's worth a read:
I've read it, thanks for starting this page. I get the impression though, that using an SSD for a non-experienced Linux user is far too complicated at the moment. Given that the use of SSDs increases rapidly, I think something needs to be done to make such hardware easier to use - I think at the end of the day users don't want to think about alignments of filesystems, special mount options, setting up cron jobs etc to use an SSD.
[...] ext4 and xfs have internal discard support, BUT it is highly non-optimized and as such is not a significant performance benefit. The major issue is the trim commands require the command queue on the SSD be flushed. So interspersing trims with normal i/o is not a great solution.
fyi: Windows also intersperses the commands, so it to does not greatly benefit.
In my opinion, a better solution for now is to use the wiper.sh script described in the wiki page. wiper.sh depends on fallocate() being supported by the filesystem. Many do including ext3, ext4, xfs. Not sure which others.
The big problem with wiper.sh is it has no support for lvm / dm / md setups. And worse I don't think it detects the problem, so if used with partitions on those setups it could cause data loss!
I have now installed openSUSE 11.3 on a OCZ Vertex 2E SSD. I used a standard ext4 filesystem, the mount options at the moment are "rw,noatime,acl,user_xattr". Unfortunately, wiper.sh doesn't work at all. $> wiper.sh --verbose --commit /dev/sdb1 wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord. wiper.sh: This tool is DANGEROUS! Please read and understand wiper.sh: /usr/share/doc/packages/hdparm/README.wiper wiper.sh: before going any further. rootdev=/dev/sdb1 fsmode2: fsmode=read-write /: fstype=ext4 freesize = 45338732 KB, reserved = 453387 KB Preparing for online TRIM of free space on /dev/sdb1 (ext4 mounted read-write at /). This operation could silently destroy your data. Are you sure (y/N)? y Creating temporary file (44885345 KB).. Syncing disks.. Beginning TRIM operations.. get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.13467 /dev/sdb: trimming 89770696 sectors from 1493 ranges FAILED: Input/output error Removing temporary file.. Syncing disks.. Aborted. No joy, obviously. So what can I do? Should I try the "discard" mount option? Or would that really hurt performance? The motherboard, by the way, is an Asus P6X58D-E, the SSD is attached to one of the 3GB/s SATA ports (Intel chip). There's also a 6GB/s SATA port (Marvell chip) on the board, but I couldn't find Linux support for that (that's why I haven't used this port).
[...]
With the exception of Intel SSDs I would use the script unless you are using lvm / dm / md. The script is in oS 11.2 and 11.3
Well,... See above. Regards, Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org