Hi All,
We've hit what appears to be an idiosyncrasy with older jffs2 where
a large
reclaim backlog is not garbage collected during runtime, presumably due to
outstanding free block total being substantially above gc_trigger. In this
scenario reclaim does not kick in during runtime, however upon a reboot
after
a partition is mounted and modified, reclaim kicks in causing a stall in
boot of
several minutes on a 400Mhz ARM926EJ-S. The partition is sized at 32MB with
under 5% usage. The application is heavily modifying a single small file.
Search of list archives for a similar issue and examination of history
from where
this was observed in kernel version 3.16.7 (fs/jffs2 commit 16b9057804c) to
current didn't reveal anything obviously relevant. We've subsequently
produced
a work around which forces runtime gc to trigger at a lower threshold,
eliminating
the protracted boot time reclaim. However we're interested in a
general, long-term
solution and are wondering if the description here may sound familiar to
others,
either encountering the issue or any discussion/implementation of an
approach to
address the same.
Thanks,
-john
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
