Slashdot Mirror
Journaling Flash File System
menthos writes: "It seems like Axis Communications has brought a YAJFS (Yet Another Journaling File System) to Linux. It is however a bit different, in that it is designed for flash memory filesystems, as in Axis's own Web cams. It is GPL, and the JFFS link is here. Maybe this could mean more Linux PDAs?"
Because flash memory is not standard memory. In particular it has slower access times and does not like to be written to often that much. This makes using caches necessary for good performance (especially on 200+ Mhz handhelds).
But if you use caches, there's always the question of what happens in the case of a power outage (as in, the battery just popped off). Journaling allows to go back quickly to a reasonable state 99.9% of the time (at least). To the point that the user will probably not notice the problem.
Incidentally, a jfs does _not_ protect against disk crashes at all, it is not designed for that. If you want protection against (most) disk crashes, what you need is RAID.
Actually, if you want very reasonable data security without daily backups, especially given the current cost of large disks and comparable-size backup systems, you probably need a jfs+raid combination.
OG.
It's not very RISCy. It looks more like a almost-68000 with delay slot branches (if I remember right). It has a bunch of indirect addressing modes not found on most (or any) RISCs. Of corse it doens't have to be a RISC. It runs pretty quick (50Mhz? 100Mhz?), as you say it has lots of good I/O features and built-in networking.
It is a pretty cool CPU for the right target. But it ain't a RISC.
People who want to know more about a cool embeded CPU with lots of networking and I/O features should definitly checkout their little CISC CPU.
Anyone that thinks it is a RISC chould check out page 17 of the ETRAX 100 Data Sheet, and then maybe the John Mashey "What Is RISC" essay. Enjoy.
Flash memory has a very finite lifespan. You can only get a limited number of read/writes out of a flash chip (something ~ 1 billion IIRC) before it goes kablooey. Thus preventing read/write intensive operations is of the utmost importance. This, obviously, precludes letting fsck thrash your flash chip up.
--
I think there is a world market for maybe five personal web logs.
At University, I am working on a protocol extension to Jini to bring Jini to non-Java capable devices, e.g. embedded CPUs. Back when I began, we thought that we should find a cool hardware device to try the new protocol on. The Axis camera is a great product (I knew from several job-related projects) and it is hands-down the coolest device out there that combines an embedded microcontroller, an ethernet connector and a restricted hardware environment. Perfect to demonstrate my project of native Jini support without the need for a Java Virtual Machine.
October last year, long before I actually started working on my thesis, I requested developer information from Axis about their network camera. It took me four requests to get any response from them in the first place. Finally, after writing a polite complaint to Axis HQ Sweden, I got to an overly enthusiastic marketing drone from Axis Germany.
He told me that my project is a great thing, that Axis was very interested in it and that he would do everything he could do to help me.
He just noted that the formerly close-source firmware of the Axis camera will be changed to a port of the Linux kernel very soon and that I should wait for the new Linux version, due out in November.
"Isn't that great?" he told me "you don't even have to sign an NDA, we will provide you with the complete source of the firmware and one or two free demo units. All you have to do to get the demo units is sign a research agreement with us." I have an email from him lying around somewhere where he confirms this offer.
Oh, you can imagine how happy I was. Just a few weeks to get a demo unit with full firmware source and it's a cool product, too!
Well, weeks passed. Months passed. My contact person was always happy, bright and optimistic when I called him and asked about the progress of the product. No matter when I called him, the camera was due to be released "in two or three weeks" and "yes, you will get your demo unit with firmware source from us."
Strange that one time he asked me specifically not to contact the firmware developers at Axis Sweden before the release of the camera, since is "going to cause problems" for him...
Well, the camera was finally released in late Februar for CeBIT. There, I met an actual developer from Axis Sweden. He had never heard of my continuous requests.
"Interesting. It would have been nice to know this a few months back so that we could have looked into this project during our development." Yeah, but I told Axis about it four months ago.
The bottom line: There will be no freely available firmware source of the camera until "the end of the year". The developers' superiour has no interest in my thesis project, so that even with an NDA I will not be allowed to modify the camera's firmware now. (I could wait another year, but hey, one day I do want to finish University...)
I would have been nice to know this four months ago. Of course, because of the continouing promises and full confirmations by Axis Germany, I did not look into alternative hardware.
Anyway, if you're interested, see http://developer.jini.org:80/exc hange/users/hanno/ for more information about my protocol extension. You'll need a Jini developer account.
------------------
------------------
You may like my a cappella music
Absolutely, but you're forgetting what it is in power outages that causes disk crashes.
:) But anyway, this isn't a fail safe method, you just have to be a much better shot with the power button.
;)
Filesystems (and ext2fs in particular) keep a certain amount of the state of the 'disk' in memory, leaving the actual physical disk in an incomplete state. If you see what I mean.
The simple solution is to use synchronous writes - the api call doesn't return until the state has been written on disk. This, incidentally, is the default for mount under FreeBSD - you can make FreeBSD a whole lot faster writing to disk by mounting async, but it would be less safe so you have to enable it manually
A jfs means that even if you trip the power half way through the write, the whole thing can be rolled back to a pre-written state, a la database transactions.
A quick aside is the softupdates package under FreeBSD which does something similar to a jfs. Unfortunately I've not got further than the limited licence for this so I cannot comment further.
So, why does this matter for flash? Because flash is embedded. It cannot be allowed to go wrong. Do you really want a fsck button on your digital camera? Oh - OK, errrmm, Aircraft? Exactly.
Corrections by email please
Dave
I write a blog now, you should be afraid.
Flash has a limited write lifespan. Journalling requires writing to the journal before every modification to the fs. Flash being very slow for writes makes this a major performance hit.
.
fsck doesn't need to make very many writes at all when fixing an insane drive. Recovery requires lots of reads, but the flash reads are fast and the drive is very small. This performance hit is nothing compared to doubling the already slow flash writes.
.
There are filesystems that do not leave the fs in an insane state by making only one modification at a time, and do not have this kind of overhead for regular use. The only case where the journal would give stability with better performance is deleting massive directory trees...
-- http://thegirlorthecar.com funny dating game for guys
I design Telecomms stuff - much of it embedded. We've just been asked to design a box which takes serial data from PBXs, collates it, caches it and makes it them available over a network. JFFS is one very key part of that - and this announcement could not have come at a better time for me.
Axis have an excellent business model on all of this. They've designed their own custom RISC processor with built-in network support and quite a lot of very neat I/O ( A dream come true for telecomms embedded people). They're offering Linux as the OS and it seems they've taken a long, hard look at Linux and what it might lack for people using their chip. They spotted a gap - so they created the JFFS and released back to the developer community which gave them Linux in the first place.
It seems to me to be a perfect example of how Open source should work and how it can work for everyone's benefit - and how open source can be part of a very rational business stratgey.
So I hope to be an Axis customer very soon.
People who want to know more about the RISC chip should look at :
http://developer.axis.com/about/
AJB
It's cool, I just don't know what it's for!
=P
Free music from Jack Merlot.