Why at least 4 cylinder groups?

Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net
Tue Oct 11 16:18:49 UTC 2016


> 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.

I tracked back in svn and this was infact added with the UFS2 support,
I understand the goal in the code, which is good for larger file systems,
but is probably a bad idea when the file system total size is so small
that a CG would not contain at least something like 64 cylinders.  This
is a regersion, very old, but should probably be looked at by Kirk or
another FS expert.

Commit that added the relevant #define and code implementing MINCYLGRPS
https://svnweb.freebsd.org/base?view=revision&revision=98542

And relative parts of that commit:
https://svnweb.freebsd.org/base/head/sys/ufs/ffs/fs.h?r1=98542&r2=98541&pathrev=98542
https://svnweb.freebsd.org/base/head/sbin/newfs/mkfs.c?r1=98542&r2=98541&pathrev=98542
 
...
-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the freebsd-hackers mailing list