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-next>] [day] [month] [year] [list]
Message-ID: <47F1EC20.6050600@wpkg.org>
Date:	Tue, 01 Apr 2008 10:02:40 +0200
From:	Tomasz Chmielewski <mangoo@...g.org>
To:	LKML <linux-kernel@...r.kernel.org>, penberg@...helsinki.fi,
	Jörn Engel <joern@...fs.org>,
	ext-adrian.hunter@...ia.com, jwboyer@...il.com,
	"Artem B. Bityutskiy" <dedekind@...dex.ru>
Subject: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

Artem Bityutskiy wrote:

> I've renamed the thread because I do not like this flamish discussion
> to me mixed with the technical one.
> 
> Jörn Engel wrote:
>> Shiny numbers!  Performance has improved significantly in the last six
>> month.  Still worth a closer look.
> We'll re-run them. Does logfs support write-back? Does it support compression?

For me, the motivators to wait for LogFS are mainly the facts that it
can work on traditional block devices, and not only on pure flash:

1. It works on normal block devices and it supports transparent compression

Today, a 64 GB SSD/flash-based media costs ~about the same as a 1 TB
hard disk. This makes flash very expensive to use; compression can
compensate that cost a bit (will depend on the usage, of course).

I believe there is no other Linux filesystem which can do transparent
compression on block devices.


2. It does wear-levelling also on normal block devices

Although it doesn't sound normal to do wear-levelling twice (most
flash-based block devices do wear-levelling on their own), I had a flash
corruption after just ~one month of using RAID bitmap on a IDE-flash
disk formatted with ext3. Apparently, device-level wear-levelling wasn't
spreading updates of RAID bitmap file well enough.

(...)

> This basically means it is unfinished. Handling dynamic bad blocks is a *must*
> if you are going to work on NAND, especially on MLC NAND which are not as
> reliable as SLC.
> I think you should bluntly say about this when you submit patches to prevent
> people from starting using it in production.

I too wouldn't use LogFS today in a production environment - it is still 
not feature complete and not widely tested.
I wouldn't use btrfs or ext4 today for the very same reason.


-- 
Tomasz Chmielewski
http://wpkg.org


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ