Reiser On ReiserFS's Future And More

Steven Haryanto writes: "This one's from Indonesia. InfoLinux did an email interview with Hans Reiser, in which he explained about the ReiserFS project plan and the new Namesys business model. Mr. Reiser told me that Namesys recently received $600K funding from DARPA to include encryption in ReiserFS v4.0." Dig this quote: "We are going to add plugins in our next major version, and we hope that plugins will do for filesystems what they did for Photoshop." Mmmm -- encrypted, compressed, journaling, extensible filesystems. Reiser also touches on issues of international software development and how programmers can achieve fame.

Mmmm... CPU cycles

Mmmm -- encrypted, compressed, journaling, extensible filesystems.

May ask for a moment of silence for the CPU? First IDE, now CPU heavy filesystems? Also, one of my first questions is, how do you compress a filesystem without having problems with either:

• Making seeks tough to calculate, or worse, requiring many disk accesses to get the right address
• Performance problems with things like writes in the middle of the file, causing the dictionary for that part of the file to overfill and the whole portion of the file to need recompression

Perhaps I'm just not up on the latest compression techniques (most likely), but those questions just popped in my head.

Either way, this is just further down the road of increasing CPU requirements just to drive the friggin disk. Ick. I miss SCSI.

--

Modular Plugins != plugin modules.

Just because something is modular in the kernel doesn't mean it can only be a module. The only case that this exists, AFAIK, is the protocol-specific masquerading modules.

Maybe against the current recommendations, anything that I don't have to load as a module (my AWE32 and Masq mods) gets compiled into the kernel. Why? Because it's not like I won't need the features - that's why I selected them for compile in the first place.

If you encrypt all of your main filesystems, then you'll just have a /boot partition with vmlinuz on it, and the encrypted filesystem mods already loaded. Load the kernel, find the encrypted root, and *Bam* there's your newly-readable filesystem. This isnt' rocket science.

Ooops...

What if you did something silly like placing your filesystem encryption module on your encrypted filesystem... Get outta that one Houdini ;)

Re:encrypted, compressed, journaling....

(Wavy flashback lines)

I remember when the Linux kernel introduced modules and in the race to out-module one another, a lot of newbies rebuilt their kernels with every single filesystem as a module. Ahh, those were the days...

Re:great news, xfs

Not to start a filesystem war, but my experience with XFS on linux has been very positive. The install .iso is *polished*. The fs tools are plentiful and high quality. Performance is excellent. If XFS on MIPS is any guide, reliability is top notch too.

I'm glad to see ReiserFS aggressively pushing the technology envelope, but I have nothing but good things to say about XFS, and would recommend it to anyone using a recent kernel who wants a robust journaling filesystem.

As others have said I think there is room for both filesystems going forward.

DARPA

$600K funding from DARPA to include encryption

Nice to see that DARPA [darpa.mil] (the Defense Advanced Research Projects Agency) is still funding useful things like this. Remember that they funded the internet when it first started. They're usually up to something interesting.

SQL crippling?

Hans said:
"SQL has been crippling the database industry for decades"

I'll admit it's not the best syntax to manipulate
a database but before SQL there was no uniformity
in database access. At least you don't have to
learn a new "language" for each database you
maintain/access. I don't see how it's crippling.

I am curious about any solution he would propose.

LinuxTag

Hans Reiser is also going to speak [linuxtag.org] at LinuxTag 2001 [linuxtag.de] in Stuttgart, Germany. From the LinuxTag website:

What new features are planned for V4? Dancing trees to replace balanced trees, plugins, item handlers, ACLs, extents, a repacker, and more. Hans Reiser will discuss these plans with the audience, and get user feedback on them.

Is it even legal for DARPA to fund GPLed code?

As I recall, Federal law states that work created by or for the US government is not covered by copyright. Therefore, the code would not be able to be GPLed, because the GPL requires a copyright!

GPLing the code is also bad policy because people should be able to use technology that's developed with their tax dollars for any purpose. The GPL prevents enterprising programmers from using the code in their own products and making money from those products. It therefore seems to me that DARPA should either NOT fund such a project or insist that the code that is generated be placed in the public domain -- or at least licensed under the BSD License or the MIT license. After all, it's our tax dollars.... None of us should be denied the use of the code.

--Brett Glass

Plugins do the same as for photoshop?

While the plugins for Photoshop are great and very powerful, there is one problem. How many plugins have you seen that fail (crash or fail to complete the operation) when you try them on a large image? I think it will be very hard for enough high quality, stable, trustworthy plugins to be available. I'm sure compression, encryption, and a few other basics will be great. But will they do the same as for Photoshop? I doubt it. No one wants to take a risk of widespread data corruption or data loss.

Get ready for the RDF?

Quote: "we hope that plugins will do for filesystems what they did for Photoshop."

What, make them run 55% faster on a Mac than on an equivalent PIII?

Re:DARPA

Welcome to DARPA, where Research is our middle name.

Re:Mmmm... CPU cycles

A few more thoughts:

CPUs cycles are getting cheaper than I/O and memory bandwidth, but this kind of thing makes it hard to do DMA.

Random access to files is not particularly helped by using the "latest compression techniques", it's more a matter of how you design the filesystem.

You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.

Most files are not accessed randomly, and of those that are, most of the file is eventually accessed even if it is done non-sequentially.

Most random accesses occur on pagesize boundaries. Even if you are accessing one single byte in the middle of the page, modern VM-integrated buffer caches will fetch the whole page to do it. So what you need is not the ability to seek to any random point in the middle of the file, but just to any page boundary. Much simpler. You can store tables of these things.

If you write to the middle of the file and blow the compressibility of the data, then you punch out the page and relocate it on the disk. Sequential contiguity suffers, but heck, you weren't accessing this file sequentially anyway, so why are you complaining?

Has the world gone totally mad?

For almost ten years I worked on networked filesystems, and the US government prevented us from adding any kind of "hooks" on the basis that they might be used by furriners to add prohibited crypto.

Now the US Defense Department is paying a bunch of Russians (oh, the irony, the irony) to do exactly this!

And the Bush administrations is paying Osama bin Laden 40 mil for his valiant efforts on behalf of the War on (some) Drugs?

What's next? An invitation for Fidel Castro to spend the night at the White House and drop E with President Junior? Saturday Night Live quits doing White House satires because "we just can't keep up"?

You got the url wrong

It's www.reiserfs.com [reiserfs.com]

Re:great news, xfs

They way I see it is that Reiser is looking to make a mark with having the latest & greatest feature list, XFS is looking to have the the most stable & reliable filesystem, and ext3 is a way to have people keep their existing ext2 data and add journaling support.

Reiser is planning on selling their modules in the future, make a new feature to be sold and change the previously sold module to be free. Their entire business model depends on them having newer and newer features, which is great for people who are wanting/needing feature over stability.

XFS is leaning more towards the datacenter type of situation, it may not have the latest and greatest, but it will work reliably, constantly, and with great performance. XFS is looking towards Linux as their OS platform, they have to give the same quality of filesystem they had on Irix to their customers who demand that quality. (when buying a multi-million dollar 512proc numa system they tend to require lots of stability).

On the competeing filesystems, Steve Lord from the XFS mailing list said it probably best:

"...I have never regarded the different filesystem on Linux as being in direct competition with each other, there will always be benefits to using each different filesystem for their strong points. Plus having several filesystems under active development means that there will be a tendency for the developers to make theirs the best, the implementations improve, and everyone wins."

Reiser will be used for the things it's good at (squid, mail spool, new features) and XFS will be used for the things it's good at (larger files, NFS server, stability). They compete only that they are filesystems, but what they are designed to be good at are two different things.

NFS plugin?

Hopefully Hans will also provide an NFS plugin too...relatively recent versions of ReiserFS cause large-scale crapping out of your NFS server when you try and export ReiserFS volumes.

I won't be rushing again to stick ReiserFS on an NFS system any time soon....

RTWP

Actually he feels that it's relational databases that are crippling. In his whitepaper [reiserfs.com] advocating a unified namespace, he proposes a hierarchical model that fits to data rather than fitting the data to the model.

Photoshop plugins?

Looking forward to these filesystem plugins:

• "Random noise" - randomly copy from /dev/urandom instead of writing the actual file
• "Motion blur" - bit rot on very fast disks
• "JPEG compression" - lossy compression for your data!
• "Mosaic" - increase fragmentation
• "Colorize" - rot13 all .so files
• "Watermark" - digitally sign all files (also system files)

How about just making a toolkit for porting Gimp plugins?

Fame

Reiser also touches on issues of international software development and how programmers can achieve fame.

That should be pretty easy - create a kick-ass piece of software that everybody uses & name it after yourself (like he did :).

Re:Mmmm... CPU cycles

Microsoft solved these problems by splitting all compressed files into 64k chunks -- the compression is done, one 64k chunk at a time. When a file is read, it is decompressed. If only part of a file is written back to disk, a chunk is compressed. If it is too large to fit in the space previously occupied, it just finds a space on the volume large enough (estimated) to hold the rest of the file, and stores that chunk there. If one chunk must be relocated, it starts relocating all the rest of the chunks (two file fragments are better than 10.)

Novell takes the scheduled approach -- files are always written uncompressed. Later, at a specified time, the system looks for "compressable" files and compresses them. In this way, only decompression is performed on the fly.
-------
-- russ

"You want people to think logically? ACK! Turn in your UID, you traitor!"

First things first...

Before going into implementing new features, I'd prefer if they made ReiserFS rock solid first.

At the moment, and after hearing recent scary stories about problems with ReiserFS (but I personnally haven't ever had any big trouble), I switched to XFS and enjoy it just as much.

I also find SGI much more quick at getting things stable and finished, which is fairly important IMHO.

Matthias

Re:stability??

Given that it's only as stable as the weaker of
- ReiserFS itself
- The provider of the plug-in.
and that ReiserFS itself is stable, you do have to be careful with your choice of plug-in.

If you care about your files be as careful about your plug-ins as you are about the manufacturer of your brake-disks, or your gas oven, say.

No-one will _force_ you to use any particular plug-in, you simply have to look for advocacy stories, and make sure you're not on the bleeding edge.

THL.
--

Re:Photoshop plugins?

Hot-diggetty man, I need mod points _now_!

You forgot
* Invert - learn to read documents backwards...
* Fade - You didn't need _all_ of the data did you?
* Rotate - Put data on the next sector to the one the FS headers say it's on.
* Merge - Great if you're short of space.

THL.
--

Re:Mmmm... CPU cycles

Very good post. You ask all the right questions.

Compressed FSs have always had this problem. The best solution that people have comeup with is one that we have already implemented - caches.

In particular, the hairy writing to disk stage (where the compressions and on-the-fly construction of dictionary etc. takes place) only needs to be done on file closure.

For some files, such as those that are frequently opened for writing, it's perfectly possible to have backgrounded compression. Basically you don't compress the file until a later point in time, you store it uncompressed on the hard disk and mark it as such. It's a seperate house-keeping job to actually compress the files (when they are 'stable' for some heuristically defined stability function (e.g. closed >10 seconds ago, or yesterday, or whatever))

Another helpful technique is to chunk the files, so that you only ever have to seek from the nearest chunk boundary. This simply shrinks the amount of data that suffers from the seek problem, and often (though _not_ always) reduces the compression ratio. (e.g. a large executable could possibly be made smaller, as the code and initialised data could end up in different chunks, and the compression model could only need to adapt to one type of data.)

Note, however, that we are not talking about _a_ compression plug-in. We are talking about compression _plug-ins_ (i.e. plural). You can chose your plug-in depending on the requirements.
e.g. A FS for infrequent writes and frequent whole-file reads, such as a document management server, and could use a 'slow' compression, fast decompression, no-seek algorithm.

From purely personal opinion, I believe with current HD transfer rates giving the CPU the decompression task is a better than reading bigger files. However, I'd not swear to that until I've played around with it and tested it thoroughly, with all my favourite file types. (I tend to have 500MB highly-compressible log files from what I do, so this really pushed my buttons!)

I do go on sometimes...
THL.
--