when ufs is 99% full, current seems to limit creat to 28672 bytes

[Julian H. Stacey]

Kirk McKusick wrote Mon, 26 Dec 2016 15:13:23 -0800
> > To: freebsd-fs at freebsd.org
> > Subject: Re: when ufs is 99% full, current seems to limit creat to 28672 bytes
> > From: "Julian H. Stacey" <jhs at 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  1339169
> >   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-printable.
> >  http://berklix.eu/brexit/#stolen_votes
> 
> You HAVE made a change to the filesystem parameters. You have set
> minfree to 0%.

Sorry for my delay replying. Thanks for yours.

Yes. Crossed wires :-)
I meant I ran plain newfs years back, but yes I did a few days back run
tunefs -m 0 to try to write all last blocks, per my original post:

jhs> How I noticed:
jhs>   I wanted to soak up every last block on FS, (cos Ive been having
jhs>   block device errors, so I wanted to force a read write on all
jhs>   unused blocks to hopefully get IDE drive to re-allocate anything flakey.)


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

Interesting thanks :-)

It was really a temporary cludge of mine to tickle for bad blocks,
working from inside the file system. I'd better do it properly,
unmount & experiment with eg camcontrol on the partition or whole
disk, or search ports/ &/or write  a little C prog that reads blocks
from a file (aka dev name of partition or whole disk, stores, to
memory, & writes back blocks)

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