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....
ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.
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).
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.
Reiser? Stable? Now those are two words that don't belong in the same sentence.
In dealing with ext3, JFS, and XFS, Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only. XFS I've had issues with two, but never having to completely umount to fsck. JFS has issues where it's journalling doesn't seem to catch something and it later in the middle of operating, figures out it is inconsistant and remounts read-only for fsck, which is also highly annoying. In all cases, get ready to dig through lost+found and figure out what filenames those inodes used to be associated with.
If you seek stablity (which is extremely key for filesystems), the only way I've found to work is ext3. It is a real slug (a *real* slug), but I would trust it much more readily than any other fs.
XML is like violence. If it doesn't solve the problem, use more.
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!
Usually, unstable Reiser filesystems point towards misconfigured or faulty hardware.
I maintain ReiserFS v3 filesystems on terabyte arrays, on database servers, and on our machines that go out to client sites. ReiserFS has performed very well for my company. We are a 24/7/365 shop. Downtime isn't in our vocabulary.
With so many filesystems around, it is strange that nobody is working on interopability. Till today no filesystem exists which works well both in windows and linux.
1. FAT - comes close but does not support very large paritions and files larger than 4GB
2. NTFS - Poor write support in linux
3. EXT2/3 - Writing hardly works in windows and does not support large files.
4. ResierFS/XFS - Have limited support in windows.
Any multi-OS file system out there?
I have to take exception to this, as according to everything I know, this is a bit deceptive. As you would normally want to use a journaling
filesystem on very large discs (whether this be regular hard drives, which is bad enough, but can get very large when dealing with raid arrays, for
instance). 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? In the past, the only way to upgrade rieiserfs was to reformat the device. This is a point that I don't think people pay enough
attention to, especially in production enviroments. Say I have a 500 Gig raid array. I use reiserfs, (which is an excellent filesystem) and it is
later discovered to have a security flaw or a bug that causes data corruption. In order to upgrade to a new version of reiserfs, you have to
reformat the entire array. With ext3, you unmount the device, mount it as ext2, unmount it and remount it as ext3. Done. This is hugely important.
I am completely uninterested in having to maintain a 1Tb of drive space, in order to upgrade a 500G array.
Well, that wouldn't happen, you say? It did. Google
Also, I do seem to remember some problems running LVM and NFS on reiserfs as well, but I am willing to be corrected.
SealBeater
P.S. I am only really interested in knowing if I can upgrade a reiserfs filesystem without having to reformat.
-- Its survival of the fittest...and we got the fucking guns!!!
If you don't want FAT16, FAT32, NTFS (4 or 5), or the OS2 thingy, aren't you out of luck? How would you even install it? Much less mount it, format it, or take advantage of it.
I am not being facetious either, I really want to know
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
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.
Now I have added scripts to my system that give me all the point and shoot functionality of pgpdisk in windows. All it took was a bit of time to learn the tools (mountloop, mount, umount, etc) and a hack of a shell script I found online and now opening an encrypted filesystem is as easy as clicking it, typing the pass, and pressing enter.
What makes the present system great is its level of abstraction. Having a "thing" one can move around to ANY media without having to create new tools every time is a thing of beauty. It takes a tweaky (and now proprietary) add-on to do this in windows - sticking all the encryption in the fs itself would just be a step back to doing things the Redmond way.
if you can intentionally cause collisions by modifying messages appropriately. Then the hash becomes useless for verifying message integrity (because someone could have modified the message while keeping the hash identical).
HAND.
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
If you had to deliver millions of email messages per day, you'd find out that ext3 is not the tool for the job. I simply can't imagine email servers on this scale without reiserfs.
/home three times last year on ext3. The cause was a hardware problem, true, but fs should not be a toast because of it.
Also, i lost my
YMMV.
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?
- I get to upgrade my filesystem so that I don't get to downgrade my kernel should I run into trouble.
- Whenever something doesn't work right, (which never happened to me on Ext2), Hans Reiser tells me that "it's fixed in the newest version", and I get to upgrade my kernel and on-disk-format without the possiblity to back out.
- When things DO go wrong, (which never happend to me on ext2/ext3), it seems I need to tell reiserfsck which sub-version of the filesystem is on my disk (Hans knows that very well on his disks, but I just use filesystems to store my files). Otherwise reiser-fsck may make a bigger mess than it started with.
- When reiser-fsck is neccesary, it often requires a "rebuild-tree", which is time-consuming.
- My filesystem was "suspect". So I start reiserfsck. It apparently does nothing, as it's done in 2 seconds (which is unlikely on a 640Gb partition) When reiser-fsck --rebuild-tree is started it informs me that it's going to take some 5 hours to complete. As I didn't have that time, I interrupt it. Filesystem gone. Apparently the first thing it does is invalidate the old structures. Now instead of "suspect" I don't have a filesystem at all, and have to sit out the 5 hours for which I don't have the time....
- I sometimes have a disk-image of a different filesystem on my disk in a file. Hans Reiser tells me that a rebuild-tree would link the files inside the image into my filesytem! Fixed in newest version. Phew.
Too many (serious) problems, that I'm not ever going to try Reiserfs again. Sorry.MacOS already does something similar with DMG files, it might be worth moving in a similar direction.
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?
So with a plugin, could you make a Reiser4 fs work like VMS' file system (i.e. foo.c;1, foo.c;2, etc.)? To me this is the holy grail of file systems...built in versioning by the file system itself, not a 3rd-party app like CVS.
I was able to use reisersfsck to repair a partition resize that had gone wrong. I was pretty impressed -- only three files lost out of 20,000 (and fortunately they weren't important files!)
So I'd say it works pretty well.
Funny you should ask that.
/. last night POW! the thing just shuts down a.c. output on me for no friggin reason. Yes, I was very upset.[2]
This past week I was shutting down this here Win2k system when I was done with it because my APC 450 V.A. u.p.s. had exhausted its second set of batteries and would not hold through these brief power glitches (likely caused by Florida Power and Light cutting in replacement transformers around here) that we have been getting.[1]
A buddy gave me a large u.p.s. that had been in commercial service, so I hooked up two 12 volt deep cycle marine batteries in series to it and it fired up fine. Right while I was reading
Nonetheless, I stand by my assertion unwaveringly. I was primarily thinking of power outages lasting no more than a few seconds, which are the most common where I have lived and worked. These are more troubling because they leave hardware gates and c.p.u.s in unknown states due to their brevity and result in the "wierdness" that I spoke of in my original post.
You are free to calculate a costs/benefits analysis of replacement hardware under a scenario in which a power failure fried your motherboard, but no matter how good you are at backups, if you actually *use* your computer you will have data that has not yet been backed up. I don't know about you, but my time is far more valuable than this pile of P.L.A.s and capacitors and printed circuits and I don't want to add to the potential to waste that time by going without a u.p.s. and suffering the ensuing headaches. A u.p.s. is a very worthwhile investment, as is a r.a.i.d. and other enhancements.
The primary reason for posting my original comments is that I assume that most subscribers here are software types, so they probably don't have the interest in or experience with these hardware considerations. Words to the wise; the rest can suffer.
SO: when you read a proponent of ReiserFS claim "Well, my ext3 fs lost data on me so it's no better than ReiserFS", ask them if they had a u.p.s. supplying clean power to the box running ext3 before jumping to any conclusions. Back on topic.
***
[1] By the way, turning the machine on and off places it under greater thermal stresses from heating and cooling cycles, thus shortening the life of box. My machine normally stays on all the time.
[2] This has happened about a dozen times to this NTFS in the past week and I haven't lost any data; I'm wondering about the motives of the subscriber who earlier commented that NTFS is the worst file system of all the ones being discussed here.
slashdot: A failed experiment.
Ever notice that all the reports of ReiserFS corruption seem to be from RedHat users?
This should tell you something.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I have a 120gb drive and only around 20gb real data, maybe 10gb for the OS itself, add a another 30gb random junk to that and I still have 60gb of my HD virtually completly unused. Even if tempfiles are not handled special it will take basically forever before my filesystem fills up, its really a non-issue these days.
Beside that, I am taking about an 'intelligent' trashcan, not these "Your trashcan is full, please empty manually" ones. If the HD fills up, the trashcan should of course free itself and overwrite old stuff, possibly with custom threshold and such, no problem there, since in most cases you will find the error you did that lead to file loss relativly quickly anyway.
### Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly).
Yes, it did and its undelete weren't much powerfull or anything, but it was there and it worked already quite fine on old 386er with lausy 200mb harddrives, hardware improved quite a bit since then, undelete features however didn't for no obvious reason.
### In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).
Such stuff will NEVER be enough, I don't actually 'rm' my files, in most cases I overwrite them with 'convert', via piping or whatever. And thats exactly the reason why I want undelete at filesystem level, since the filesystem can track all these without problems, something implemented at the GUI level however can only ever track a very small fraction of excidental deletes or overwrites, if at all.
The hardware to handle a versioned filesystem without problems has at least existed for a decade, its really just the software that still hasn't improved, neither on Linux nor on Windows or MacOS.