Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Dec 2016 15:13:23 -0800
From:      Kirk McKusick <mckusick@mckusick.com>
To:        "Julian H. Stacey" <jhs@berklix.com>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: when ufs is 99% full, current seems to limit creat to 28672 bytes
Message-ID:  <201612262313.uBQNDNrX030075@chez.mckusick.com>
In-Reply-To: <201612261721.uBQHKxcJ056264@fire.js.berklix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> To: freebsd-fs@freebsd.org
> Subject: Re: when ufs is 99% full, current seems to limit creat to 28672=
 bytes
> From: "Julian H. Stacey" <jhs@berklix.com>
> Date: Mon, 26 Dec 2016 18:20:59 +0100
> =

> Gary J wrote:
> =

> > I suspect this ia a result of how UFS is designed.
> =

> Yes.
> =

> > Did you use the
> > standard options for block and fragment size?  How about inodes?
> =

> Yes, I created that partition years ago, I pretty much always just
> use newfs unless experimenting perhaps for a small partition on USB
> stick or CDROM (& then I'd normally delete), so it would have been
> a newfs almost guaranteed with no parameters, default.
> =

> > Is the file system UFS1 or UFS2?
> =

> UFS2
> =

> =

> > UFS is a very compex bit of software and I imagine there are all
> > kinds of interesting surprises when the file system is 99% full.
> > =

> > Anyway, the newfs man page may provide some clues.  Or look at
> > Wikipedia, there's a UFS entry there, but it doesn't go into the gorey
> > details.
> =

> I'll read https://en.wikipedia.org/wiki/Unix_File_System
> =

> Konstantin B wrote
> > dumpfs(8) allows to look at ....
> =

> Top of dumpfs:
>   magic   19540119 (UFS2) time    Sun Dec 25 03:19:13 2016
>   superblock location     65536   id      [ 548daf7f b34ae147 ]
>   ncg     1399    size    224197115       blocks  217157317
>   bsize   32768   shift   15      mask    0xffff8000
>   fsize   4096    shift   12      mask    0xfffff000
>   frag    8       shift   3       fsbtodb 3
>   minfree 0%      optim   space   symlinklen 120
>   maxbsize 32768  maxbpg  4096    maxcontig 4     contigsumsize 4
>   nbfree  0       ndir    1555427 nifree  102683126       nffree  133916=
9
>   bpg     20035   fpg     160280  ipg     80256   unrefs  0
>   nindir  4096    inopb   128     maxfilesize     2252349704110079
>   sbsize  4096    cgsize  32768   csaddr  5056    cssize  24576
>   sblkno  24      cblkno  32      iblkno  40      dblkno  5056
>   cgrotor 622     fmod    0       ronly   0       clean   1
>   metaspace 6408  avgfpdir 64     avgfilesize 16384
>   flags   soft-updates =

>   fsmnt   /data
>   volname         swuid   0       providersize    224197115
> =

> Thanks All,
> =

> Cheers,
> Julian
> -- =

> Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
>  Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-pri=
ntable.
>  http://berklix.eu/brexit/#stolen_votes

You HAVE made a change to the filesystem parameters. You have set
minfree to 0%. This means that you are not allowing UFS to keep any
blocks in reserve.  At this point you have no full sized blocks
left in the filesystem (nbfree =3D=3D 0). Thus the only thing left in =

the filesystem is fragments. A file in UFS is made up of zero or
more full-sized blocks and at most one fragment. When you have used
up all of the full-sized blocks you cannot create files larger than
the largest available fragment. So if you continue with your
experiment you will find that the biggest file you can create will
eventually fall to 1K.

So long as you keep minfree at 1% or higher, you will not hit this
condition which is why tunefs warns you not to set minfree to
absurdly low values. If you want to ensure that your filesystem can
be filled to the last block, you should set the blocksize and the
fragment size to the same value. This will ensure that your filesystem
has only full-sized blocks and never creates fragments. Thus you
will be able to allocate files until it is compelely full.

	Kirk McKusick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612262313.uBQNDNrX030075>