misc/145395: [nanobsd] [patch] Extremely slow nanobsd disk
image creation and 100% disk load on zfs
Warner Losh
imp at bsdimp.com
Wed May 25 17:50:13 UTC 2011
The following reply was made to PR misc/145395; it has been noted by GNATS.
From: Warner Losh <imp at bsdimp.com>
To: Alex Bakhtin <alex.bakhtin at gmail.com>
Cc: bug-followup at FreeBSD.org, imp at FreeBSD.org
Subject: Re: misc/145395: [nanobsd] [patch] Extremely slow nanobsd disk image creation and 100% disk load on zfs
Date: Wed, 25 May 2011 11:38:46 -0600
If you are doing soft updates, you can't do async. They are mutually =
exclusive. Soft updates usually are a big win for creation, but might =
need to be turned off for async operations.
If you have an updated patch against -current, please let me know.
Warner
On May 25, 2011, at 7:35 AM, Alex Bakhtin wrote:
> Hello,
>=20
>=20
>> From-To:open->closed
>> By:imp When:Fri May 13 13:44:33 MDT 2011
>> Why:We've been doing async for a while now. Bug OBE.
>=20
> I'm really sorry, but today I have tested the nanobsd.sh from
> 9-CURRENT and I'm completely sure that the problem WAS NOT fixed. I
> discovered that building image is still extremelly slow and produces
> great disk load. After checking deeply, I found that image is not
> mounted in async mode.
>=20
> /dev/md2s1a on /mnt/system/obj/amtkit/_.mnt (ufs, local, soft-updates)
>=20
> I tried to mout in async manually - and it seems that async option
> is ignored for MD-backed filesystem:
>=20
> bakhtin at tarzan(14) /mnt/system/nanobsd/amtkit
>> sudo umount /mnt/system/obj/amtkit/_.mnt
>=20
> bakhtin at tarzan(14) /mnt/system/nanobsd/amtkit
>> sudo mount -o async /dev/md2s1a //mnt/system/obj/amtkit/_.mnt
>=20
>> mount | grep md
> /dev/md0 on /etc (ufs, local)
> /dev/md1 on /var (ufs, local)
> /dev/md2s1a on /mnt/system/obj/amtkit/_.mnt (ufs, local, soft-updates)
>=20
> As you can see - md2s1a is not mounted in async mode, and this causes
> extremely bad performance on ZFS.
>=20
> I'm pretty sure that attaching MD in async mode fixes this problem.
> Please review my patch and this bug.
>=20
>=20
> --
> ---
> Alex Bakhtin
>=20
>=20
More information about the freebsd-bugs
mailing list