Guaranteed writable space on JFFS2?
Artem B. Bityuckiy
dedekind at infradead.org
Fri Jan 21 04:39:59 EST 2005
On Thu, 20 Jan 2005, Thomas Weber wrote:
> I've a problem with JFFS2 (kernel 2.4.26) on a NOR flash with 128k blocks.
> Due to previous unexpected behaviour, I've already changed
> > super.c at 85:
> > - avail = c->dirty_size + c->free_size;
> > + avail = (c->dirty_size / c->sector_size) * c->sector_size + c->free_size;
> as GC returns ENOSPC on dirty size < sector size. This occurs quite
> often on a nearly full fs with 128k blocks.
> By now, e.g. df provides the physical free space, but I do not know how
> much of this space is really writable, since I do not know how much is
> necessary file system organisation, inodes, etc.
> Is there a way to predict the maximum file size, which will still be
It is hard:
1. We do not exactly know how many nodes will be stored to flash. This
depends how will you write your file.
2. GC works, it merges modes and sometimes splits them. So the free space
is f(t) (function of time).
3. Depending on how block is filled we have different amount of unused
space at the end of block. This space is too small to store any node. But
after GC process this block, this space may be reclaimed, but there is no
4. On NAND situation is even worth, because linux periodically syncs wbuf
(JFFS2 is designed such way), so we flush it when it is partially filled,
using padding nodes.
So, possibly we may evaluate the lowest border of free space, but can not
calculate the exact value.
> Thanks for your suggestions,
> Linux MTD discussion mailing list
Artem B. Bityuckiy,
More information about the linux-mtd