From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:28:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F08EDA3 for ; Sun, 3 Mar 2013 13:28:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2E873F for ; Sun, 3 Mar 2013 13:28:15 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UC8xa-000Ngd-SN; Sun, 03 Mar 2013 13:28:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r23DSBsg089816; Sun, 3 Mar 2013 06:28:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/MDO4WFekzg7aevDk2COyT Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Peter Jeremy In-Reply-To: <20130303042043.GH286@server.rulingia.com> References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Mar 2013 06:28:11 -0700 Message-ID: <1362317291.1195.216.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71 , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:28:16 -0000 On Sun, 2013-03-03 at 15:20 +1100, Peter Jeremy wrote: > On 2013-Mar-02 18:29:54 +0100, deeptech71 wrote: > > >When one of my flash drives is being heavily written to; typically by > >``svn update'' on /usr/src, located on the flash drive; the following > >can be said about filesystem behavior: > > > >- ``svn update'' seems to be able to quickly update a bunch of files, > > but is then unable to continue for a period of time. This behavior > > is cyclical, and cycles several times, depending on the amount of > > updating work to be done for a particular run of ``svn update''. > > This sounds like normal flash behaviour: You can only write to erased > blocks. The SSD firmware attempts to keep a free pool of erased blocks > but if you write too fast, you empty the free pool and need to wait for > the wear-levelling algorithm to move blocks around and erase them. > > Enabling TRIM (the '-t' flag on tunefs) will help if the drive supports > TRIM (if it doesn't, it'll probably just lockup). Otherwise, you need > to either put up with it or upgrade to a better SSD. > > I run into this regularly with the low-end SuperTalent drive in my > Netbook but have never seen it with the OCZ Agility4 that I use for > L2ARC in my fileserver. > I run into this behavior all the time too, mostly on arm systems that have an sd card or usb thumb driver as their main/only drive. It's especially annoying when you try to launch a program that isn't in the filesystem cache already, and you have to wait 10-20 seconds for it to be read in. I stop just short of calling that "normal" because it seems like we should be able to do better somehow... I don't think the problem is on the flash device itself (like waiting for some big internal cache to drain), it acts more like there aren't enough buffers on the OS side (they're all tied up waiting to be written), or it's a bio-queue sort problem, or maybe it's somehow intentional that writes have precedence over reads (that might make more sense on a system without a big disparity between read and write speed, especially given that writing for the purpose of swapping is important to free up memory). The fact that a huge backlog of writes to a slow flash-based device can block reads from faster devices makes me think this is somehow related to available buffers in the OS. I wonder if this could be one of those situations where reducing the amount of buffers improves responsiveness (if not necessarily overall throughput). -- Ian