So now reactions here, creating files with multilabel is still slow. I would like to use multilabel access control on my /tmp, for example, my web server places it's session files there in a subdirectory. Of course, I would like to assign a label for that subdir, but with this slow file creation, that is not the way to go. I may then use a different filesystem for that. In this case, can I assign a root mac label for a mount point? Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Sun, 15 Apr 2012, Garrett Cooper wrote: > Date: Sun, 15 Apr 2012 13:35:59 -0700 > From: Garrett Cooper <yanegomi_at_gmail.com> > To: O. Hartmann <ohartman_at_zedat.fu-berlin.de> > Cc: freebsd-security_at_freebsd.org, Richard Kojedzinszky <krichy_at_tvnetwork.hu>, > Current FreeBSD <freebsd-current_at_freebsd.org>, > freebsd-performance_at_freebsd.org > Subject: Re: ufs multilabel performance (fwd) > > On Apr 15, 2012, at 1:17 PM, O. Hartmann wrote: > >> Am 04/15/12 22:00, schrieb Garrett Cooper: >>> 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. >>>>> >>>>> 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. >>>>> >>>>> And anyway freebsd is known to be fast as well, as functional. The power >>>>> to serve. :) >>>>> >>>>> 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. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Kojedzinszky Richard >>>>> Euronet Magyarorszag Informatikai Zrt. >>>>> >>>>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>>>> >>>>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>>>> From: O. Hartmann <ohartman_at_zedat.fu-berlin.de> >>>>>> To: Richard Kojedzinszky <krichy_at_tvnetwork.hu> >>>>>> Cc: freebsd-security_at_freebsd.org >>>>>> Subject: Re: ufs multilabel performance (fwd) >>>>>> >>>>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>>>> Dear list, >>>>>>> >>>>>>> Although it is not only security-related question, I did not get any >>>>>>> answer from freebsd-performance. The original question is below. >>>>>>> >>>>>>> Can someone give some advice? >>>>>>> >>>>>>> Thanks in advance, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> Euronet Magyarorszag Informatikai Zrt. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>>>> From: Richard Kojedzinszky <krichy_at_tvnetwork.hu> >>>>>>> To: freebsd-performance_at_freebsd.org >>>>>>> Subject: ufs multilabel performance >>>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> I've noticed that when I enable multilabel on an fs, a file creation >>>>>>> gets around 20-30 times slower than without multilabel set. >>>>>>> >>>>>>> This one-liner can be used to test the differences: >>>>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>>>> >>>>>> Same here, creating files seems to be 10 - 30 times slower with >>>>>> multilabels as it is without. >>>>>> >>>>>> 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. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Could someone acknowledge this, and have some suggestions how to make it >>>>>>> faster? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> TvNetWork Nyrt. >>>>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>>>> Fingerprint = F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 >>>> >>>> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 >>>> boxes I have spare to test. >>>> >>>> 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. >>>> >>>> I'd like to test this again with a small C program. >>>> >>>> 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. >>>> >>>> >>>> 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=$(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 = 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_______________________________________________ >> >> This was pretty fast ;-) > > If it turns out that it wasn't that particular item that's causing a slowdown, I can easily modify my above snippet to use stdio, etc. But unless the version of perl and a few other items are the same, I wouldn't necessarily blame the guest OS. Please also make sure that Xen, etc is completely up-to-date because there were some performance degradation issues that were fixed post-6.0. > -Garrett_______________________________________________ > freebsd-security_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe_at_freebsd.org" >Received on Tue Apr 17 2012 - 04:31:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC