On 21 March 2012 02:24, Roberto Spadim <roberto@xxxxxxxxxxxxx> wrote: > =/ well maybe with a sas disk it could be faster? maybe a pciexpress disk too? > > Em 20 de março de 2012 23:08, Shaohua Li <shli@xxxxxxxxxx> escreveu: >> 2012/3/20 Shaohua Li <shli@xxxxxxxxxx>: >>> 2012/3/20 Holger Kiehl <Holger.Kiehl@xxxxxx>: >>>> Hello, >>>> >>>> >>>> On Tue, 20 Mar 2012, Shaohua Li wrote: >>>> >>>>> 2012/3/20 Holger Kiehl <Holger.Kiehl@xxxxxx>: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> On Fri, 16 Mar 2012, Shaohua Li wrote: >>>>>> >>>>>>> The patches add TRIM support for raid linear/0/1/10. I'll add TRIM >>>>>>> support >>>>>>> for >>>>>>> raid 4/5/6 later. The implementation is pretty straightforward and >>>>>>> self-explained. >>>>>>> >>>>>>> v1->v2: >>>>>>> 1. fixed a checking issue >>>>>>> 2. dropped discard request plug and replace it with no discard merege, >>>>>>> because >>>>>>> current SCSI layer can't handle discard request merge. >>>>>>> >>>>>> Have tested TRIM patches on three different systems with the following >>>>>> hardware/ setup: >>>>>> >>>>>> 1) root mounted on a raid1 over two SAS SSD's (200GB) and /home >>>>>> partition >>>>>> on a raid0 over a fusionio ioDrive Duo. Is very new and seen very >>>>>> little usage. >>>>>> >>>>>> 2) root and /home mounted on a raid0 over two Intel X25 Postville >>>>>> (160GB) connected to a Intel P55 Express chipset. Has seen very >>>>>> heavy usage for approx. 2 years. >>>>>> >>>>>> 3) root and /home mounted on a raid0 over three OCZ-VERTEX2 (120GB) >>>>>> connected via ICH7 south bridge. Has seen mild usage for approx. >>>>>> 1.5 years. >>>>>> >>>>>> Made the following observations when running my own benchmark which >>>>>> copies around a lot of small files and deletes them. The benchmark on >>>>>> all systems was always run only on the /home partition ie. on a raid0. >>>>>> >>>>>> For system 1) there is hardly any measurable differnce whether discard >>>>>> is enabled or not (~29000 files per second). >>>>>> >>>>>> On system 2) the performance drops from 6500->3700 files per second, >>>>>> but under normal usage one does not notice any difference. >>>>> >>>>> do you have the blktrace data when the benchmark is running, especially >>>>> when doing file deletion. I'd like to check the latency of discard in this >>>>> case. >>>>> >>>> It is uploaded on ftp://ftp.dwd.de/pub/afd/test/trim >>> Thanks, I'll check it. >> Thanks for the testing. The trace data is very helpful. In the intel >> SSD, trace data >> shows a discard request uses about 1 ~ 3 ms. The filesystem suffers from >> fragmentation too, so lots of small discard requests. When ext4 starts doing >> discard, it usually uses more than 1 minutes. That's too bad. >> If just looking one disk's trace data, there are some extra latencies between >> two discard requests. The combined trace data of two disks show the latency >> comes from waiting for another disk, so nothing abnormal. I thought we could >> do an optimization for this case in the future. >> So in summary, discard from the SSDs is slow. When your filesystem is >> fragmented, the performance will be terrible. >> >> Thanks, >> Shaohua >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Roberto Spadim > Spadim Technology / SPAEmpresarial > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Not relevant. Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
