|
|
Subscribe / Log in / New account

LogFS merged into the mainline kernel

[Posted March 8, 2010 by corbet]

LWN first looked at LogFS, a new filesystem aimed at solid-state storage devices, back in 2007. It has taken a long time, but, as of 2.6.34, LogFS will be in the mainline kernel and available for use; let the benchmarking begin.
to post comments

LogFS merged into the mainline kernel

Posted Mar 9, 2010 1:55 UTC (Tue) by leemgs (guest, #24528) [Link]

Thank you for fast notice. It seems that This is good news for developers to use a scalable flash filesystem on embedded system. :)

LogFS merged into the mainline kernel

Posted Mar 9, 2010 16:58 UTC (Tue) by blitzkrieg3 (guest, #57873) [Link] (20 responses)

That article talks about getting merged in .23. Why did it take so long to merge? How is this different than other log based filesystems designed to run on flash such as NILFS2?

LogFS merged into the mainline kernel

Posted Mar 9, 2010 17:45 UTC (Tue) by joern (guest, #22392) [Link] (19 responses)

> That article talks about getting merged in .23. Why did it take so long to merge? How is this different than other log based filesystems designed to run on flash such as NILFS2?

One difference may be that NILFS had a little more corporate funding and more than one person working on it. Also I wasn't aware of Valerie's law (a filesystem takes five years) when I started. This is one of those moments when I hate her for being right.

And was NILFS2 really designed to run on flash? I was not aware of that.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 18:15 UTC (Tue) by blitzkrieg3 (guest, #57873) [Link] (18 responses)

I'm not sure it's designed specifically for SSD as LogFS was. The "A File System to Make SSDs Scream" headline just made me think that was the intention http://www.linux-mag.com/id/7345/2/ . On second look, the primary design consideration seems to be snapshotting.

As for the differences, I was mostly hoping for a comparison of architectural differences and features.

Thanks for your work and finally getting it merged :) The more SSD filesystems the better.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 18:27 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] (15 responses)

Why are you talking about SSDs?

LogFS is designed to work on real flash, directly. Flash != SSD.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 18:49 UTC (Tue) by blitzkrieg3 (guest, #57873) [Link]

Okay I see now. My mistake.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 19:36 UTC (Tue) by nix (subscriber, #2304) [Link] (12 responses)

That is to say, it's not designed to work on any hardware the majority of
us will ever see. Alas.

LogFS merged into the mainline kernel

Posted Mar 11, 2010 4:02 UTC (Thu) by pj (subscriber, #4506) [Link]

Only by choice... openwrt-compatible routers are pretty cheap.

LogFS merged into the mainline kernel

Posted Mar 11, 2010 9:06 UTC (Thu) by joern (guest, #22392) [Link] (10 responses)

Iggy Pop once explained why so many of his songs became a hit 10 years after being released. He said they didn't care so much about what the public taste was but rather what the public taste was supposed to be.

In a way I'm doing the same. The SSD you can buy at your local electronics store has a SATA interface and is hiding its flashiness behind a translation layer. It is trying to mimic a hard disk. Between your operating system and the actual medium is a fairly large number of bridge chips, translating from CPU bus to PCI or PCIe, to SATA, to some internal SSD bus and to the actual NAND interface. Each step adds latency.

The SSD you should be able to buy simply has fewer steps in between. Rip out the translation layer. Skip SATA and attach to PCIe. Skip PCIe and attach to a hypertransport socket on your mainboard. Simply move it as close to the CPU and RAM as possible.

Support for block devices came as a hind-sight, because I too have to live in the present and it is a lot harder and more expensive to create my own SSD than to change my filesystem. But that doesn't mean I have to like the current situation. Nor should you. ;)

LogFS merged into the mainline kernel

Posted Mar 11, 2010 13:21 UTC (Thu) by nix (subscriber, #2304) [Link]

Oh, I certainly don't. I'm sure the FTL in those bridge chips is bloody awful, and we can't fix it, and it's non-free and baked into hardware and pointless extra mandatory complexity purely because Windows can't handle raw flash and ew.

But still, this is a really cool project that I can't use sensibly. I hope you're right and that should be written 'can't use *yet*'!

LogFS merged into the mainline kernel

Posted Mar 11, 2010 14:49 UTC (Thu) by tack (guest, #12542) [Link] (5 responses)

What about something like Fusion-io ioDrive cards, where it's a bunch of NAND flash presented as a block device (but the proprietary driver might be doing some clever things underneath the filesystem)? Is LogFS appropriate for that?

LogFS merged into the mainline kernel

Posted Mar 11, 2010 15:08 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (4 responses)

If we can get docs on how to talk to the card, then yes. I believe that all their silly translation layer stuff to make it pretend to be spinning rust is done in software.

LogFS merged into the mainline kernel

Posted Mar 11, 2010 17:48 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

I don't know about docs, but the driver code itself is available.

I really doubt that it's all done in software. At the speeds they are working, I would expect it to be in firmware if not in a custom ASIC or PGA

LogFS merged into the mainline kernel

Posted Mar 19, 2010 11:21 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (2 responses)

"I don't know about docs, but the driver code itself is available."
For the FusionIO boards? Where?

LogFS merged into the mainline kernel

Posted Mar 19, 2010 12:42 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

through the fuision io website under support. they have a source package available to downoad

LogFS merged into the mainline kernel

Posted Mar 19, 2010 12:45 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

The only "source" packages I've found contain binary blobs and a tiny shim layer.

LogFS merged into the mainline kernel

Posted Mar 11, 2010 18:11 UTC (Thu) by linusw (subscriber, #40300) [Link] (1 responses)

Anyone can see that e.g. Netbook vendors and other convergent device manufacturers would by simple economic reasoning have motivation to cut the licensing of special ATA controllers with embedded FTLs sooner or later.

If we instead twist the question and ask: suppose we can have raw NAND access to the flash, what kind of hardware accelerators would LogFS love to see in order to do it's job properly? Is there some loop in your code that you would just love to hand over to a piece of hardware, say "here is buffer A, here is buffer B, here are parameter X,Y,Z, do the stuff (even DMA it from source to destination etc) and then IRQ me when you're done"?

LogFS merged into the mainline kernel

Posted Mar 12, 2010 14:27 UTC (Fri) by joern (guest, #22392) [Link]

DMA, IRQ and error correction, basically. Create a device with a number of chips that operate independently of each other. Allow commands to be sent and queued to a certain depth. Allow block erases, page reads and page writes. Calculate ECC in hardware with each write. Check ECC in hardware with each read. If possible do any necessary correction in hardware. Always report errors, corrected or not. Send an IRQ when operations are done.

If you have done all the above, you are in excellent shape. A few additional bells and whistles are possible, but nothing really fundamental.

LogFS merged into the mainline kernel

Posted Mar 12, 2010 16:16 UTC (Fri) by giraffedata (guest, #1954) [Link]

The SSD you should be able to buy simply has fewer steps in between. Rip out the translation layer. Skip SATA and attach to PCIe. Skip PCIe and attach to a hypertransport socket on your mainboard

So stop confusing people by referring to this as an SSD. This thing you should be able to buy is not an SSD, it's an alternative to an SSD. SSD means it emulates a disk drive. It's a very important category of storage device because you can use it with existing non-flash-aware system components. As we all know, there is a price to pay for that.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 19:52 UTC (Tue) by joern (guest, #22392) [Link]

While true, it is also designed to work on fake flash or SSD. To some extend. Problem is that flash behaviour is fairly well-known and easy to anticipate while SSD behaviour depends on a black box of software and policy that continues to grow in complexity. Optimal behaviour on one SSD can be worst-case behaviour on another.

One example is around TRIM. Lacking TRIM, one way to tell the SSD that certain blocks are unused is never to use them. So a filesystem should f.e. leave all free space at the end while reusing the front again and again. However, on another breed of SSD with less useful wear leveling, this behaviour will wear out the front, while the end never gets used at all.

But overall logfs will also work on SSD.

LogFS merged into the mainline kernel

Posted Mar 9, 2010 20:25 UTC (Tue) by joern (guest, #22392) [Link] (1 responses)

Ok, let me try as best I can. NILFS follows the old Sprite NFS approach of having a userspace daemon to control Garbage Collection (GC). Disadvantage is that after a number of writes when the device has been filled up, noone can write anymore until the userspace daemon does its thing. In LogFS GC is done entirely inside the kernel. So after you delete a large file, you can immediately reuse that space. In the NILFS case, the daemon isn't actually too bad, because snapshotting prohibits reusing the space of deleted files.

LogFS supports raw flash, which requires a number of tricks that NILFS lacks. Wear leveling, journal relocation, erase before write, that sort of thing.

Used/free space tracking on a naive LFS requires a write, which changes used/free space and would require yet another write, ad infinitum. NILFS solves this problem by pre-calculating the state after the write. LogFS solves the problem by writing the old state and and caching small updates in the journal. I believe UBIFS solves it by storing the state in a seperate UBI volume.

Surely there are more differences. I just don't know NILFS well enough to speak on its behalf. So beware of any mistakes in the above. :)

LogFS merged into the mainline kernel

Posted Mar 9, 2010 22:41 UTC (Tue) by blitzkrieg3 (guest, #57873) [Link]

Thanks for that! That's exactly what I was looking for.

Where to buy?

Posted Mar 11, 2010 14:06 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (11 responses)

Where does one buy a raw flash non-SSD device and how much does it cost?

In particular I imagine that one could make a pretty standard Linux system boot blisteringly fast if it had its /usr on a few Gb of (cheap!?) raw flash.

Where to buy?

Posted Mar 11, 2010 14:52 UTC (Thu) by gkarabin (guest, #16189) [Link] (10 responses)

This sort of thing isn't usually packaged to plug into a PC system, to my knowledge. It's a bare chip soldered down on a board, commonly used in embedded systems - things like MP3 players and cell phones. Maybe some netbook manufacturers use them already - I dunno.

In any case, you buy them through distribution channels, usually in bulk quantities. Digikey is an example of a supplier that works in lower quantities. Here's an example part:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Deta...

Where to buy?

Posted Mar 11, 2010 22:32 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (9 responses)

What I was hoping was that someone made a cheap raw flash PCIE card. If there's no such thing, there should be!

What did the LogFS developers develop on?

Where to buy?

Posted Mar 12, 2010 5:37 UTC (Fri) by Necronom (guest, #22645) [Link] (5 responses)

You'd have to write a driver, but there is Intel Turbo Memory.

Turbo Memory

Posted Mar 12, 2010 12:25 UTC (Fri) by rvfh (guest, #31018) [Link] (4 responses)

I'd love to be able to put this gig of flash to some use, rather than sitting in my PC idle...

Why did nobody get interested in using that? I would be cool to stick / on it!

Turbo Memory

Posted Mar 12, 2010 14:47 UTC (Fri) by joern (guest, #22392) [Link]

People did get interested in using Turbo Memory. But Intel has never released any documentation and noone was sufficiently motivated to reverse-engineer the windows driver. If you work for Intel and can send me the documentation or have worked it out by other means, writing an actual driver would be the easy part.

Turbo Memory

Posted Mar 12, 2010 17:49 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] (2 responses)

Just a question: if you plug it in and do a "lspci -vv", does it display a 1 Gb of memory located over the 4 Gb area? Is that a strait memory mapped FLASH or a complete subsystem with DMA, IRQ and other hardware optimisation?

lspci for Intel Turbo Memory

Posted Mar 15, 2010 15:41 UTC (Mon) by fragmede (guest, #50925) [Link] (1 responses)

2GB Intel Turbo Memory miniPCIe card

04:00.0 Memory controller [0580]: Intel Corporation Turbo Memory Controller
[8086:444e] (rev 11)
Subsystem: Intel Corporation Device [8086:444b]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f2600000 (32-bit, non-prefetchable) [size=1K]
I/O ports at 2000 [size=256]
[virtual] Expansion ROM at 80000000 [disabled] [size=64K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Capabilities: [68] Express Legacy Endpoint, MSI 01

(from http://lkml.indiana.edu/hypermail/linux/kernel/0812.0/018...)

lspci for Intel Turbo Memory

Posted Mar 16, 2010 9:36 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

Ok, thanks fragmede, it is a complete subsystem and I do not need to buy (until it is documented).

Where to buy?

Posted Mar 12, 2010 14:43 UTC (Fri) by joern (guest, #22392) [Link] (2 responses)

You are unlikely to find a cheap raw flash PCIe card anytime soon. I have no idea how bit the market for a raw flash PCIe card is, but it looks significantly smaller than the SATA SSD market. So any company about to start such a business will likely have to deal with low volume. And a low volume product is unlikely to be cheap.

That being said, if a large number of people say that they would buy a raw flash device for, say, 20% more than a SATA SSD, it might help persuade potential manufacturers. Not to mention, I am rather curious how many people share my preferences.

What did the LogFS developers develop on? Well, a large number of devices. A real kernel running on hardware, a virtualized kernel running in QEMU or KVM or a standalone port of the Linux VFS to userspace. Devices range from regular files and virtualized flash though OLPC prototypes and similar embedded boards to standard PCs with crap SSDs and hard disks. At least that covers the ones I can talk about in public. ;)

Where to buy?

Posted Mar 21, 2010 19:43 UTC (Sun) by robert_s (subscriber, #42402) [Link] (1 responses)

Crazy as this may sound, I don't think it would be incredibly hard to create such a thing.

In fact, it may even be the simplest possible 'hello world' PCIe device to design. An entry level PCIe FPGA development card and some NANDs soldered onto a prototype board would get things going. It really isn't beyond "amateur" electronic engineers' capabilities, so there must not be much interest in the idea.

It's certainly easier than creating an open graphics card.

Where to buy?

Posted Mar 24, 2010 16:14 UTC (Wed) by joern (guest, #22392) [Link]

By all means, go for it! I'd even make you a deal and write the driver if you send me a card.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds