2009/7/7 Marat N.Afanasyev <[email protected]>: > Kostik Belousov wrote: >> >> On Tue, Jul 07, 2009 at 12:15:46AM +0400, Marat N.Afanasyev wrote: >>> >>> Kostik Belousov wrote: >>>> >>>> On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: >>>>> >>>>> i have a huge amount of small files on the source systems, as you can >>>>> see they have about 20 million files and almost each of them is jpeg or >>>>> gif. >>>>> afaik, there are no sparse files at all. >>>>> >>>>> i still cannot figure out what is it: a free space leak in ufs2+su or >>>>> bug in statfs(3), that is used in df, or something else. >>>> >>>> My guess that it is due to fragmentation. >>>> As an experiment, try to create 1-byte file. Does it work on the >>>> filesystem >>>> in described state ? >>> >>> I can create small files, as many as i have patience, maximum size of >>> such "small file" is 14336, so. it seems that if file is no greater than >>> (block_size-2048) it can be created. larger file cannot be created. >>> >>> imho, fragmentation on filesystem should be very low, there were no >>> deletions on it, just creations. >> >> The fragmentation on UFS usually means using fragments for the file tails, >> not having file sequential blocks allocated in the non-sequential disk >> blocks. >> >> You experiment confirms my hypothesis. > > i cannot create a slightly larger > file joining two unallocated parts of different blocks even if no fully free > block exists? ;)
You can't. As far as I remember, ffs_alloc() tries to populate a number of whole blocks and then only packs a remain data tail into a partially allocated block (one, two, .. seven fragments), thus creating a block fragmentation. In other words, it's impossible to partially allocate several blocks for a one file. Can you show your dumpfs output (superblock part)? -- wbr, pluknet _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
