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

From: Emanuel Strobl <Emanuel.strobl_at_gmx.net>
Date: Tue, 9 Aug 2005 23:35:11 +0200
Am Dienstag, 9. August 2005 21:10 CEST schrieb drvince_at_safe-mail.net:
> Hi,
> I'm using jails inside md devices to limit the disk space each jail can
> use.  It's working great but I have to start manually all of them at
> startup.  Here's my drill:
>
> mdconfig -a -t vnode -f ${IMAGE} -u ${ID}
> fsck_ufs /dev/md${ID}c
> mount /dev/md${ID}c ${DEST}
> mount_devfs devfs ${DEST}/dev
> jail -l -U root ${DEST} ${FQDN} ${IP} /bin/sh /etc/rc

And you don't suffer from a big disk performance degradation with that?
If you don't have I/O load it doesn't matter but I need usual I/O 
performance so I give each jail its own partition (GPT partitions).
But I think some good guys are looking for fixing the performance issue 
like they already solved the nullfs problem :) Thanks again for that! 
(Jeff?)
So it was fine to have the stuff you suggested in the future.

-Harry 

> Therefore, I can't use the /etc/rc.d/jail facility.  So I thought, it
> would be good to add *fsck before mounting* and an optional mdconfig
> beforehand.
>
> jail_${NAME}_md_device=""    # The device to attach or NO
> jail_${NAME}_image=""        # The image file containing the jail, used
> with md_device jail_${NAME}_fsck_options="" # Options to pass to fsck
>
> In fsck_options I could put "-t ufs".  Of course, /dev/md${ID}c must be
> present before mounting, could happen if the image isn't bsdlabel'ed.
>
> I'm a terrible coder, I could do it, but I'll need coaching and I've
> never made a patch.  I would gladly hand that to someone else but I also
> need it to be done, I can't babysit the server forever.  So, how does it
> sound?
>
> DrVince
> _______________________________________________
> 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 Tue Aug 09 2005 - 19:36:10 UTC

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