All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitrios Apostolou <jimis@gmx.net>
To: "Jörn Engel" <joern@logfs.org>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: swap file over jffs2 partition
Date: Fri, 29 Feb 2008 19:29:53 +0200	[thread overview]
Message-ID: <47C84111.6030103@gmx.net> (raw)
In-Reply-To: <20080229084345.GA16507@lazybastard.org>

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:

http://en.wikipedia.org/wiki/JFFS2

> 
> 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:

http://dev.laptop.org/ticket/6469

> 
> 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,
Dimitris

WARNING: multiple messages have this Message-ID (diff)
From: Dimitrios Apostolou <jimis@gmx.net>
To: "Jörn Engel" <joern@logfs.org>
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: swap file over jffs2 partition
Date: Fri, 29 Feb 2008 19:29:53 +0200	[thread overview]
Message-ID: <47C84111.6030103@gmx.net> (raw)
In-Reply-To: <20080229084345.GA16507@lazybastard.org>

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:

http://en.wikipedia.org/wiki/JFFS2

> 
> 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:

http://dev.laptop.org/ticket/6469

> 
> 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,
Dimitris

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

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  2:50 swap file over jffs2 partition Dimitrios Apostolou
2008-02-29  8:43 ` Jörn Engel
2008-02-29  8:43   ` Jörn Engel
2008-02-29 17:29   ` Dimitrios Apostolou [this message]
2008-02-29 17:29     ` Dimitrios Apostolou
2008-02-29 19:57     ` Jörn Engel
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=47C84111.6030103@gmx.net \
    --to=jimis@gmx.net \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.