pon., 22 kwi 2019 o 07:17 Fernando Cassia <fcassia_AT_gmail.com> napisał(a):
>
> On 4/19/19, Daniel Cegiełka <daniel.cegielka_AT_gmail.com> wrote:
>
> > Would anyone be interested to start supporting JFS? I'm thinking about
> > rewriting jfsutils.
> >
> > Best regards,
> > Daniel
>
> +1 on all your points.
>
> I ran JFS on a dual-Pentium III SMP system for nearly five years. With
> excellent performance.
>
> Ten years ago I wrote to the IBMers in charge of the code, Dave
> Kleikamp at IBM's Linux center in Austin was a joy to talk to.
>
> Several years later I tried contacting him again but his email
> bounced. He's now one of the several Linux kernel devs _AT_ Oracle.
It's not that bad, 'shaggy' is alive and he's still support JFS :)
https://github.com/kleikamp/linux-shaggy/tree/jfs-next/fs/jfs
As you can see in the logs, he is quite active :)
What I think should be done
-------------------------------------
Kernel
* fallocate
https://github.com/kleikamp/linux-shaggy/blob/master/fs/jfs/file.c#L151
* DAX support
https://github.com/kleikamp/linux-shaggy/blob/master/Documentation/filesystems/dax.txt
* 64 bit time type issue:
https://github.com/kleikamp/linux-shaggy/blob/master/fs/jfs/jfs_types.h#L45
* struct statx?
Userland
I want to write tools to handle JFS from scratch. When jfsutils was
created, there were no uniform standards - one library had something,
the other didn't. Today, jfsutils can be written in a much cleaner and
lighter way. I would like to create a multibinary that would contain
basic tools for JFS (such as kmod). The whole would be statically
linked, which is important for system tools. However, it would be
possible to compile to the library and then such a library can be
used, for example, in python or lua. This would give the opportunity
to create an interactive debugger for JFS and to build additional
tools, such as data recovery.
Daniel
> FC
>
Received on Mon Apr 22 2019 - 15:43:55 CEST