[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47C84111.6030103@gmx.net>
Date: Fri, 29 Feb 2008 19:29:53 +0200
From: Dimitrios Apostolou <jimis@....net>
To: Jörn Engel <joern@...fs.org>
CC: linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: swap file over jffs2 partition
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists