From owner-freebsd-fs@freebsd.org Mon Dec 26 09:11:28 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 5F94FC8F037 for ; Mon, 26 Dec 2016 09:11:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2DEB1CAC for ; Mon, 26 Dec 2016 09:11:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uBQ9BHWa053664 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Dec 2016 11:11:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBQ9BHWa053664 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBQ9BH4M053663; Mon, 26 Dec 2016 11:11:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Dec 2016 11:11:16 +0200 From: Konstantin Belousov To: Shane Ambler Cc: gljennjohn@gmail.com, freebsd-fs@freebsd.org Subject: Re: when ufs is 99% full, current seems to limit creat to 28672 bytes Message-ID: <20161226091116.GO94325@kib.kiev.ua> References: <201612250331.uBP3Un70004592@fire.js.berklix.net> <20161225111148.6ee769b8@ernst.home> <86167004-c918-f879-e8d9-9abd38e94499@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86167004-c918-f879-e8d9-9abd38e94499@ShaneWare.Biz> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Mon, 26 Dec 2016 09:11:28 -0000 On Mon, Dec 26, 2016 at 01:51:56PM +1030, Shane Ambler wrote: > On 25/12/2016 20:41, Gary Jennejohn wrote: > > On Sun, 25 Dec 2016 04:30:49 +0100 > > "Julian H. Stacey" wrote: > > > >> A puzzle below, that I think I've solved, but comments welcome: > >> When ufs is 99% full, current limits creat to 28672 bytes. > >> > > >> Produces loads of little files of size 28672 bytes = 0x7000 > >> > >> A foreground fsck of FS shows no errors. No ZFS in use. Where > >> does all the extra space come from ? Why does it keep allowing > >> more little files ? But not files bigger than 7K ? > > > > > I suspect this ia a result of how UFS is designed. Did you use the > > standard options for block and fragment size? How about inodes? > > > > Been a while since I looked into filesystem specs but as I recall - > > My guess is free block fragmentation - I believe on UFS each file is > kept in a continuous strip of blocks on disk. This is absolutely false statements. UFS does not require any continuosity in the blocks for file. It does make some measures to reduce fragmentation, in particular, so that single op could read or write MAXPHYS bytes of data in one io, but there is nothing which would prevent it from working on not adjacent blocks. > If blocks are 8K and the > system is unable to find more than one free block between existing files > it would prevent a new file over 8k being created, even though there may > be MB of free blocks available throughout the filesystem. At a certain > fill factor moving files to create enough free space becomes too costly. > > There is also fragmentation, I understand that multiple (or just two) > small files can be stored in one block, so a 3k file can be added to a > block that already has a 3k file on it, but it may be unable to find > space to create a new 12k file. dumpfs(8) allows to look at the UFS allocation bitmaps tracking free clusters and inodes in relatively human-friendly form.