Why at least 4 cylinder groups?

[Konstantin Belousov]

On Tue, Oct 11, 2016 at 06:14:09PM +1100, Peter Jeremy wrote:
> On 2016-Oct-11 08:50:44 +0200, Norbert Koch <nkoch at 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.