Re: More into /etc/rc.d/jail

From: Glenn Dawson <glenn_at_antimatter.net>
Date: Wed, 10 Aug 2005 11:19:33 -0700
At 03:31 AM 8/10/2005, Jeremie Le Hen wrote:
>Hi Glenn,
>
> > >This was recently discussed in some thread.  The problem with this
> > >approach is that file backed md(4) devices are too slow to make it
> > >standard.  This is why this won't go into FreeBSD, IMHO.
> >
> > I experienced the same performance problem when comparing md(4) virtual
> > disks in 5.x to vn(4) virtual disks in 4.x.
> >
> > The results were that md(4) file backed disks in 5.x was only about 1/3 
> the
> > speed of vn(4) file backed disks in 4.x.
> >
> > Ultimately it turned out that newfs in 5.x creates ufs1 file systems which
> > are quite different than the same file system created with newfs in
> > 4.x.  The most notable difference was that in 5.x each cylinder group
> > essentially only had one cylinder in it.
> >
> > When a file system was created in 4.x and then mounted in 5.x using md(4),
> > the performance was almost identical to the performance of vn(4) in 4.x.
> >
> > I posted a message about it on the freebsd-fs list, but never received any
> > feedback.
>
>I just tested what you are saying.  I first created a file backed vn(4)
>device on my RELENG_4, disklabel(8)'ed and newfs(8)'ed it :
>%%%
>     yoda:root# dd if=/dev/zero of=newfs4x bs=1m count=50
>     yoda:root# vnconfig -c vn0 newfs4x
>     yoda:root# disklabel -r -w vn0 auto
>     yoda:root# newfs /dev/vn0c
>     yoda:root# vnconfig -u vn0
>%%%
>
>I copied it to my CURRENT box, and then I created a file backed md(4)
>device, bsdlabel(8)'ed and newfs(8)'ed it (note that labeling is not
>required since 5.x, but I have done it for the sake of consistency) :
>%%%
>     jarjarbinks:space# dd if=/dev/zero of=newfs7x bs=1m count=50
>     jarjarbinks:space# mdconfig -at vnode -f newfs7x
>     jarjarbinks:space# bsdlabel -r -w md1 auto
>     jarjarbinks:space# newfs -O 1 /dev/md1c
>     jarjarbinks:space# mdconfig -du 1
>%%%

That is basically what I did.  The only real difference is the block size 
that you used. (I was using 512 byte blocks)

It's interesting that you got nearly identical numbers.  The test that I 
ran was showing about 20Mbytes/sec under 4.x and about 7MB/sec under 
5.x.  The only way I could get 5.x to come close to the 4.x numbers was to 
use newfs in 4.x and then mount that file system in 5.x.  (I had a boot 
disk with two slices, 4.x and 5.x, and two other disks in the same machine 
that I used for testing.)

I'll run the tests again, and post the results.  Either I was doing 
something horribly wrong, or there's more to it than just using the 4.x 
newfs.  I ran the test over and over with the exact same result.

-Glenn



>And now the benchmark :
>%%%
>     jarjarbinks:space# mdconfig -at vnode -f newfs4x -u 4
>     jarjarbinks:space# mdconfig -at vnode -f newfs7x -u 7
>     jarjarbinks:space# mount /dev/md4 /mnt/newfs4x/
>     jarjarbinks:space# mount /dev/md7 /mnt/newfs7x/
>
>     # File backed filesystem created on RELENG_4 :
>     jarjarbinks:space# cd /mnt/newfs4x/
>     jarjarbinks:newfs4x# for i in `jot 10 ` ; do dd if=/dev/zero of=foo 
> bs=1m count=45 2>&1 | sed -n '$p' ; done
>     47185920 bytes transferred in 3.149436 secs (14982340 bytes/sec)
>     47185920 bytes transferred in 3.226415 secs (14624877 bytes/sec)
>     47185920 bytes transferred in 3.095972 secs (15241069 bytes/sec)
>     47185920 bytes transferred in 3.192095 secs (14782116 bytes/sec)
>     47185920 bytes transferred in 3.122508 secs (15111545 bytes/sec)
>     47185920 bytes transferred in 3.020874 secs (15619956 bytes/sec)
>     47185920 bytes transferred in 3.197009 secs (14759396 bytes/sec)
>     47185920 bytes transferred in 3.382755 secs (13948962 bytes/sec)
>     47185920 bytes transferred in 3.373716 secs (13986334 bytes/sec)
>     47185920 bytes transferred in 3.320148 secs (14211993 bytes/sec)
>
>     # File backed filesystem created on CURRENT :
>     jarjarbinks:newfs4x# cd /mnt/newfs7x/
>     jarjarbinks:newfs7x# for i in `jot 10 ` ; do dd if=/dev/zero of=foo 
> bs=1m count=45 2>&1 | sed -n '$p' ; done
>     47185920 bytes transferred in 3.329189 secs (14173399 bytes/sec)
>     47185920 bytes transferred in 3.469024 secs (13602074 bytes/sec)
>     47185920 bytes transferred in 3.662984 secs (12881825 bytes/sec)
>     47185920 bytes transferred in 3.558615 secs (13259630 bytes/sec)
>     47185920 bytes transferred in 3.241910 secs (14554975 bytes/sec)
>     47185920 bytes transferred in 3.339987 secs (14127577 bytes/sec)
>     47185920 bytes transferred in 3.498271 secs (13488355 bytes/sec)
>     47185920 bytes transferred in 3.194855 secs (14769346 bytes/sec)
>     47185920 bytes transferred in 3.746663 secs (12594120 bytes/sec)
>     47185920 bytes transferred in 3.358272 secs (14050654 bytes/sec)
>%%%
>
>As you can see, there is a small performance difference between
>the the one created by RELENG_4's newfs(8) and CURRENT's one.
>
>I've ran this test 100 times on each and made some statistics on the
>results :
>%%%
>     x newfs4x.result
>     + newfs7x.result
>     [...]
>     N           Min           Max        Median           Avg        Stddev
>     x 
> 100      12935312      16175549      14715640      14645011     685871.34
>     + 
> 100      11957991      16434651      14063540      14166142     907669.84
>     Difference at 95.0% confidence
>         -478869 +/- 222983
>         -3.26985% +/- 1.52258%
>         (Student's t, pooled s = 804451)
>%%%
>
>I've also compared RELENG_4's UFS1 and CURRENT's UFS2 :
>%%%
>     x newfs4x.result
>     + newfs7x.result.ufs2
>     [...]
>         N           Min           Max        Median           Avg 
> Stddev
>     x 
> 100      12935312      16175549      14715640      14645011     685871.34
>     + 
> 100      11368526      16089835      13619242      13727881      851634.8
>     Difference at 95.0% confidence
>         -917130 +/- 214322
>         -6.2624% +/- 1.46345%
>         (Student's t, pooled s = 773208)
>%%%
>
>Regards,
>--
>Jeremie Le Hen
>< jeremie at le-hen dot org >< ttz at chchile dot org >
>_______________________________________________
>freebsd-current_at_freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Wed Aug 10 2005 - 16:18:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:41 UTC