Messages in this thread | | | Date | Sat, 3 May 2008 14:00:05 +0200 | From | Jörn Engel <> | Subject | Re: LogFS merge |
| |
On Sat, 3 May 2008 11:29:43 +0200, matthieu castet wrote: > > Shouldn't this get review by mtd guys first ?
They were on Cc: on most of the review rounds.
> 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
-- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |