Date: Tue, 11 Oct 2016 19:06:46 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Jeremy <peter@rulingia.com> Cc: Norbert Koch <nkoch@demig.de>, freebsd-hackers@freebsd.org Subject: Re: Why at least 4 cylinder groups? Message-ID: <20161011160646.GT68202@kib.kiev.ua> In-Reply-To: <20161011071409.GL76775@server.rulingia.com> References: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> <20161011071409.GL76775@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 11, 2016 at 06:14:09PM +1100, Peter Jeremy wrote: > On 2016-Oct-11 08:50:44 +0200, Norbert Koch <nkoch@demig.de> wrote: > >Am 2016-10-10 um 17:26 schrieb Rodney W. Grimes: > >>> In an embedded system I am having a rather > >>> small (static) ram disk of about 1.5MB, > >>> formatted as UFS(1). > > ufs2 is designed to work around some space limitations in ufs1 and so > needs more space. If you're space-limited, ufs1 is probably a better choice. > > >>> Is there any technical reason not to have less > >>> than 4 cylinder groups? > >> Probably on a UFS2 file system yes, but as far as I can > >> see not on a UFS1 file system. > >> > >>> For my application the wasted 188KB make a difference. > ... > >So, afaics technically one cylinder group would be ok for UFS1, right? > > The reasons for multiple CGs are: > 1) Improve performance by limiting the seek distance to a CG. > 2) Provide redundant superblocks to protect against bad blocks. > Neither of these reasons apply to a ramdisk. > > If you're keen to maximise data space, you might like to also reduce > ipg (increase '-i'). I am not aware of the reason why MINCYLGRPS exists at all. If your goal is reducing the memory consumption for the kernel and metadata overhead with the fixed amount of data to access, you may consider using tmpfs. The additional kernel text size is tiny 50K, comparing with the 1.5M disk size. If you mmap(2) the data from the ramdisk, then you will save the amount of memory twice the size of your mmaped data. tmpfs allows to set limits on mount, so you can have safety belts as well. The recommendation is valid if you use stable/10, 11 or HEAD.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161011160646.GT68202>