From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: [Lsf-pc] [LSF/FS TOPIC] Scaling file systems on high performance flash devices Date: Fri, 04 Feb 2011 11:58:24 -0500 Message-ID: <4D4C3030.6080906@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lsf-pc@lists.linuxfoundation.org, linux-fsdevel@vger.kernel.org To: Nauman Rafique Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:55937 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752794Ab1BDQ63 (ORCPT ); Fri, 4 Feb 2011 11:58:29 -0500 Received: by qwa26 with SMTP id 26so1940184qwa.19 for ; Fri, 04 Feb 2011 08:58:29 -0800 (PST) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 02/03/2011 07:39 PM, Nauman Rafique wrote: > Flash device vendors are coming up with faster and faster devices > every year. Given the high performance supported by these devices, > there are thoughts about using them not only as high performance > storage but also as a replacement for huge quantities of DRAM. That > particular use case would put very stringent requirements on the > performance of file systems on these devices --- an issue that should > be discussed. > > I will share our experience running some experiments on a high > performance flash device (FusionIO IODrive duo) with ext4 and XFS. We > have devised an extensive set of experiments focused on finding the > scaling and overhead problems in the kernel. Our experiments use > various IO sizes, and perform IO in both synchronous multi-threaded > mode and AIO mode. We configure our setup to bypass the block layer > (fusionIO driver supports that), and do IO in O_DIRECT mode to > minimize overhead in the kernel. In spite of such optimizations, we > still see performance issues especially while doing IO at the peak > throughput capacity available on these drives. The issues pertain to > CPU scheduling behavior, filesystem metadata manipulation, and > basically the whole kernel code path involved in doing IO to > such devices, that would not be involved if data was read from DRAM > directly. > > -- > Nauman Thanks, I think that this is a very good topic for us and should have broad interest... Ric