LKML Archive on
help / color / mirror / Atom feed
From: Dimitrios Apostolou <>
To: "Jörn Engel" <>
Subject: Re: swap file over jffs2 partition
Date: Fri, 29 Feb 2008 19:29:53 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Jörn Engel wrote:
> On Fri, 29 February 2008 04:50:17 +0200, Dimitrios Apostolou wrote:
>> I intend to build a diskless linux system (root over NFS). Because it
>> has 1GB of embedded flash storage, I'm thinking of using this as swap 
>> (I've been bitten many times by the problems linux has with *no* 
>> swap...). And to avoid wearing out the flash storage too fast, I 'm 
>> thinking to format the 1GB partition as JFFS2, and create the swapfile 
>> on top of it.
>> I'm not so experienced with JFFS and I don't know if it's too heavy for
>> the CPU, for swapping. Or if there are other issues I 'll face. What do
>> you think about it? Any other ways you 'd propose?
>> Sorry for sending this at LKML but jffs-dev mailing list seems to be 
>> off. And JFFS is the only in-kernel filesystem that does wear-leveling, 
>> right?
> Replying in reverse order...
> The relevant mailing list is linux-mtd, added to Cc:.  JFFS and JFFS2
> are two different things, JFFS is older and was removed from the kernel
> not too long ago.

Thanks and sorry for intruding LKML. It seems that even wikipedia has 
wrong address for the mailing list, see the last link of the article:

> The real fun comes not from CPU usage, but from interactions with the
> memory management subsystem.  In a nutshell, JFFS2 may require memory in
> order to write data.  When the system is under memory pressure, it needs
> JFFS2 to write out pages, which will try to allocate memory.  It is
> theoretically possible to deadlock the system in this way.

Interesting. I guess nobody has experimented with it yet so I'll try. 
Unfortunately it seems I'll face another problem, that JFFS2 doesn't 
support having a swap-file at all. Why would this happen? More info:

> On the plus side, the write path of JFFS2 is relatively simple and
> extremely low-latency.  It shouldn't be too hard to review the code and
> handle all problem cases wrt. memory allocations.
> One issue that is hard to solve is space reservation.  JFFS2 compresses
> data and allows users to write as long as there is space remaining.  It
> is possible to swap out data that compresses well, have some other
> process fill up the filesystem, then try to swap out data that
> compresses badly and get -ENOSPC in return.  As a system administrator
> you can prevent others from ever writing to JFFS2 - and you better do!

Of course! I intend to use all the 1GB of flash only for swap, the 
system will be practically diskless. And I don't think enabling 
compression for such a task would be wise.

> Jörn

Thanks for the help,

  reply	other threads:[~2008-02-29 17:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  2:50 Dimitrios Apostolou
2008-02-29  8:43 ` Jörn Engel
2008-02-29 17:29   ` Dimitrios Apostolou [this message]
2008-02-29 19:57     ` Jörn Engel
2008-02-29  9:19 ` Bernd Petrovitsch
2008-02-29 18:13   ` Dimitrios Apostolou
2008-03-02 11:55     ` Bernd Petrovitsch
2008-03-02 13:57       ` David Newall
2008-03-03 14:19         ` Bernd Petrovitsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: swap file over jffs2 partition' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).