Re: ufs multilabel performance (fwd)

Without any benchmarks I would also think for the high io, in the xen dom0 I see high disk activity (eg 99% writes) when using mac labels. But of course I will do the tests, please give some instructions, how to compile the kernel, how the implement the benchmark.

Thanks in advance,

Kojedzinszky Richard
Euronet Magyarorszag Informatikai Zrt.

On Tue, 17 Apr 2012, Edward Tomasz Napierała wrote:

Date: Tue, 17 Apr 2012 22:57:09 +0200
From: Edward Tomasz Napierała <trasz@xxxxxxxxxxx>
To: Adrian Chadd <adrian@xxxxxxxxxxx>
Cc: Richard Kojedzinszky <krichy@xxxxxxxxxxxx>,
Garrett Cooper <yanegomi@xxxxxxxxx>, freebsd-security@xxxxxxxxxxx,
Current FreeBSD <freebsd-current@xxxxxxxxxxx>,
O. Hartmann <ohartman@xxxxxxxxxxxxxxxxxx>
Subject: Re: ufs multilabel performance (fwd)

Wiadomość napisana przez Adrian Chadd w dniu 17 kwi 2012, o godz. 21:17:
On 16 April 2012 23:31, Richard Kojedzinszky <krichy@xxxxxxxxxxxx> wrote:

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?


This is a perfect job for hwpmc / dtrace.

Would you be able to load up either of those and get some CPU usage
statistics whilst you're running your benchmark?

It's either that, or it's (massive) locking contention.

Or disk I/O. MAC labels, just like ACLs, are stored in extended attributes,
and I remember something about writing those being synchronous.

If you cut off my head, what would I say? Me and my head, or me and my body?
freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"