linux-kernel - Re: swap file over jffs2 partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Feb 2008 09:43:45 +0100
From:	Jörn Engel <joern@...fs.org>
To:	Dimitrios Apostolou <jimis@....net>
Cc:	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: swap file over jffs2 partition

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.

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.

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!

Jörn

-- 
Joern's library part 5:
http://www.faqs.org/faqs/compression-faq/part2/section-9.html
--
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/