Date: Sun, 8 Jan 2012 16:09:00 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: phk@phk.freebsd.dk Cc: current@FreeBSD.org Subject: Re: CD9660/md(4)/UFS22 silly behaviour Message-ID: <201201090009.q09090sR024751@gw.catspoiler.org> In-Reply-To: <8334.1326061310@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201090009.q09090sR024751>