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>