Reiser4 Filesystem Released 637
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.
ext3 to reiser4 ? (Score:4, Interesting)
Re:ext3 to reiser4 ? (Score:5, Informative)
Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?
No, you will have to reformat. However, I recommend the upgrade; I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs. The only arguable advantage of ext3 is its compatibility with the baseline ext2.
Re:ext3 to reiser4 ? (Score:3, Insightful)
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
Re:ext3 to reiser4 ? (Score:5, Informative)
ext3 has a functioning fsck, reiserfs does not.
I myself have never had any problems with reiserfsck -- what exactly is wrong with it?
Re:ext3 to reiser4 ? (Score:5, Funny)
You don't know? The problem with reiserfsck is that it is invisible to those who are dogmatically anti-Reiser. Hans is currently working on a ReiserDecloak() function to address this.
Re:ext3 to reiser4 ? (Score:5, Informative)
"man reiserfsck"
But ReiserFS doesn't need an "fsck" type program in normal circumstances. In power outages, etc., it's rock-solid. But for things like drive failures and the likes that tend to actually corrupt the data, then yes; EXT3 is the better choice. The reiserfsck program isn't intended to be run on the event of just any power outage or failed unmount, because those sorts of things don't tend to damage the filesystem.
I've been using ReiserFS 3 for years and I've really been happy with the results. The only times (once or twice) that I've had problems were when I had severe hardware malfunctions (due to failing mobo capacitors and a dying hard drive), and my own carelessness when trying to repair the bad data.
Re:ext3 to reiser4 ? (Score:5, Informative)
reiserfsck is there, and does work.
I've had more problems with the Ext filesystems than I care to mention, and we do not use Ext2 or Ext3 on any production machines that run Linux any more. Everything's ReiserFS v3, and once we start testing Reiser4, we'll move to that.
Ext3 was a hack for compatibility with Ext2. It serves its purpose, which is easy upgrades and backwards compatibility.
Re:ext3 to reiser4 ? (Score:3, Informative)
AFAIK, with journalling, there shouldn't be *any* fsck after a bad shutdown - with the few times I've pulled out power cords, I've never seen an ext3 fscking.
Then it seems that reiser spends about a second doing a fast fsck every boot, whether is was shut down cleanly or not...
Re:ext3 to reiser4 ? (Score:5, Insightful)
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.
Re:ext3 to reiser4 ? (Score:4, Informative)
Its also true that by default after 6 months or 30 mounts an ext3 volume *will* perform a full fsck. This can be very painful if the volume is large enough/holds enough files that an fsck will take 24 hours plus (I've seen this several times)
Personally, I'm a fan of IBM's jfs. I had some early problems with it but they were real responsive to every issue I found while punishing it as an NFS volume in a test system.
Huh? (Score:5, Informative)
It astounds me that your post was marked as "Informative," because it's downright wrong.
Now, if you're talking about fsck after a certain number of boots, or a full fsck for whatever reason, then no, there's no advantage over ext2. It's ext2 + improvements + journal, for the most part.
For my money, using ext3 without btree hash dirs is stupid nowadays. Go back and bench reiser vs. ext3. ext3 is usually still slower, but the gap is narrower nowadays.
Re:Huh? (Score:5, Interesting)
1) Reiser destroyed Ext3 for directories with many thousands of files in them. However, now you say ext3 has btree hash dirs, probably minimizing the difference
2) Resier was much more space efficient if the average file sizes on the filesystem is very small (say, well under 4k). However, no *real* filesystems I found were like this.
3) The two were about the same in speed for large numbers of small reads and writes.
4) Ext3 was a bit faster for big sustained reads/writes. But it wasn't a huge difference and might not apply to Reiser4.
In short, Reiser4 was more robust to unusual filesystem usage, at a slight penalty to normal usage.
In fairness, this is because Ext has been around for so long, it is optimized for normal usage, and software is tailored not to step on the toes of Ext's deficiencies. For instance, to store huge numbers of small files, people usually use a database of some sort (even if only flat file). Reiser opens the possibility of simplifying life by replacing simple databases of small records with the filesystem; for instance, it might be practical for a Usenet newsreader to store every cached message in a separate file.
But for the most part, I think Reiser will stand on its new gee-whiz features (plugins), rather than raw performance, since there are so many filesystems with roughly comparable performance for normal usage scenarios. As with Longhorn's fancy new filesystem, the question is whether people really want feature-rich files.
Re:Huh? (Score:5, Informative)
V3 of reiserfs paid a performance penalty for saving space and handling large directories efficiently. This irritated the shit out of me, the author, and we fixed it in V4 and then some.:)
V4 is finally to where it is sweet, and works like I fondly imagined earlier version of reiserfs would. We fixed deep design errors, and V4 is a complete rewrite from scratch reflecting all our regrets accumulated over 10 years of learning what the hell we were doing. We were beginners when we started out, as everyone is.
Now, the space savings makes things go faster not slower, and does not add seeks. We learned from XFS also, and allocation on flush works very well. Thanks SGI, for taking the time to explain to me why I should adopt allocation on flush in ReiserFS. XFS is a great filesystem.
Now that the performance advantage is ours for the now, and there aren't irritating flaws bothering me, we should and will move to semantic features not performance as our focus. The post above is right about that. Semantics matter more than performance.
Re:ext3 to reiser4 ? (Score:5, Insightful)
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.
Re:ext3 to reiser4 ? (Score:5, Informative)
Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.
Re:ext3 to reiser4 ? (Score:4, Funny)
I've been feeling ill ever since I came home from Flagstaff...
Re:ext3 to reiser4 ? (Score:5, Funny)
Re:ext3 to reiser4 ? (Score:5, Informative)
It's still perfectly fine to use MD5 to check the validity of your files for bit-errors. Then again, so is CRC32.
I do have a question to anyone more knowledgeable in MD5's weakness: although MD5 can now be spoofed , it's not clear to me from reading the news - is it only directly applicable to messages of a certain type/length or to all messages?
Re:ext3 to reiser4 ? (Score:5, Informative)
Suppose you've got a 1K file. There are 2^1K possible values that file can assume. If you map those 2^1K values to the 2^160 values a SHA1 hash can assume, you have an average of 2^944 1K files that collide on any give SHA1 hash.
What differentiates hash algorithms is their ability to prevent people from generate a text that matches a given hash. It is currently not possible to do this for either MD5 or SHA1. It has been speculated that MD5 is nearing the end of it's life in this regard though. I don't follow the field closely enough to weigh in on the matter, but I can tell you that the only thing that finding an actual md5 collision will do is demonstrate what was rather easily proved in the previous paragraph.
As far as verifying files is concerned, the cryptographic strength of the hash algorithm is irrelevant. Unless you suspect someone will be tampering with your results, use whatever algorithm you can find a useful tool for, be it md5, sha1, or even crc32.
Re:ext3 to reiser4 ? (Score:3, Informative)
Some postings can be found here [rtfm.com], and google is your friend
--Eamon
Re:ext3 to reiser4 ? (Score:4, Insightful)
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.
Re:ext3 to reiser4 ? (Score:5, Informative)
yeah, that, and *stability*. reiserfs has a noteable history of people losing their data because of filesystem problems.
Not over the past couple of years -- the original corruption problems with reiserfs, although pretty severe, are well in the past now.
Re:ext3 to reiser4 ? (Score:5, Insightful)
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.
Re:ext3 to reiser4 ? (Score:5, Informative)
---
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.
I just wanted to add my two cents to this: We had done internal benchmarks at our company, and found XFS to be the fastest filesystem, and seemed to have a good track record with the community. (We didn't consider reiserfs because of its lack of bad block handling).
Either way, we converted ONE of our 2 Terabyte mount points to XFS. Whenever a file would be created on that mount point that exceeded 4G, bdflush would peg the cpu at 100%, commits to the disk would cease, and file system corruption ensured.
This was with kernel 2.4.23.. The problem was fixed in 2.4.25 (maybe 2.4.24, but we never tested that kernel). When we had this issue, and linked it to XFS (through another test system), we quickly migrated away from XFS, back to ext3.
We never had a problem like that was the ext's. We've lost data with both reiserfs and XFS. And if you grep the changelog for the kernels on XFS, you'll see tons of fixes for "deadlocks, race conditions, oopses", etc. These were all fixes AFTER 2.4.23..
Lesson: Stop playing with something that works, and be happy your servers serve. We never made it to testing JFS, and we probably won't. Ext3 might not be the fastest kid on the street, but it has been the most reliable for us.
Bad blocks, etc. (Score:5, Informative)
Oh, dear. Bad block handling is not needed on modern drives, all moderns drives have automatic remapping of failing blocks, and if you have a drive which actually has bad blocks which are visible to the OS you should not be storing any data on that drive.
Just to add a data point: I've also had very mixed experiences with XFS. I installed it and it seemed to be chugging along fine for ~1 year (just regular desktop machine, no particular I/O load to speak of) until suddenly the initial root mount showed an empty
Re:ext3 to reiser4 ? (Score:3, Interesting)
Re:ext3 to reiser4 ? (Score:4, Informative)
EVERY computer needs a u.p.s. (Score:5, Insightful)
"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.
Re:Why I use ext3 (Was Re:ext3 to reiser4) (Score:5, Informative)
This is the single most important factor when it came to deciding what filesystem to run, namely, can reiserfs 4 be upgraded to new versions easily?
Yes; as I understand it, ReiserFS 4 is designed with a plug-in architecture, so that future improvements to the filesystem can be incorporated in a non-destructive manner. You can read more about this functionality in the summary [namesys.com] of the new features in v.4.
Re:ext3 to reiser4 ? (Score:5, Insightful)
Re:ext3 to reiser4 ? (Score:5, Informative)
Possibly using convertfs [narod.ru], but I have no idea if it works or not.
This page [optusnet.com.au] seems to have more info about it.
Re:ext3 to reiser4 ? (Score:5, Informative)
Nope convertfs won't work... From the horses mouth:
To upgrade from reiserfs V3 to V4, use tar, or sponsor us to
write a convertfs.
The lkml posting is probably cached all kinds of places, but kerneltrap [kerneltrap.org] also reproduces it in full.
Then again, reiserfs v4 and v3 have nothing to do with each other (unlike ext2 and ext3 for instance), so there's no quick fix possible probably.
On the other hand - reiser4 is completely untested (compared to reiser v3 and jfs, xfs, ext2, heck even the wine-dll emulation layered ntfs writing driver...), so do yourself a favour and don't do anything quite so crazy as not just using it for a production machine but also trying to convert an existing system to it with 'smart' tricks... Give it a little while... or make a lot of backups...
Windows port? (Score:3, Interesting)
Re:Windows port? (Score:5, Informative)
and many [tuningsoft.com] for [swin.edu.au] ext2/3 [ashedel.chat.ru]
if OTOH, you are looking for a fully featured driver that can be used for production use, then i wouldn't count on it
Re:Windows port? (Score:5, Informative)
Will we ever have a Windows port of ResierFS or any alternative filesystems?
I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.
Of course, you may be talking about a native Windows implementation of Ext2/3 and/or ReiserFS. Which is a totally different kettle of fish...
Re:Windows port? (Score:3, Informative)
I have a hard drive with Windows installed on it and a hard drive with Linux, and I use both OSes. Explore2fs is handy when I'm in Windows but I need to grab a file on my Linux drive.
Re:Windows port? (Score:3, Insightful)
For windows and l
Re:Windows port? (Score:3, Informative)
http://yareg.akucom.de/index.html
works for me now.... I have to say I would much prefer a real driver, but beggers can't be choosers.
oooooo, dancing trees! (Score:5, Funny)
Re:oooooo, dancing trees! (Score:5, Informative)
that's what he meant.
oh, and whoever moderated offtopic didnt rtfa, either. damn, peeps.. what is wrong with this community these days?
pm
Re:oooooo, dancing trees! (Score:5, Funny)
Only one question... (Score:4, Interesting)
Is there an easy and non-destructive way for me to migrate my ReiserFS version 3 to a version 4 Filesystem?
--Pathway
Re:Only one question... (Score:5, Informative)
Well, Mr. Reiser Dude suggests tar in his posting to lkml which can also be viewed on kerneltrap.org [kerneltrap.org].
In other words,
no.
Re:Only one question... (Score:4, Insightful)
Reiser4 may be great.... (Score:3, Funny)
Seriously.... their server admins must be FSCKing angry.
Re:Reiser4 may be great.... (Score:4, Funny)
Hans
Helpful Mirror (Score:4, Informative)
* Reiser4 is the fastest filesystem, and here are the benchmarks.
* Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
* Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
* Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.
V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX and Gentoo. We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.
Re:Helpful Mirror (Score:3, Funny)
No, really, they use a bunch of illustrations like this in the linked article. It dumbfounds me.
Re:Helpful Mirror (Score:5, Insightful)
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.
Re:Helpful Mirror (Score:5, Insightful)
Re:Helpful Mirror (Score:4, Informative)
I know everyone's thinking it... (Score:3, Interesting)
I did an informal comparisson of this fs against several others for one of my classes, and my results had it winning _hands down_.
But on a more serious note, I hope this release is stable. From lurking on their mailing list, it seems that it hasn't been too long since they were in bug-squashing mode.
Who's got the balls... (Score:5, Interesting)
I'm not trying to spread FUD on reiser at all, I run reiser 3 and I've never had any problems. I'm just raising the question of how long does it take until people will put it in production servers and their main desktops?
Anyone who maintains servers care to shed some light on this?
Re:Who's got the balls... (Score:5, Informative)
http://www.redhat.com/archives/fedora-list/2004-J
The date of the post caught my eye. The test was very recent. Ext3 won in this particular case, by a longshot, leading a Red Hat employee to respond "Your investigation proves that we default to the right mode
I haven't seen ext3 (ordered) lose in any reliability benchmarks versus jfs, xfs, or reiserfs, though it's hard to find many such benchmarks.
Re:Who's got the balls... (Score:5, Interesting)
Over the past year, we've had some fairly serious filesystem failures on some of our DB and large FS servers. Ext3 on failed in every instance, Reiser was recoverable (similar RAID/hardware/useage/failure).
We pound the living hell out of our machines, day and night, with billions of small files every year. ReiserFS makes Linux work for us.
There are some instances where ReiserFS v3 is slower than Ext3, but we don't care about that any more. We're finished with Ext2/3, and are looking forward to testing ReiserFS4 now that it's been released.
Re:Who's got the balls... (Score:4, Informative)
Reiser4 does not have such a problem, as it operates in data=ordered mode by default.
Re:Who's got the balls... (Score:5, Interesting)
RedHat are the guys that at one point shipped their kernel with REISERFS_DEBUG turned on just to make us look slow.....
I don't know why RedHat regards us as in the enemy SuSE camp just because we took money from SuSE, we would take money from RedHat too if it was offered....;-)
These distro rivalries are distasteful to me.
Hasn
Re:Who's got the balls... (Score:4, Insightful)
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)
What's with that link? (Score:3, Funny)
Oh...
Yea that homepage looks like alot of others (Score:3, Funny)
Stability (Score:3, Insightful)
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?
Re:Stability (Score:5, Insightful)
Re:Stability (Score:5, Informative)
Reiser4 is fully atomic though, and a write will either make it to disk entirely or not at all, with no data garbling. In other words, assuming that metadata journaling was what made you unhappy, we listened, but waited until a deep rewrite could allow us to fix it with no significant performance loss.
We are very happy that the use of wandering logs allowed us to make things atomic without losing any significant performance.
Re:Stability (Score:4, Funny)
His thoughts on NTFS... (Score:5, Interesting)
[NTFS]
"Inside the Windows NT File System" the book is written by Helen Custer, NTFS is architected by Tom Miller with contributions by Gary Kimura, Brian Andrew, and David Goebel, Microsoft Press, 1994, an easy to read little book, they fundamentally disagree with me on adding serialization of I/O not requested by the application programmer, and I note that the performance penalty they pay for their decision is high, especially compared with ext2fs. Their FS design is perhaps optimal for floppies and other hardware eject media beyond OS control. A less serialized higher performance log structured architecture is described in [Rosenblum and Ousterhout]. That said, Microsoft is to be commended for recognizing the importance of attempting to optimize for small files, and leading the OS designer effort to integrate small objects into the file name space. This book is notable for not referencing the work of persons not working for Microsoft, or providing any form of proper attribution to previous authors such as [Rosenblum and Ousterhout]. Though perhaps they really didn't read any of the literature and it explains why theirs is the worst performing filesystem in the industry....
Well? (Score:3, Funny)
Sweet! (Score:3, Insightful)
Re:Sweet! (Score:5, Informative)
AC (Score:4, Funny)
-l
No compelling reason to upgrade (Score:5, Funny)
adoption of new features will be an uphill battle (Score:3, Interesting)
But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.
I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).
Re:what are you talking about? (Score:4, Interesting)
Well, the Reiser4 plugin infrastructure allows for more functionality to be added to the filesystem. Depending on the plugins created, the processes accessing this filesystem may need to know about them. E.g. GNU tar is incapable of preserving extended attributes and ACLs when copying data. Or look at the NTFS streams [alcpress.com] feature. This kind of thing needs at least some support in userspace, or else it can't be accessed.
It will very much be possible for people to write code that needs to run on Reiser4 in order to work properly. It will be interesting to see if this happens, and if so, how widely adopted it becomes. I think there's a lot of potential here, but I understand how people might be reluctant...
noah
Re:what are you talking about? (Score:5, Interesting)
MANIFESTO (Score:3, Funny)
Now, all I'm interested in doing is exploring the potential of doing everything in the "manifesto" literary style. My next letter to the editor? Manifesto. My thank-you note to grandma? Manifesto. My resume? Manifesto. My next Slashdot posting? Manifesto.
Oh yes
Encrypted filesystems (Score:3, Informative)
It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.
The next release of Suse is going to be a doozy. KDE 3.3, Reiser 4.
Uh, excuse me? (Score:5, Informative)
I think you misunderstand, that's the beauty of it. Basically, Linux (and FreeBSD with GBDE [google.com]) allows you to encrypt a device at the block level. Everything is written to the disk encrypted, including the file system itself and not just the data. This also allows you to abstract the device. It could be a big file sitting on an existing device or the device itself. It's very flexible.
Some of the other advantages of this are fairly important. Here's a few off the top of my head.
On the plus-side, filesystem level encryption lets you choose to encrypt on an as-needed basis (such as with NTFS), but the uses of this are minimal and questionable at best (what about swap, temporary files, and data that you forget to encrypt?)
I think you may have learned from my previous comments how you accomplish this. Hint: you don't encrypt at the filesystem layer.
Using the loopback device to encrypt data has been available for longer than NTFS has had encryption.
Windows vs Linux: encrypted filesystems (Score:5, Insightful)
* 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.
Transactions? (Score:5, Interesting)
Can I write an installation program which creates, replaces, moves, and deletes many files and directories, and have it all be under one transaction with a single commit at the end? Do other 'sessions' not see the transaction until it is complete? Are sessions based on processes or threads or something else?
That would be pretty amazing, to be able to roll back large sets of changes in case of an error. I know that database rollbacks can take large amounts of time (they optimize for the commit, which makes perfect sense) but nonetheless having rollback support in applications would be sensational.
Re:Transactions? (Score:5, Informative)
You can say that this is not really atomic, and by database traditions that is correct, but I believe we have implemented the aspect of atomicity that for sure should be implemented by the file system and not by the layers above.
Later we may support more isolation and rollback, but we started with allowing people to define a set of fs modifying operations that would either all be preserved across a crash or none of them would be preserved. I tried using the term "transcrash" instead of atom, but no one but me loved the term.
I must caution though that the API for defining an atomic set of filesystem operations is still being debugged. The core infrastructure is rock solid though, as it is what we use for atoms defined internal to the FS. We shipped as soon as our core code was rock solid, and plan to incrementally finish the other stuff over the coming year.
User Report (Score:3, Informative)
It rocks. Very, very fast. Whereas an:
would have taken about 20 seconds to run under reiser3, it takes about 5 seconds under reiser4. Very impressive.
I haven't had any stability issues with it. There were ( last time I checked ) 2 outstanding bugs - one nfs ( files on server with reiser4 ) bug, and one strange bug that made adn OpenOffice compile fail miserably. Bug (1) doesn't affect us, as our nfs server is running reiser3, and bug (2) I got around by creating a reiser3 partition, mounting
I just can't get over how fast it is.
Re:User Report (Score:4, Informative)
Boot CD with reiser4progs 1.0 (Score:3, Informative)
The only boot CD I was able to find was the (R)ecovery (I)s (P)ossible Linux rescue system:
http://www.tux.org/pub/people/kent-robotti/loop
It was released yesterday (22 Aug) and is still warm to the touch.
Stephen
This looks very cool. (Score:5, Insightful)
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
Re:This looks very cool. (Score:4, Informative)
Filesystems seem to be like VWs (Score:5, Insightful)
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.
Re:Filesystems seem to be like VWs (Score:4, Insightful)
Re:On the other hand ... (Score:5, Funny)
When you develop software that is immune to hardware failure, be sure to let us all know
How about a undo or at least a trashcan/undelete? (Score:4, Interesting)
Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports
powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?
And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?
German magazine iX (Score:4, Interesting)
They said it was blazingly fast, but had problems, that the performance went down the drain once the processor did something not reiserfs related, thus IO is a higher burden on the processor, due to the tree structure they use.
The other problem is fragmentation, which should be resolved by a defrag daemon/tool running in the background, which was not available back then.
So my question, have those two problems been resolved already?
Re:ATOMIC FILE-ING SYSTEM HERE I COME (Score:4, Informative)
And yeah, you'd better believe it happens. The BSDs use a similar approach called SoftUpdates (basically odrered writes). If power craps out in the middle of a write, you will have corruption. The main advantage is that, because writes aren't scattered all over, you only lose the file(s) you were most recently working on. This focuses the damage, it doesn't reduce it at all.
Re:ATOMIC FILE-ING SYSTEM HERE I COME (Score:5, Informative)
Re:ATOMIC FILE-ING SYSTEM HERE I COME (Score:5, Informative)
Hans
Re:ATOMIC FILE-ING SYSTEM HERE I COME (Score:3, Informative)
Atomicity isn't the same thing as synchronous writes, where the OS won't return from the write() call until the data has truly been flushed successfully to the disk controller (and with controllers which support it, to the platter itself). Atomicity says that a set of writes either happens completely, or not at all.
Re:ATOMIC FILE-ING SYSTEM HERE I COME (Score:5, Informative)
Think of classic banking example: credit savings and debit checking are a single atomic operation. You must ensure that you don't get the credit preserved and the debit lost by a crash.
The poster above you was right.
Re:here is the text from namesys.com (Score:4, Informative)
Re:here is the text from namesys.com (Score:3, Informative)
Re:here is the text from namesys.com (Score:4, Interesting)
Hans
Re:here is the text from namesys.com (Score:5, Interesting)
Re:atomic v. journaled (Score:5, Informative)
Journaled: The data is written to a temporary queue and then copied to the main storage. If the system dies while writing to the temporary queue then the main storage is unaffected; if the system dies while writing the queue to main storage then the system will notice when it reboots and will resume writing the queue to main storage.
PRO: Safer than non-journaled since you can never end up with half a buffer written to disk.
CON: Writes everything twice, causing delays. Very bad things could happen if data and associated metadata are in separate transactions and the system crashes between them.
Atomic: The file data is written to unallocated space on the disk. Once that has completed, the directory record is updated by writing a copy of that record to unallocated space. The directory's parent is then updated by writing *it* to a new region of the disk, and so on up the tree. Since each write doesn't take effect until the next has completed, any interruption results in complete reversion.
PRO: Safe. Faster than journaled since there is no double-posting.
CON: More complicated to impliment, I suppose. I would expect it to be slighly slower than journalled method when writing very small changes to existing files as journalled can optimise the writes in the queue whereas atomic has to finish what it started...
Re:How reliable is an "unstable 1.0" anyway? (Score:5, Informative)
That said, if you have a mission critical server, be sensible, wait a bit.
It is in the -mm kernel, if it goes without a bug report for a week, we send it to Linus. I hav been surprised by the lack of bug reports after going into -mm. All we have is one apache 2 bug report that we cannot reproduce yet.