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.
Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?
Will we ever have a Windows port of ResierFS or any alternative filesystems?
I only have one question (And I obviously have not researched an answer...):
Is there an easy and non-destructive way for me to migrate my ReiserFS version 3 to a version 4 Filesystem?
--Pathway
IT'S ABOUT FREAKING TIME!!!!!
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.
...to use it for a while. I'm sure it's been tested very extensively, but there are always bugs initially in any major release like this. I'm sure nobody running a server will touch this for a while even with the benchmarks.
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?
IF you can get to the site, you'll find this juicy reference at the end:
[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....
Ok, so thats the standard response, but the main benefits will be stuff like: encryption plugins (so easy per directory encryption).. Finally maybe we'll have fully encrypted home directories easily. and stuff like the winFS system integrated into the filesystem possibly. its also 2X faster then reiserfs, and 4X faster then NTFS The big issue though is that until freebsd gets these benefits, apps aren't likely to get these capabilities :(
so maybe someone should work on porting this, then maybe theres a good chance these technologies will be used extensively..
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 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
How large (and long) can Reiser atomic transactions be?
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.
I'm hanging out for a SQL pluging. Being able to "SELECT filename FROM filesystem WHERE size > 1000000" would be fantatstic (note very basic example). Not to mention meta data plugins that can index your media files and store that data in the filesystem (again with SQL access)
Normal people worry me!
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.
The gentoo guys have not complained about my characterization, if they do in an email I will change it. As the other poster said, gentoo seems to prefer reiserfs in what they write and say.
Hans
One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.
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?
Ran a huge article on Reiser4 a while ago. (Around 2 issues ago)
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?