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

Konstantin Belousov kostikbel at gmail.com
Mon Dec 26 09:11:28 UTC 2016


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" <jhs at berklix.com> 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.


More information about the freebsd-fs mailing list