Slashdot Mirror
Reiser4 Filesystem Released
trixie_czech writes "It's finally arrived. Go to namesys for reasons to use reiser4 as a filesystem and benchmarks. Go here to download. Enjoy!" The Namesys homepage in its current stage reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto -- which is to say, there is a lot to read here, not just a bullet-pointed feature list.
I doubt it. In general, that's not necessarily possible (though you can get away with it in special cases). In any case, doing that without a UPS would probably be risky, since there would be a (probably very long) period of time where the filesystem is totally incomprehensible to BOTH filesystem drivers (old and new), and if the system dies during that time, say bye-bye to your data.
ext3 has fewer bugs and has been through more testing. ext3 has a functioning fsck, reiserfs does not.
For most applications the reliability of the filesystem is far more important than the performance.
I'm definitely excited about reiser4 but I don't expect to be using it in production systems for years, unless I have an application that specifically requires it. If an fsck for reiser4 is never released, I might never use it.
Would it be possible to copy all data from the ext3 partiton to a network mountpoint(nfs, ftp, samba, etc...) format the drive to reiserfs, and then copy all the data back?
Yes! Some advice, however: if possible, make two separate copies of your data on different remote servers. Also, check the integrity of your copies using something like md5sum -- there's nothing worse than moving data to a new location and finding out it's corrupted only after you have deleted the originals.
Tubal-Cain smokes the white owl.
I remember reading something a while back about how ReiserFS would occasionally barf and corrupt data... And that the Dev response was something to the effect of 'so what?'.
How stable in this new version in terms of data loss? Is this something that's optimized to run on a RAID array--with, say mirroring--that gets it's speed from dangerous shortcuts that are only acceptable in a non-single-disk environment?
Now when will we see it in the vanilla kernel?
Star does though.
And Reiserfs (and for that matter, Linux kernel) is not developed by professionals? Reiserfs is fully funded and the designers/coders are paid; By definition, PROFESSIONAL. But they are also talented
I suppose it's just a coincidence that the reiser benchmarks page doesn't compare it to XFS... or maybe they were too embarassed to show the results?Please quit being a total twit. XFS has its' place, but for now, we are discussing ReiserFS. Just for the record, ReiserFS has been around for years, and does a great job with mixing loads of little to medium files. While XFS does an ok job, it really excells with the large files, in particular, very large sparse files.
For what it is worth, I have used Reiserfs, XFS, JFS, EXT3, EXT2, and minix for linux FSs. I have found that they all have advantages depending on what you are doing. minix works for compatability (with very OLD linux); Ext2 does a great job with a mostly read only fs (think boot or /usr; Ext3 has the advantage of data journaling, but it is soooooo slllloooowwww; Jfs, XFS, and Reiserfs are my main ones and they always work.
I prefer the "u" in honour as it seems to be missing these days.
Write on the blackboard 10^10000000 times:
"EVERY computer needs an uninterruptible power supply. EVERY one."
There are so many problems of which you might not be aware, aside from those requiring you to run fsck afterwards, which are solved by a good u.p.s. that you'd be penny-wise, pound-foolish for not putting a u.p.s. on every machine in sight.
My clients think that I can walk on water simply because I eliminated a large share of unexplainable wierdnesses from their machines by installing an inexpensive u.p.s. on every single one.
Solid, clean power is very important to a stable computing system. I cannot stress this enough.
slashdot: A failed experiment.
This looks very cool.
.reiser_meta folder in each directory to store the corresponding file directories? Or is there another way?
Using files are both files and directories is really nice - throw ACLs, metadata, whatever in a directory the same name as the file: access it as a file and it is the file, access it as a directory and it provides access to the metadata. It doesn't break things. Well, not much. As mentioned, this will break things like tar a bit. But the VFS has managed to deal with resource forks from HFS, albeit in a slightly ugly fashion. This is a little nicer, and perhaps with time will be the framework for slowly abandoning outdated filesystem concepts.
How would you mofidy tar to deal with this? Add a
"I think it would be a good idea" Gandhi, on Western Civilisation
There are two kinds of people, when it comes to the original VW Beetle: Those who love them, and those who hate them.
People who do not fall in one of the above two categories have never really used or owned an original VW Beetle.
It seems filesystems are the same way. I'm a long-term Ext2/3 user and have never had any particular issue with it. For the medium-power stuff I work with, it does fine. The filesystem on my laptop has been ext2/3 for almost 5 years now, I still have email, documents, etc. from 5 years ago on it. (It's been copied a few times - it originated on an AMD K6 system, now it's on a Dell Centrino Laptop)
So, I guess I'm in the "Ext3 is all good" camp.
Reading these posts, there are those who love Reiser, and those who hate it. Those in the middle haven't apparently used it.
I've found Ext3 to be slow when you have more than about 5000 files in a directory. If I had a specific need for that, I'd consider Reiser if my particular distro (RedHat migrating to Debian) supported it "out of the box".
Other than that, why bother? I've delivered millions upon millions of email messages and many millions of website hits on servers running Ext3.
So, for me, what filesystem I use is sort of like what tires I use on the car. I might care slightly when installing, but otherwise I wouldn't give even a rat's ass.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
"Reiser4 is architected for military grade security."
DING * DING * DING * DING
Alarm bells going off here. There is no commonly accepted definition of what constitutes "military grade security". Authors and vendors should avoid this terminology like the plague. It reeks of snake oil and most security profressionals will look askance at anything that touts this "feature". Having said that, I've used Reiser3 and I think it's great. There's no reason to think Reiser4 won't be even better. Given its plugin architecture there's also no reason to think that secure plugins can't be developed for it in a transparent way that actually provide good security. Maybe my complaint here is pedantic. Never say never, but no software program should ever use the phrase "military grade security" if it wants to be taken seriously. There is no standard of "military grade security" by which such claims can be measured. Why would you want your software to be grouped with fraudulent security products, even if yours really is secure.
When you're being paid by the military and being told what their needs are, you can say military all you want.
Apparently, Omnifarious is stubbornly concerned that someone might hack into this guy's computer when he is transferring from ext3 to reiser4, spend significant (hypothetical even) resources in generating identical files that have the same md5 sum in the brief window of opportunity before the file transfer is complete. And what would be the attacker's gain? Nothing more than pissing this guy off by having a couple of corrupted files.
Yes, MD5 collisions have been shown. That has NOTHING to do with the problem at hand regarding checking file corruption when transferring between two disks. The argument that MD5 should be abandoned for this purpose is ridiculous.
There are also some severe disadvantages to block-level encryption -- from a user standpoint, WinNT-style filesystem-level encryption is generally preferable. Among other things:
* Filesystem-level encryption can outperform block-level encryption.
* It's easy for a Windows NTFS user to "start encrypting something" -- they right-click a directory and check a box. Linux requires a new mounted filesystem running through a new loopback device. Since this isn't doable at the user level in any distro that I'm aware of, it pretty much means that each user doesn't have their private files encrypted separately.
* Choosing as-needed performance is not trivial. I currently maintain individual files encrypted with GPG. I don't want to have to have my P2P software making my kernel blow cycles constantly and unnecesarily encrypting and decrypting software.
* Unless I'm doing something really grotty, like putting a filesystem on block-level encryption on an LVM virtual volume, if I'm using block-level encryption, I'm forced to choose how much space to allocate to each encrypted area -- how much to put towards my ~/.private directory, how much to put in my ~/main/notes/passwords directory, and so forth. If I'm using filesystem-level encryption, I'm taking available space from a shared pool.
* While not strictly a block-level vs filesystem-level encryption issue, no major distro that I'm aware of provides a nice interface for setting up encrypted directories (well, mount points with block-level encryption) and home directories, with a user's login password used to decrypt keys used to access the encrypted filesystems. Windows is significantly more user-friendly (including providing the option of administrative key recovery) here.
The block-level approach is ideologically clean and modular, but has serious drawbacks. It cannot replace filesystem-level encryption.
May we never see th
This is the danger of ext3 journaling (and possibly others as well). It makes people beleive that just because the filesystem passed as "clean" during boot, no corruption occured. Try a full fsck after a year or so of running (with a number of power failures/OOPS'es), and you will probably find a number of ext3 fs corruptions not detected by the "fast" fscking.
As far as reiserfs is conserned, bring me quota and i'll consider it. Until then, it's ext3 with full fsck's at boot.
Probable impossibilities are to be preferred to improbable possibilities.
Aristotele
Read what Hans wrote again. Shipping their kernel with REISERFS_DEBUG turned on isn't a question of limited resources, it's a deliberate attempt to undermine the performance of Reiserfs on that platform.
(and yes, I've read the excuses for this, and no, I don't use reiserfs, so it's not like I'm carrying water for them, but Redhat's behavior in this regard has been awful)
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga