Re: [dev] JFS filesystem

From: Daniel Cegiełka <daniel.cegielka_AT_gmail.com>
Date: Sun, 21 Apr 2019 22:39:50 +0200

niedz., 21 kwi 2019 o 22:07 Ciprian Dorin Craciun
<ciprian.craciun_AT_gmail.com> napisał(a):
>
> On Sat, Apr 20, 2019 at 1:29 AM Daniel Cegiełka
> <daniel.cegielka_AT_gmail.com> wrote:
> > * JFS [1]
> > Forgotten file system. JFS is what ext4 should be. This is a very well
> > thought and well-designed file system. It is very light and has a tiny
> > resource consumption. The first journaling file system plus unicode
> > support. Here is a small comparison of the kernel modules (size):
>
>
> I used to have JFS as my default filesystem for Linux until a few
> years ago when I switched to Ext4. It was indeed a fast file-system,
> especially for large number of files, however I think it suffers from
> lack of attention from developers.

This is a problem that I would like to limit. If I rewrote jfsutils
and added some missing functionality in kernel (fallocate), then maybe
more people would be interested in JFS. It would be nice to perform
some fuzzing tests and in this way to catch potential problems.

https://github.com/oracle/kernel-fuzzing

> Moreover it happened to me once during an online-resize that the
> kernel issued an error and remounted my partition read-only. Luckly
> nothing was lost, however it wasn't a pleasent experience.
>
> As some others on this list have mentioned, JFS and power failure
> don't mix well and usually it loses your file (i.e. truncates it);
> however I bet the issue here is not the actual file-system but the
> applications that don't `fsync` a file before `close` and just assume
> that `write` + `close` implies persistance. (As this happened to me
> also on Ext4.)

An interesting solution is to keep JFS metadata on a fast separate
ssd. Then on the main disk you have only data structures that can be
recovered more easily.

JSF has its drawbacks, but it seems to me that it is a quite flexible
filesystem and incredibly light.

Daniel

> Ciprian.
>
Received on Sun Apr 21 2019 - 22:39:50 CEST

This archive was generated by hypermail 2.3.0 : Sun Apr 21 2019 - 23:12:08 CEST