Slashdot Log In
Reiser On ReiserFS's Future And More
Posted by
timothy
on Wed May 23, 2001 08:58 AM
from the salut dept.
from the salut dept.
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.
This discussion has been archived.
No new comments can be posted.
Reiser On ReiserFS's Future And More
|
Log In/Create an Account
| Top
| 123 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Mmmm... CPU cycles (Score:5)
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. (Score:3)
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... (Score:5)
Re:encrypted, compressed, journaling.... (Score:4)
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 (Score:3)
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 (Score:3)
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? (Score:3)
"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 (Score:3)
Hans Reiser is also going to speak [linuxtag.org] at LinuxTag 2001 [linuxtag.de] in Stuttgart, Germany. From the LinuxTag website:
Is it even legal for DARPA to fund GPLed code? (Score:3)
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? (Score:4)
Get ready for the RDF? (Score:3)
What, make them run 55% faster on a Mac than on an equivalent PIII?
Re:DARPA (Score:3)
Re:Mmmm... CPU cycles (Score:3)
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? (Score:4)
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 (Score:4)
Re:great news, xfs (Score:5)
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? (Score:3)
I won't be rushing again to stick ReiserFS on an NFS system any time soon....
RTWP (Score:3)
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? (Score:5)
- "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 (Score:4)
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 (Score:3)
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... (Score:3)
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?? (Score:3)
- 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? (Score:3)
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 (Score:4)
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.
--