From owner-freebsd-current@FreeBSD.ORG  Mon Jan  9 00:09:08 2012
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 5A8561065670
	for <current@FreeBSD.org>; Mon,  9 Jan 2012 00:09:08 +0000 (UTC)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242])
	by mx1.freebsd.org (Postfix) with ESMTP id 3C8638FC0C
	for <current@FreeBSD.org>; Mon,  9 Jan 2012 00:09:08 +0000 (UTC)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q09090sR024751;
	Sun, 8 Jan 2012 16:09:04 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <201201090009.q09090sR024751@gw.catspoiler.org>
Date: Sun, 8 Jan 2012 16:09:00 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: phk@phk.freebsd.dk
In-Reply-To: <8334.1326061310@critter.freebsd.dk>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: current@FreeBSD.org
Subject: Re: CD9660/md(4)/UFS22 silly behaviour
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jan 2012 00:09:08 -0000

On  8 Jan, Poul-Henning Kamp wrote:
> 
> I'm doing som data-mining on a pile of ISO images right now.
> 
> I stuck the ISOs on a UFS2 on a flash-disk for speed, and mdconfig(8)'d
> them so I could mount them.
> 
> The traffic pattern his "interesting":
> 
> dT: 1.003s  w: 1.000s
>  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
> [...]
>     1    733    733   1466    1.3      0      0    0.0   98.2| md39
>     1    733    733  23449    1.3      0      0    0.0   93.2| da0
> 
> Notice the 1:16 ratio on kBps but 1:1 ratio on ops/s ?
> 
> da0's UFS2 has 32k block-size:
> 
> 	magic   19540119 (UFS2) time    Wed Jan  4 16:41:47 2012
> 	superblock location     65536   id      [ 4f046cf5 c30697ee ]
> 	ncg     104     size    19537685        blocks  19228156
> 	bsize   32768   shift   15      mask    0xffff8000
> 	fsize   4096    shift   12      mask    0xfffff000
> 	[...]
> 
> It looks like every 2k read from CD9660 turns into a 32k block
> read in the UFS filesystem, without any beneficial caching happening.

Probably some confusion about which filesystem layer owns the cached
data.  It would probably be inefficient to cache the data in both
places.  The best fix would probably be for CD9660 to think that the
underlying device has 32Kb sectors.