Reiser On ReiserFS's Future And More 123
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.
Re:Plugins do the same as for photoshop? (Score:1)
Re:encrypted, compressed, journaling.... (Score:1)
Hint: not everything needs to be compressed / encrypted.
Re:ReiserFS for Mac OS X? (Score:1)
I thought "crypto with a hole" was illegal? (Score:1)
Correct URL (Score:2)
http://www.namesys.com/whitepaper.html [namesys.com] is much better.
Cheers,
--fred
Re:ROTFL! (Score:1)
Don't even get me started. After looking at how their RPMs are built, it's a wonder SuSE runs at all. Half of the ones I looked at *can't* be built as anyone but root. So if they miss a file, there's no way of knowing during QA, because "it works for me". Making spec files without a BuildRoot is like going whoring without a condom. You may get out ok, but most likely you just got screwed.
We supported SuSE in our previous release of our software where I work, but I've given up after spending almost a day trying to coax their system into compliance, when I can build 20 meg of code on RedHat 6.x and 7.x, mandrake 7.2 and 8.0 in 2 hours from a single spec file.
Solaris Journaled UFS? (Score:2)
The most famous example of a file system that grew into journaling was Solaris UFS. I have heard some rather harsh criticism (from SGI) on the design. I don't know enough about filesystem design to discuss the merits, but I do know that Sun was the number one US server vendor last year, so they must be doing something right.
Here is the man-page entry:
logging | nologging
If logging is specified, then logging is enabled for the duration of the mounted file system. Logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the file system. Once a transaction is stored, the transaction can be applied to the file system later. This prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck. And, because fsck can be bypassed, logging reduces the time required to reboot a system if it crashes, or after an unclean halt. The default behavior is nologging.
The log is allocated from free blocks on the file system, and is sized approxima tely 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. Logging can be enabled on any UFS, including root (/). The log created by UFS logging is continu- ally flushed as it fills up. The log is totally flushed when the file system is unmounted or as a result of the lockfs -f command.
Re:I thought "crypto with a hole" was illegal? (Score:2)
--
Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.
Re:Like Frank Xia ... (Score:2)
--
Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.
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.
--
Re:Standards, limits of extension interfaces (Score:2)
I don't see how it is x86 specific. It is specific to CPUs that use caches, which is pretty much all non-embedded CPUs, and many of the embedded ones. I would imagine this would not be faster on something like the Terra, which is a non-cached CPU, but since it relies on proper management of 1000s of hardware level threads, I don't think Linux is ready to run there at all. Even on those systems it should be faster then indirecting through a pointer, faster by exactly one memory access (the pointer).
I do agree that it is untested (in terms of benchmarking). I don't think it has entirely wrecked extensibility. One needs to modify that file to add a filesystem, so you can't do it through a run-time loaded module...unless you use the generic void*.
I'll go for "that is really really ugly", and maybe even "does that make a noticeable difference when you are probably going to schedule a disk I/O?", and even "I'm glad FreeBSD doesn't do that". There is no way I'll buy "it's x86 specific" though.
Re:Standards, limits of extension interfaces (Score:2)
This has been discussed on the LKML. Using a Union for all the various FS specific inode info is a performance hack. You could have a pointer there to a FS specific inode, but you are going to lose memory locality benefits, and cause cache line thrashing. Inodes are touch OFTEN, that makes thes memory issues important.
Further this is a performance hack that takes advantage of the fact that the Linux Kernel is open source, and easily compiled. You can't get this advantage in closed source without arbitrary FS specific inode info size limits.
But, you are right there is an ugliness to it, but don't make the mistake that Linux Kernel developers are idiots or poor coders. This has been considered.
Remember the truism: The Perfect is the enemy of the Good.
Re:Mmmm... CPU cycles (Score:1)
I have recently built a firewall server with 2 ATA33 drives mirroring each other via md raid1 (all reiser except
This firewall box has 256MB PC133 RAM and a Duron 750. This is probably about 4x more RAM and 6x more CPU than necessary.
For server situations, CPU is so cheap that I believe you should pile on as many options as possible, as long as they're optional. modular plugin filesystem functionality is really really cool, and if I can plugin a steganographic encryption system [mcdonald.org.uk] (or choose to build it in statically as long as its presence is 'masked' somehow
Your Working Boy,
- Otis (GAIM: OtisWild)
Re:Mmmm... CPU cycles (Score:1)
Still, I'd like to see compressed ISO mounting via loopback...
# mount -o ro,loop,compressed
Your Working Boy,
- Otis (GAIM: OtisWild)
ROTFL! (Score:1)
ROTFLMAOL! Good one, Hans, good one. You just lightened my day with that joke. I mean, it's a joke... isn't it? QA for SuSE means "the booklet has pretty colors and one or two really stupid and annoying jokes". Before I moved I hoped to find people who actually could tell a technically solid product appart from a big budget marketing department. *sigh* Then I thought "ok, I'll give this a try, it can't be that bad". I withstanded a little over 14 months of it. Then I broke. SuSE is invasive. "What? You are the sysadmin here? Yeah, right!" Their entire approach to the distribution is painfully invasive. It's their way or the highway (sorry, couldn't resist -- but it still applies). Most of the time that thing called SuSEconfig will respect the changes you have made to config files, but the problem is, most of the time just doesn't cut it. I could just quit using it, but it's not an option if other people "help along" with the adminning, because they like not having to use that horrible program called vi (or any other editor that doesn't have buttons for that matter). In fact, the day I broke was because SuSE decided Magic-SysRq is an spawn of the devil... that spiced up with the horrible (non-existant) upgrade paths they have, which I'm sure their QA department have tested and have made sure it works...
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:Mmmm... CPU cycles (Score:1)
Re:SQL crippling? (Score:1)
What I would replace it with is described at www.namesys.com
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:I thought "crypto with a hole" was illegal? (Score:1)
They've been "eased", "suspended", or whatever. Just another capricious fascist executive order away from going back in. Mark my words, they'll put it back someday and make an example out of whomever is politically inconvenient at the time.
--
Re:Standards, limits of extension interfaces (Score:2)
I think I gave up on the idea that Linux would ever know what it was doing with filesystems when I saw this abomination [linux.no]. That's right, Linux not only has no concept of vnodes, it actually uses a union of every single filesystem type for its inode data structure. Search lxr for "vnode" if you don't believe me. So much for generic, to say nothing of modular.
--
Re:Standards, limits of extension interfaces (Score:2)
So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster
As for that truism, here's another: penny wise, pound foolish.
--
Re:First things first... (Score:1)
I'd hate to have ResierFS installed all over the place and then this prick demands royalties or something 'a la Unisys'.
--
Delphis
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.
"Reiser On ReiserFS's" (Score:1)
Re:They actually make money.... (Score:1)
I hate to tell you, but I'm pretty sure Hans Reiser is male. The hint was when the interviewer called him "Mr. Reiser".
Caution: contents may be quarrelsome and meticulous!
Re:I'm pretty sure Hans Reiser is male. (Score:1)
True, I've never met the guy. He could be one of those androgynous anime-looking men. (today on "It's Pat" - Pat talks about Free Software with Hans Reiser.) But judging from his flame potential on the lkml, I still would have guessed male :).
Caution: contents may be quarrelsome and meticulous!
Re:Photoshop plugins? (Score:2)
Re:stability?? (Score:1)
Bullshit. The plugin version would (presumably, that's the general rule for kernel modules) have to match your kernel version, and you have to be root to load the modules, and I assume you'd have to explicitly enable the functionality of the plugin for individual filesystems.
So, if you run any untrusted code as root, let alone an untrusted kernel module, you deserve any shit that's going to hit the fan.
--
Re:Mmmm... CPU cycles (Score:1)
Thats a "compressed volume", or "partition", or "drive".
On NTFS, (and as ReiserFS intends on doing it i believe), you compress on a file by file basis.
On NT, you right click on a file -> properties -> and you have your usual attributes, "system", "hidden", "read only", "archive", and a new one, "compressed".
Check compressed, hit okay, and that file is now stored compressed.
The volume, ie. partition/disk is NOT compressed, the NTFS filesystem is still normal as always, but if the compressed attribute is enabled on a file, it is stored compressed; other files are not.
Of course, you can enabled "compressed" on a dir, and it will ask you if you want to recursively compress all other files. (yes or no). Any new files put into that dir will be compressed on default.
Basically, this is alot different to the old doublespace/drive space technique.
It also lets you see wierd things; right click on a 10kb file, and it will say "file size: 10kb", "size on disk: 12kb". Okay, that makes sense. That 10kb file has been allocated 3x 4kb "clusters" or "allocation units". 2kb of the last cluster is wasted.
Compress it, and it will say, "file size: 10kb", "size on disk: 8kb".
Nifty.
Personally, i prefer this method of compression. You can compress your text/documents directory, but not your mp3s/jpegs/etc which won't compress at all.
Its quite nice, and i'd love to see ReiserFS (and others, ext3fs? UFS) support it.
I suppose you'd use the 'chflags' command (FreeBSD has that, i believe linux has something equievalant for ext2fs flags) to set the 'compressed' flag on a file/dir.
D.
Re:Mmmm... CPU cycles (Score:2)
Dunno. NTFS Is a journalling filesystem and has had compression and encryption for years. Compression has been in NTFS for at least 6 years, perhaps quite a lot longer. (dunno if NT 3.51 had NTFS compression).
I've found it works *great* and has no real performace impacts. (apart from serious fragmentation if you go and compress your whole drive at once. When that happens, just do a big defrag.)
Nevertheless, with the cheapness of hdd's these days (they practically give away 40gb drives) filesystem compression is rather useless.
I also see your points, how do seek()'s and things work? I dunno.
D.
Re:SQL crippling? (Score:1)
Don't throw away the baby with the water. The limitations of SQL are due to it not supporting the full relational model, and to its arbitrary limitations.
We need a properly implemented relational database language -- probably based on Chris J Date [dbdebunk.com.]'s and Hugh Darwen's The Third Manifesto [dbdebunk.com.].
Going for any hierarchical model, be it an OODBMS or a filesystem based one, is forfeiting all the relational model advantages because you find SQL, which isn't really relational, lacking... and you get nothing that any proper D [alternativetech.com] wouldn't offer.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Re:SQL crippling? (Score:1)
SQL is crippling because it doesn't implements the full relational model [acm.org], as you can read in DBDebunk [dbdebunk.com.].
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Re:Mmmm... CPU cycles (Score:2)
And since compression is deterministic, compressing wil do absolutely NOTHING to protect against a ciphertext-only attack, except reduce (slightly) the effectiveness of a "birthday attack". A 128-bit block cipher (such as AES) should be perfectly immune to such attacks. Ie. compression does NOT enhance security of the ciphertext, in any appreciable way, using a modern (ie. non-DES) cipher.
Re:Plugins do the same as for photoshop? (Score:2)
Erm. None, really. Based on the architecture of the file system, I think plugins would be an interesting and, most importantly, plausible concept.
No one wants to take a risk of widespread data corruption or data loss.
You've obviously never seen the Linux zealots running the -dev releases of Debian. Sheesh! Talk about trashing a system sometimes...
Cheers,
levine
Plugins? (Score:2)
Re:Plugins do the same as for photoshop? (Score:1)
It's even easier than that... (Score:2)
I once in my very newbie-days made
Too bad I needed
http://www.reiserfs.com/whitepaper.html (Score:1)
Don't miss reading Reiser's vision of the future - if they can pull all this off, it will truly change the way computers are used.
Re:It's even easier than that... (Score:2)
I find it very strange that nothing appears to depend on RPM in RedHat...
Standards, limits of extension interfaces (Score:2)
I really hope that when Hans and Co. think about how to extend filesystems they'll put their weight behind some generic facility and not just pull some new ReiserFS-specific interface out of their collective ass. Stackable vnodes, which are supposed to address this same need, are ancient history. NT has had filter drivers - not just for filesystems but for just about anything - since day one, and they have proven invaluable as a way to implement new functionality without writing a whole new filesystem. Erez Zadok has done some really cool work on a system called FIST for this sort of thing. All of these should serve as sources of inspiration at the very least, and of code in some cases.
On a different note, journaling is not really something that can be added as a plugin, extension, or filter. Even if you have a generic journaling interface or layer separate from the "core" filesystem code, you have to make sure that that core code is "journaling-friendly". This involves thinking about ordering and atomicity, plus callouts and hooks between the main FS and the journaling code. It's pretty pervasive, and not something that can be done "stealthily" by adding a plugin or filter to a filesystem that was never designed (or, as in ext3, redesigned) with journaling in mind. Encryption, compression, virtual namespaces, all sorts of other things can be added as plugins or filters, but not journaling.
Re:Solaris Journaled UFS? (Score:2)
Perhaps I wasn't clear enough. I wasn't saying that you couldn't add journaling to an existing filesystem. What I was saying was that you couldn't add it *as a plugin*, i.e. by leaving the original code untouched and adding a separate journaling facility. You have to change the original code, at least to the point of making it "journal-friendly".
UFS is a good example of this. They implemented a mostly-separate logging component called ufs_log, but the original code is still littered with flag checks and callouts to use it. It could probably be more modular than it is, which might be the source of SGI's criticism, but it could never be so modular as to be a plugin.
Re:Like Frank Xia ... (Score:1)
Re:Like Frank Xia ... (Score:1)
Disregarding the facts, I imagine the toilet was in fact invented by the famous Japanese sanitation engineer Dr. Takhira Shita.
Other fine, albeit fabricated, news stories are available here:
http://www.denounce.com/ [denounce.com]
Re:First things first... (Score:2)
Re:stability?? (Score:1)
re: Third-party bad code -- Then don't use it until it is tested stable by a third party. Back up your data. Don't run beta code on production systems. Etc.
--
Charles E. Hill
Re:Mmmm... CPU cycles (Score:1)
Disk compression has been around since the good old days of DOS 3.21 with the likes of Stacker, DoubleSpace and a few others. (Possibly much sooner, but those are what I can remember off the top of my head.) The algorithms are probably all worked out and on file somewhere.
Disk/file/drive compression was real big until Microsoft included the function in an OS upgrade.
--
Charles E. Hill
Re:Mmmm... CPU cycles (Score:1)
File system plugins (Score:1)
nitpick time (Score:1)
Different model (Score:2)
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.
Re:It's even easier than that... (Score:2)
That one took some juggling to solve. I now have a staticically linked ldconf.
Re:ROTFL! (Score:2)
Re:encrypted, compressed, journaling.... (Score:1)
But seriously, I can't see why a filesystem plugin couldn't be statically compiled into the kernel. It's still a plugin from the point of view of the file system, but during its initialization, it registers with the fs and then can be used like any other part of the kernel. I don't know if this is the way they are going to do it, but it would be possible.
Re:RTWP (Score:1)
Ah yes, hierarchical databases
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
Re:I thought "crypto with a hole" was illegal? (Score:2)
Re:undo plugin would be handy (Score:1)
Re:SQL crippling? (Score:2)
Re:Plugins do the same as for photoshop? (Score:1)
You've obviously never seen the Linux zealots running the -dev releases of Debian. Sheesh! Talk about trashing a system sometimes... ;)
I thought about mentioning the bleeding edge types. But they are so used to bugs, they don't mind them. =)
Re:Plugins do the same as for photoshop? (Score:2)
Plugins do the same as for photoshop? (Score:4)
So ReiserFS becomes a VFS? (Score:1)
--
Re:Mmmm... CPU cycles (Score:2)
IMO, the real solution to this "problem" is to use intelligence in choosing how you use your file systems. If you are in an environment where performance is hyper-critical and you need to have rapid, accurate seeks, you just don't use a compressed file system. You only use it for file systems where that's not likely to be a problem. The whole advantage of a pluggable architecture is supposed to be that the various attributes like compression, encryption, etc. are optional, after all.
Of course there's also some question about the practical utility of compressed file systems these days. In practice, we're already using compressed file systems by using compressed file formats of various types. The big files that are going to use up all of the hard drive space for desktop-class users are things like pictures, music, video clips, etc. But those files are already compressed using JPEG, MP3, MPEG, etc., so a compressed file system isn't really going to buy you a whole lot anyway. Doing things that way also has the huge advantage that you can use highly optimized compression algorithms for each different class of data, rather than a generic one that won't work as well. People working on larger, more powerful systems are less likely to be willing to pay the performance hit for compression.
Re:I thought "crypto with a hole" was illegal? (Score:1)
Re:stability?? (Score:1)
You donøt see these kind of problems with the kernel, so why whould you in a filesystem
Re:Get ready for the RDF? (Score:1)
Choose the Filesystem that fits you (Score:2)
I like ReiserFS and I found that it's completly stable, it has never crashed. Others like XFS and that is fine by me, just don't tell me that my choise is wrong, I'll decide that for myself.
The great thing about Linux is that it let us choose what we want and don't give us what some dude i Redmond thinks we want. Let us have have 3,4 or 8 filesystems, then the user can choose what filesystem he or she want to use.
Get ready for the RDF? (Score:3)
What, make them run 55% faster on a Mac than on an equivalent PIII?
Re:First things first... (Score:2)
From the interview
Not every day a big name in software grants your wishes...
Re:SQL crippling? (Score:2)
try Database Debunkings [firstsql.com] for some views of the limitations of SQL.
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:Ooops... (Score:2)
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....
Re:nitpick time (Score:1)
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 :).
encrypted, compressed, journaling.... (Score:2)
And you expect to boot off of your encrypted/compressed drive how again?
Forgive me if I'm wrong, but you need to read the module files off the hard drive in order to load them and use them, but you need the modules loaded to read the drive... Kind of a chicken before the egg problem?
Lol. (Yea, I know. Boot partition is a standard FS the kernel and bootstrap prog can read and keep your FS module files on a non encrypted/compressed drive. But still, it's funny. I'm sure that more than a few newbies are going to forget about this little problem, move their module files to the encrypted drive, and then when they next reboot it won't work. *grin*)
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!"
I agree (Score:2)
"I now tell people that I firmly advocate making the names of the programmers as prominent on the code as possible, especially when it is free software, and the sponsors should also be prominent on the code. People who do something should get either fame or money as their reward for it, and for free software to succeed we have to maximize the amount of fame that goes around. I think it is a complete rip-off that Stallman's name is not on every Linux distro (or at least the name GNU). It hurts his ability to command attention from people outside the industry who don't know much about us, and it is simply unfair. Failure to cite properly is considered an offense in academia, and it should be considered an offense in the free software community."
stability?? (Score:2)
Re:Ooops... (Score:2)
Off topic, but you reminded me of a bug I once saw on a page of "most interesting bugs" in an older version of multics. It seems that the entire OS was swappable, and in one version, the swapper-out module could swap out the swapper-in module...
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:Like Frank Xia ... (Score:2)
port named after him. Or Georg Keyboard, Enzo Tpqic02,
Bzzz wrong. compress-y jounaling-y crypto-no (Score:2)
Attitude of ReiserFS's developers/backing company (Score:2)
From what I have read thus far on ReiserFS and how they are planning on charging for plugins in the future along with ports, XFS seems like a slightly better choice for those concerned with the aesthetics of a project. I don't mean to be a "FREE!" bigot, but I wouldn't want to run something on my system next to the very core of Linux that didn't match the philosophy of it's neighboring code. I hope XFS finds a place in the kernel -- it deserves it a lot more -- and politics casts ReiserFS out. I know the argument: "People have to eat!" Well, that's fine and dandy, Certainly ReiserFS should be available. I just don't think XFS should be left out of the tree if it is embracing more platforms and has no commercial "options" (thus, making it more free.)
From the ReiserFS FAQ: "15.Can I use ReiserFS on other architectures than i386? Yes, on DEC Alpha. You may be able to easily bribe us to do the port though...."
From the XFS FAQ: "Q: Does it run on platforms other than i386? The current XFS tree seems to work just fine on ppc now (aside from some trivial compile fixes). It also runs well and is getting sporadically tested on the alpha, sparc64 and ia64. But on all of those platforms it is
not as well tested as on i386, but so far there are no major problems on those platforms known. All in all it looks like XFS will be running across a lot of platforms fine soon (with all the platforms above we have 32/64bit and little/big-endian architectures supported. If you run it on a platform not mentioned here please
let me know so that i can add it. Also an important note is that XFS is inherently platform independent in the on disk layout - so it should be possible to move a XFS disk from one linux platform to another out of the box."
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.
--
Why in kernel space? (Score:2)
What are the disadvantages of putting it into kernel space?
Maybe ReiserFS is the best we are going to get and the only way in which people are going to migrate to something less impoverished than the current UNIX file system data model. But I still think it's not a good engineering tradeoff overall.
They actually make money.... (Score:2)
She has a darn good point on this. If all that Linsux companies can do is produce pieces of plastic to buy, then I am definitely going to take my money elsewhere. The reason I buy software that is not open source is because I can't get the sources.
Is open source bad? No, just the business model. It's a decent community, it just doesn't work in the corporate world. I know very few people who, faced with a free choice and a paying choice, both of which are perfectly legal, will take the payment route.