Date: Sun, 15 Apr 2012 13:00:25 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: O. Hartmann <ohartman@zedat.fu-berlin.de> Cc: freebsd-security@freebsd.org, Richard Kojedzinszky <krichy@tvnetwork.hu>, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) Message-ID: <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> In-Reply-To: <4F8B21D2.4080008@zedat.fu-berlin.de> References: <alpine.DEB.2.02.1204142134050.8001@krichy.tvnetwork.hu> <4F8AAEF7.3090800@zedat.fu-berlin.de> <alpine.DEB.2.02.1204151555080.12537@krichy.tvnetwork.hu> <4F8B21D2.4080008@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote:
> Am 04/15/12 15:59, schrieb Richard Kojedzinszky:
>> Thank you for the reply.
>>=20
>> Unfortunately, dont know why, but on my xen virtualised environment,
>> fbsd amd64 domU performs much slower, not only 30 times. Without
>> multilabel, file creation speed is around 2500/s, but with =
multilabels
>> enabled, it is only 15/s (!). so it is more than 100 times slower.
>>=20
>> And anyway freebsd is known to be fast as well, as functional. The =
power
>> to serve. :)
>>=20
>> But in my environment, 15/s file creation is very-very slow. The
>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the =
host
>> runs linux. I think with this hw the mentioned speed is really slow.
>>=20
>> Regards,
>>=20
>>=20
>> Kojedzinszky Richard
>> Euronet Magyarorszag Informatikai Zrt.
>>=20
>> On Sun, 15 Apr 2012, O. Hartmann wrote:
>>=20
>>> Date: Sun, 15 Apr 2012 13:20:23 +0200
>>> From: O. Hartmann <ohartman@zedat.fu-berlin.de>
>>> To: Richard Kojedzinszky <krichy@tvnetwork.hu>
>>> Cc: freebsd-security@freebsd.org
>>> Subject: Re: ufs multilabel performance (fwd)
>>>=20
>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky:
>>>> Dear list,
>>>>=20
>>>> Although it is not only security-related question, I did not get =
any
>>>> answer from freebsd-performance. The original question is below.
>>>>=20
>>>> Can someone give some advice?
>>>>=20
>>>> Thanks in advance,
>>>>=20
>>>>=20
>>>> Kojedzinszky Richard
>>>> Euronet Magyarorszag Informatikai Zrt.
>>>>=20
>>>> ---------- Forwarded message ----------
>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET)
>>>> From: Richard Kojedzinszky <krichy@tvnetwork.hu>
>>>> To: freebsd-performance@freebsd.org
>>>> Subject: ufs multilabel performance
>>>>=20
>>>> Dear List,
>>>>=20
>>>> I've noticed that when I enable multilabel on an fs, a file =
creation
>>>> gets around 20-30 times slower than without multilabel set.
>>>>=20
>>>> This one-liner can be used to test the differences:
>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000'
>>>=20
>>> Same here, creating files seems to be 10 - 30 times slower with
>>> multilabels as it is without.
>>>=20
>>> But as several posts and discussions reflects, FreeBSD isn't =
supposed to
>>> be fast although it is claimed that writing is the major than =
reading;
>>> FBSD should serve functionality.
>>>>=20
>>>> And one can see that the open call takes much more when multilabel =
is
>>>> set on an fs. It seems that only file creation needs that many =
time,
>>>> when a file exists it is opened much faster.
>>>>=20
>>>> Could someone acknowledge this, and have some suggestions how to =
make it
>>>> faster?
>>>>=20
>>>> Regards,
>>>>=20
>>>>=20
>>>> Kojedzinszky Richard
>>>> TvNetWork Nyrt.
>>>> E-mail: krichy (at) tvnetwork [dot] hu
>>>> PGP: 0x54B2BF0C8F59B1B7
>>>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7
>=20
> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10
> boxes I have spare to test.
>=20
> I just tried to reproduce your observation and as far as I can go with
> my experience, I can confirm that by using your perl script.
>=20
> I'd like to test this again with a small C program.
>=20
> I can only test the issue (test is too far optimistic, it's simply a
> reproduction of your observation) on FreeBSD 10, the only remaining
> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and =
"in
> production", so changing multilabel support is a bit harsh at the =
moment.
>=20
>=20
> Sorry about crossposting, but I think this belongs more to CURRENT and
> PERFORMANCE than SECURITY.
My suggestion is completely take perl out of the equation because the =
way you're invoking it above uses stdio and a few other things that add =
unnecessary overhead.
Try the attached C program/bourne shell snippet instead.
Cheers,
-Garrett
#!/bin/sh
set -e
tmp=3D$(mktemp -d tmp.XXXXXX)
trap "cd /; rm -Rf $tmp" EXIT
cd $tmp
cat > test_open.c <<EOF
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
int
main(void)
{
char buf[20];
int i;
for (i =3D 0; i < 1000; i++) {
sprintf(buf, "%d", i);
close(open(buf, O_WRONLY|O_CREAT, 0600));
}
return (0);
}
EOF
gcc -o test_open test_open.c
time ./test_open=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?951B1A8C-A216-420A-BA17-316B8D9C2B0E>