LogFS merge
Hi,
Quoted 7 lines · Jörn Engel
not being familiar with either maintaining my own git tree or the -next process, I'd still like to get logfs into mainline. It has gone through six rounds of reviews and the last has been mostly about crossing some i's here and dotting some t's there.
So should it simmer in -next and -mm for another month? Should it go straight into -linus?
Shouldn't this get review by mtd guys first ?
Also for info, there have been some issue raised by the ubifs developer [1].
Matthieu
[1] http://thread.gmane.org/gmane.linux.kernel/658740/focus=660392
Quoted 2 lines · matthieu castet
Shouldn't this get review by mtd guys first ?
They were on Cc: on most of the review rounds.
Quoted 1 line
Also for info, there have been some issue raised by the ubifs developer [1].
I am aware of them. When ignoring FUD and personal things (Artem and I have a history), it should come down to roughly this:
1.
Ubifs takes the easy approach and uses ubi for wear leveling, bad block handling, ets. Saves a ton of work, gives quick results and is limited by ubi scan time, which is O(n).
Logfs ignores ubi and does wear leveling, bad block handling, etc. itself. Bad block handling in particular is not too robust yet. If you expect blocks to rot away after mkfs time, logfs is a bad choice.
2.
Logfs still scans the medium. It currently does not store free space maps and has to search for free space the hard way. I still have a patch to keep the map in-memory, which will avoid any rescans. But the real deal is to store it in a file with some additional tricks to make things work in a log-structured fashion. Not done yet.
Ubifs has a seperate region to store its free space map, which has its own GC. Wear leveling is dealt with through ubi. Again, ubi makes life easier.
3. Code size.
4. Mount time. I don't see any numbers I could quote, but I believe ubifs is somewhere close to a second. Does anyone know? Logfs is in the 10-60ms range.
5.
Ubifs has write-back caching for file data. Their benchmarks blow jffs2 or logfs out of the water, which isn't surprising when comparing DRAM to flash.
Logfs has write-back caching for metadata (indirect blocks, etc.) but immediatly writes normal data. Some embedded folks actually prefer this approach, as it is more deterministic. For most uses it simply throws away some performance. Extending caching to normal data isn't too hard and fairly high on my list.
6.
"Logfs isn't finished yet."
My usual answer to that is that Linux isn't finished yet either. We're still improving performance, adding hardware support and fixing bugs some 15 years after people started using it. The question is not whether there are improvements left, but whether it is good enough already.
Jörn
Signature · 4 lines
I've never met a human being who would want to read 17,000 pages of documentation, and if there was, I'd kill him to get him out of the gene pool. -- Joseph Costello
Quoted 4 lines · Jörn Engel
1.
Ubifs takes the easy approach and uses ubi for wear leveling, bad block handling, ets. Saves a ton of work, gives quick results and is limited by ubi scan time, which is O(n).
Which is easy enough to fix.
Quoted 3 lines
Logfs ignores ubi and does wear leveling, bad block handling, etc. itself. Bad block handling in particular is not too robust yet. If you expect blocks to rot away after mkfs time, logfs is a bad choice.
It's a matter of fact that especially on NAND flash blocks become bad over time, i.e. after mkfs. So that's a pretty crucial feature which needs to be complete and robust before it's declared to be usable on such devices.
Thanks,
tglx
Quoted 8 lines · On Sun, 4 May 2008 18:20:23 +0200 (CEST) Thomas Gleixner <[email protected]>…
Quoted 3 lines
Logfs ignores ubi and does wear leveling, bad block handling, etc. itself. Bad block handling in particular is not too robust yet. If you expect blocks to rot away after mkfs time, logfs is a bad choice.
It's a matter of fact that especially on NAND flash blocks become bad over time, i.e. after mkfs. So that's a pretty crucial feature which needs to be complete and robust before it's declared to be usable on such devices.
I agree. LogFS seems quite impressive in its performance, however I'm wondering how much redesign and rewrite would be needed in the code to fix the bad block handling. Maybe it's not so much and I'm overly paranoid, but having at least some idea of what it would take might help. You could add it to Documentation/filesystems/LogFS.txt as a TODO.
josh