From owner-freebsd-fs@freebsd.org Thu Dec 29 20:39:41 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46EBBC96D58 for ; Thu, 29 Dec 2016 20:39:41 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D25B710D3 for ; Thu, 29 Dec 2016 20:39:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5083C20F.dip0.t-ipconnect.de [80.131.194.15]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id uBTKdbqU040927; Thu, 29 Dec 2016 20:39:37 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id uBTKdYQ2091622; Thu, 29 Dec 2016 21:39:35 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id uBTKdGR4033963; Thu, 29 Dec 2016 21:39:28 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201612292039.uBTKdGR4033963@fire.js.berklix.net> To: Kirk McKusick cc: freebsd-fs@freebsd.org Subject: Re: when ufs is 99% full, current seems to limit creat to 28672 bytes From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Mon, 26 Dec 2016 15:13:23 -0800." <201612262313.uBQNDNrX030075@chez.mckusick.com> Date: Thu, 29 Dec 2016 21:39:16 +0100 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 20:39:41 -0000 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" > > 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