Re: CD9660/md(4)/UFS22 silly behaviour
--JMMA/5w7oqUUivCa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 08, 2012 at 10:21:50PM +0000, Poul-Henning Kamp wrote:
>=20
> I'm doing som data-mining on a pile of ISO images right now.
>=20
> I stuck the ISOs on a UFS2 on a flash-disk for speed, and mdconfig(8)'d
> them so I could mount them.
>=20
> The traffic pattern his "interesting":
>=20
> 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
>=20
> Notice the 1:16 ratio on kBps but 1:1 ratio on ops/s ?
>=20
> da0's UFS2 has 32k block-size:
>=20
> 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
> [...]
>=20
> It looks like every 2k read from CD9660 turns into a 32k block
> read in the UFS filesystem, without any beneficial caching happening.
>=20
> Less than optimal I'd say...
>=20
What is the access patern ? Is it random access, or sequential read
(from the cd9660 POV) ?
--JMMA/5w7oqUUivCa
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk8KGEgACgkQC3+MBN1Mb4jruQCcCzy7Ple7akRe/HtI+bfw/TnC
nksAniu/bgOQg5rDZS0+6wbTKBqDrA3m
=0mal
-----END PGP SIGNATURE-----
--JMMA/5w7oqUUivCa--
討論串 (同標題文章)
完整討論串 (本文為第 2 之 8 篇)：