| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 15 Apr 2013 16:41:42 +0000 From: "Sam Bradshaw (sbradshaw)" <sbradshaw@...ron.com> To: Jens Axboe <axboe@...nel.dk> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Asai Thambi Samymuthu Pattrayasamy (asamymuthupa) [CONT - Type 2]" <asamymuthupa@...ron.com> Subject: RE: [PATCH 2/2] mtip32xx: mtip32xx: Disable TRIM support > On Fri, Apr 12 2013, Asai Thambi S P wrote: > > > > Temporarily disabling TRIM support until TRIM related issues > > are addressed in the firmware. > > How serious is this? We do have released kernels out there with the > driver, you might want to consider a stable backport too. It's a performance issue, not data integrity. Since the ATA trim command is non-queueable, IO traffic must halt while the trim is outstanding. A filesystem that is actively trimming sectors is effectively duty cycling the IO path on this part. We are working to shrink the trim command latency while also investigating whether some sort of offline trim is more appropriate. Given the incremental endurance gain for trim on 34nm SLC vs the severe throughput degradation under some workloads, it seemed prudent to disable the feature. If you think that warrants a stable backport, just let me or Asai know. -Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists