Date: Thu, 29 Dec 2016 21:39:16 +0100 From: "Julian H. Stacey" <jhs@berklix.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: freebsd-fs@freebsd.org Subject: Re: when ufs is 99% full, current seems to limit creat to 28672 bytes Message-ID: <201612292039.uBTKdGR4033963@fire.js.berklix.net> In-Reply-To: Your message "Mon, 26 Dec 2016 15:13:23 -0800." <201612262313.uBQNDNrX030075@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusick wrote Mon, 26 Dec 2016 15:13:23 -0800 > > 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612292039.uBTKdGR4033963>