FAQ

1. License
   1. Q: What is the license for LogFS?
2. Code maturity
   1. Q: I want to use LogFS on my X
   2. Q: When will LogFS be ready?
3. Device support
   1. Q: Does FogFS work on both NAND and NOR?
4. Usage
   1. Q: I created a filesystem with "mklogfs -q ..." and mount it. I get an immediate oops.
5. Inode file
   1. Q: In LogFS, inode numbers are allocated by super->s_last_ino++; Won't the inode file occupy a huge amount of space over time?
6. Misc
   1. Q: Where are the userland tools for working with LogFS? mkfs, fsck, ...?

License

Q: What is the license for LogFS?

A: GPL version 2. Both for the kernel patch and the userland tools.

Code maturity

Q: I want to use LogFS on my X

A: LogFS is not ready yet. If you want to take a look and play around with it, please do. Just don't put any data you care about on it - you may lose it and cry heavily.

Q: When will LogFS be ready?

A: Mid 2007. Well, that was the answer in early 2007, so go figure. As of March 2008 the code is pretty stable. Pushing for mainline inclusion can start when all (known) bugs are gone, which is likely a matter of weeks.

Device support

Q: Does FogFS work on both NAND and NOR?

A: Yes, it does. It works on block devices (USB stick, hard disk, etc.) as well.

Usage

Q: I created a filesystem with "mklogfs -q ..." and mount it. I get an immediate oops.

A: mklogfs has to erase the complete device at filesystem creation time. The only reason to avoid doing so is when a filesystem has just been create on the same device before and it is known to be erased. In other words, when giving a demonstation and not wanting to wait for a long time. The option should either get removed or come with a large warning.

Inode file

Q: In LogFS, inode numbers are allocated by super->s_last_ino++; Won't the inode file occupy a huge amount of space over time?

A: The same problem exists for directories as well and was solved there. In principle the same solution would work for inodes as well, with one extra detail to worry about. Deleted inodes in LogFS are removed completely. Not even the generation number remains stored on the medium. Therefore, when reusing low inode numbers, nfs may see the same (ino, generation) tupel again and falsely believe the new inode to be identical to the old one.
To solve this LogFS should store a global generation number. And to prevent overflows from happening too quickly, several inode numbers should get used before incrementing the global generation number and restarting from the beginning.

Misc

Q: Where are the userland tools for working with LogFS? mkfs, fsck, ...?

A: mklogfs is here as a binary for i386 or here in source.
fsck does not exist yet. There is a kernel config option for debugging purposes, but the code is waiting for a userspace port.