NetBSD Problem Report #50726

From dholland@macaran.eecs.harvard.edu  Fri Jan 29 18:13:59 2016
Return-Path: <dholland@macaran.eecs.harvard.edu>
Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D45BC7ABE4
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 29 Jan 2016 18:13:58 +0000 (UTC)
Message-Id: <20160129181339.0DBAA6E25D@macaran.eecs.harvard.edu>
Date: Fri, 29 Jan 2016 13:13:38 -0500 (EST)
From: dholland@eecs.harvard.edu
Reply-To: dholland@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: ffs -o discard is slow
X-Send-Pr-Version: 3.95

>Number:         50726
>Category:       kern
>Synopsis:       ffs -o discard is slow
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 29 18:15:00 +0000 2016
>Originator:     David A. Holland
>Release:        NetBSD 7.99.25 (20151222)
>Organization:
>Environment:
System: NetBSD macaran 7.99.25 NetBSD 7.99.25 (MACARAN) #34: Tue Dec 22 23:55:33 EST 2015 dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

riz@ today reported that after deleting 3G of data with -o discard on
it was many seconds before the discards completed and the visible free
space stabilized. (With discard on, freed blocks don't show up as
available again until the storage-level discard operation finishes.)

There are possibly many reasons for this but a key one is that we
discard single blocks only and don't coalesce adjacent entries.

(This is not just a direct performance issue; discarding larger ranges
can be handled differently, i.e. better, by SSD firmware and result in
improved performance later on and also better wear life.)

>How-To-Repeat:

as above

>Fix:

hack hack hack, it's not trivial

(should discard requests be coalesced in ffs or at the disk level?
while all the internal plumbing I put in last time around is
synchronous so coalescing would have to be in ffs, there's something
to be said for queueing them at the disk level and letting the disk
munge pending requests. this would be even less trivial)

Home	PR Database Search