What’s with the ReiserFS data safety thing?
I constantly hear people badmouthing ReiserFS (V3). For example, see the comments on the APC article. I don’t really need to read an article to know that: even one of my college professors (who contributes to the Linux kernel) has told me so. I don’t know if it’s because people are misinformed… but I’ll pitch in with my two cents:
Update: if you value your information, you may want to consider skimming over the tables and conclusions of this paper that discusses file system failure policy — or (in short words) how different file systems cope with different types of failure. You might be surprised by its conclusions!
I don’t understand why people keep assigning blame on ReiserFS when they lose data because of faulty hardware. Ironically, the complexity of on-disk structures in ReiserFS filesystems is greatly derived by the fact that ReiserFS takes pains to ensure data is written properly, while tuning for performance.
I’ll tell a short story: I once had a 40 GB hard disk go bad on me, and it was ReiserFS-formatted, plus chock-full of my (then small) invaluable MP3 collection. How did that turn out? I only lost two files that used bad sectors. I didn’t have to use the reiserfsck tool. How’s that for resilience? Evidently, I still use Reiser (V3) to the day, in all of my disks.
How do I guard for data corruption? Backups, my friends. I have an LVM volume that combines two old disks, encrypts them with LUKS, and cron does a nightly backup to the LVM volume, through dirvish (yay! incremental backups with an option to access old files if I screwed up inadvertently and deleted important files, then let a few days go by). For extra safety, the LVM volume is unmounted when it’s not in use, and their component disks are actually turned off by hdparm. Oh, and an UPS/surge protector combo protects my computer, just in case lighthing bolts (or, much more probably, morons from the electric company) hit my 4-story building.
I actually went out of my way to get all partitions formatted with ReiserFS, because my Fedora installer didn’t offer it as an install-time option. I think I should also commend ReiserFS’s blazing speed in a (majorly small-file based) regular Linux system like mine.
Bottom line: if you feel your data is at risk by combining ReiserFS and bad hardware, do us all a favor, be stupid and use FAT32 or something. Oh, you don’t have a backup, right? Then don’t whine about data loss, and get over it: you’ve already proven by your inaction that your data isn’t important to you at all. I’ll grant you this: my backup setup was quite hard to assemble, but I don’t have enough money to go around shopping for RAID or external backup solutions; yet, backup solutions for Linux are (figuratively and literally) a dime a dozen nowadays, so my case is no excuse for you.
I’m willing to share my backup automation scripts with you. Just post a comment here and I’ll contact you back soon. In any case, I sincerely hope the Reiser family comes out OK from the ordeal they’re going through.
October 14th, 2006 at 11:38
I don’t get it either why people rag on reiserfs as they do. For the last 4(?) years I have used it for /, /home and /var partitions with a /boot partition as ext2. Baring the odd hardware problem it has proved to me a resilient file system. My boxes have experienced a number of inadvertent, um, power outages and on a power up after a short reiser journal replay, theres not been a single problem. In fact I can easily say I have not lost any data attributable to using reiserfs.
Now I do know from reading reiserfs is not recommended for really huge files as noted by the folks who use mythtv. That’s fine and understandable.
Though the more I read what others have said and their experiences the more I believe it simply has to do with their feelings or whatever about the man himself. Yeah sure he can be opinionated and all that. But really I don’t see him that way any more than Linus himself being that way. In the end I am beginning to lean towards thinking all this “rukus” has more to do with various politics than anything else.
I mean one of the reasons IIRC reiser4 has not been included with the kernel is that a complete reformat would be needed. I know there has been some other reasons for it’s exclusion but frankly that point sounds really lame to me on the kernel devs part. So what that I can’t drop back to v3, big deal. Before switching to reiserfs I was using ext3 and never had a need, nor did I care the file system could be dropped back to ext2. And if “backwards” compatibility is such a huge issue. Then why is there no such thing for XFS or the other filesystems the kernel supports? Hmm?
In the end if the next kernel version included version 4 I’d switch to it in a heartbeat, in the blink of an eye, no matter how many partitions I would have to reformat.
October 14th, 2006 at 11:40
You have obviously no lost gigabytes of customer data for a couple of bad sectors. Filesystems should be designed so that when the hardware goes bad the impact is minimal. With old, slow, true and tested filesystems you can get the most data out even when the hardware fails. This is not the case with ReiserFS.
October 14th, 2006 at 11:51
http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
October 14th, 2006 at 12:26
I may be just as well showing my ignorace here but let me share a simple thought… I have used several file systems in the past including ext2, ext3 and reiserfs. I’ve setteld for reiserfs. There are (just google for it) a number of comparisons between the file systems and how they fare in performace with regards to each other as to guide you on what application they would be more efficient and why not, however … if you have a bad sector it matters not what file system you have, you no longer can read the sector
The ONLY secure way to deal with bad HDDs is to have a good backup plan … everything else is just “plain onld talk” as they say.
October 14th, 2006 at 12:32
If your data is important to you, you should not only make regular backups, you should also verify your backups. Some backup programs does this for you e.g. rdiff-backup (I don’t know how dirvish acts, in this respect).
To make this happen you need to work with a LVM snapshot so that it can compare, backed up data and existing data. Make sure that you have a recent kernel, snapshots have been somewhat unstable in the past.
You should also make sure that the backup is not stored in the same building in case of fire or burglary chances are that you will lose your backup as well.
Another thing, even if you make a LVM snapshot before you make your backup, that only makes sure that what’s on disk remains unchanged during the backup. Transactional applicatins such as databases may preserve their state in RAM, so you must either shut them down temporarily or run some command that stores their information in a consistenst state while you create your LVM snapshot.
Remember that databases are used in many applications, e.g. some imap servers, authentication systems, and the same safeguards must be applied to these as your more obvious database applications such as MySQL or Postgresql.
Finally, I really don’t see much point in using ReiserFS anymore, unless you really, really have lots and lots of extremely small files. If you are running databaes oriented applications such as MySQL or Postgresql, ext3 actually performs better.
October 14th, 2006 at 13:49
No I have not lost gigs of data due to bad sectors and your argument at best has nothing to do with the file system in use. Attributing reisers inability to read a sector that is no longer readable is complete non-sense.
October 14th, 2006 at 17:24
I’m with the author; ReiserFS is just fine for me and when doing benchmarks I’ve seen it to be faster than ext3. I do agree that ext3 is a safer bet but haven’t lost data with either due to problems with the filesystem itself. All my data loss has been user or hardware error so as long as backups are done correctly, you should be able to get back up and running in no time. Also if you’re doing something that really requires high availibility, you would have several machines/drives that are mirrored.
October 14th, 2006 at 19:19
I have had some bad instants wiht RieserFS on GOOD HARDWARE. I got a corrupt drive from a power failure. Before you point to the the power failure and say that is to blame remember, teh whole point of jounarled FS is so that WON’T happen. Second point against Rieserfsv3, basicly nobody is maintaining it. The 4 main guy’s that were worked for Novell/SUse and have gotten tired of it. If Hans basiclly abandoned v3 what is say he and his team won’t do it again on v4. From that angle I will stick with the ext2/3/4 family. IT has a nice proven support history. Yes it is slower, but it has survived every power failure like it is supposed to so far ( Same HD, by the way). YMWV
October 14th, 2006 at 20:48
I have used Reiser 3 continuously since SuSE introduced it six years ago and never lost one byte of data. This has been on a dirty power supply, i.e. anywhere in the Northeast, with numerous power outages, even surpassing the best efforts of several UPSes. So irrespective of the tragic turn of events with the Reiser family or the “Stalmanesque” personality characteristics of Hans Reiser on occasion, the technology has been undeniably sound, innovative, and wonderfully resilent. Now is not the time for less gifted developers to allow avarice to get the best of them and use personal circumstances to debunk a wonderful contribution to open source file systems.
October 14th, 2006 at 21:44
Some Benchmarks including Reiserfs
Below are the averaged file creation, deletion and access performance numbers got by running ‘bonnie++ -s0′ using several filesystems (the benchmark used 16,000 files per directory in each sessions):
Version__1.03__________Sequential Create_______________Random Create________ __________________Create_____Read_____Delete____Create_____Read_____Delete__ ___________files__/sec %CP__/sec %CP__/sec %CP__/sec %CP__/sec %CP__/sec %CP reiserfs_____16k 21459__99 +++++ +++ 17856__96 20172__98 +++++ +++ 16414__96 jfs__________16k__7015__13 +++++ +++__5868__10__3068__14 +++++ +++__1075___3 ntfs 3g______16k__3021__99 14291__99__5226__99__3548__99 16149__99__5223__99 xfs__________16k__2401__17 +++++ +++__2095__15__2301__20 +++++ +++___347___2 ext3_________16k__1862__96 +++++ +++ +++++ +++__1914__96 +++++ +++__9695__98 minix________16k__1450__97 +++++ +++ 18148__94__1694__97 +++++ +++__4847__98 fat32________16k___366__97 +++++ +++__1809__97___428__97 +++++ +++__1361__97 paragon ntfs 16k____58__98__1259__99___245__99____55__99 +++++ +++___832__99 captive ntfs____Always crashes early on file creations and loses files. ________________This was also confirmed and fix denied by its developer.
These are from Szabolcs Szakacsit’s README for his new ntfs driver ntfs-3g.
Real Life File System Tests.
cp /linux-2.4.17.tar.gz /mnt/fs (cd /mnt/fs && tar xfz /mnt/fs/linux-2.4.17.tar.gz) rm -fr /mnt/fs/linux-2.4.17.tar.gz /mnt/fs/linux
___________ jfs _____ xfs ____reiserfs__ reiserfs____ ext3______ ext3______ ext3______ ext2___ ___________ jfs _____ xfs ____reiserfs__ (notail)(writeback)(ordered)_(journal) ext2__ real 1m_23.683s 0m_36.143s 0m_35.545s 0m_19.582s 0m_25.984s 0m_25.152s 0m_34.794s 0m_21.498s user 0m__4.930s 0m__4.890s 0m__5.080s 0m__4.900s 0m__5.110s 0m__4.860s 0m__5.030s 0m__4.580s sys_ 0m__3.810s 0m__8.570s 0m__6.410s 0m__5.590s 0m__3.150s 0m__3.580s 0m__3.400s 0m__2.640s
reiserfs (with notail) wins EASILY (among journaling filesystems (the non-journaling filesystem, ext2, is close)).
January 12, 2002 © Sergey I. Rotar
There are more benchmarks at:
http://www.fortunecity.com/skyscraper/romrow/935/j fs_xfs_rfs_ext.html Linux 2.4.5 versus Windows 2000 Professional SP1.
Jade @ http://linux.coconia.net/
October 15th, 2006 at 0:10
I’ve also used Reiser since SuSE introduced it. On everything from laptops, to servers, to production DB servers that get the crap beat out of them. I even have it on several FrankenBoxes that are cobbled together from parts and are not known for their stability. I can also say that despite some serious HW crashes and power issues, I have never lost a byte of data due to Reiser. In fact I even got data back from a tanked deathstar drive (actually, a recover service got it back. It was totally uncorrupted. They even commented on that fact)
Generally there are two groups. Whiners that complain about everything. And zealots that blindly hate “X” because it isn’t their favourite “Y”. They just hide their “Y” loving in false “I used ‘X’ and I hated it” stories.
The one (half) concession I’ll make to the Reiser haters is that some Reiser hater distro’s either don’t or poorly support Resiser, and this can cause problems that appear Reiser related. However, that doesn’t make it Reiser’s fault. It’s your fault for choosing such a suck distro.
The REAL, original Tachyon, Accept no substitutes!
October 15th, 2006 at 5:34
I have lost terabytes of data because of ReiserFS, using server grade hardware and server grade storage. It is inaccurate to argue that all data loss is due to dinky systems. Consider that other filing systems aren’t losing data when being run on the same dinky systems that blows away data when using ReiserFS, and you start seeing the light.
You brag about not even having to use the reiserfsck tool… that is in fact one of the big arguments against ReiserFS - that reiserfsck command is completely bloody useless. It checks the on-disk structure but has almost zero capability to recover any data whatsoever.
That’s why I use ext3. The fsck tool for ext3 actually works as a result of having been developed and extensively tested as part of ext2. That I haven’t actually had to use fsck (other than as part of pre-deployment testing) is testimony to the robustness of the on-disk structures used in ext3.
Same hardware, all server grade components (because they actually are servers, used for Computer Science at a University), with ReiserFS losing data left right and centre, and ext3 delivering almost the same performance without a hiccup. The choice is pretty damned clear, no?
Signed; a non-cool, but old experienced big-iron admin.
October 15th, 2006 at 9:58
You have obviously no lost gigabytes of customer data for a couple of bad sectors.
Did you read the part about backups, and ReiserFS not having anything to do with bad hardware? If you have a bad disk, no filesystem is going to save you.
The fact that you’re talking about customer data and not talking about backups or RAID, and you’re expecting any filesystem to work around bad sectors, shows just how ignorant you are.
Filesystems should be designed so that when the hardware goes bad the impact is minimal.
And so they are. However, you can never account for the affect that this will have at any given time. If your filesystem writes at the time the machine goes then you’re trusting to luck. ext3 isn’t going to save you here, as I’ve seen a screwed ext3 partition under such circumstances. Fortunately, the partitions that went didn’t mean anything and I had a backup anyway.
With backups, RAID and a UPS power supply downtime would have been zero whatever the filesystem.
This is not the case with ReiserFS.
You’re going to have to elaborate because this means zilch. I suggest you re-read the blog post.
October 15th, 2006 at 10:16
I have lost terabytes of data because of ReiserFS, using server grade hardware and server grade storage.
On server grade storage? Errrm no you haven’t. I don’t think you run what you say you do.
Consider that other filing systems aren’t losing data when being run on the same dinky systems that blows away data when using ReiserFS
There is simply no evidence for this. If a system dies when a filesystem is performing a write operation then any filesystem you care to mention is at risk. I’ve had a few meaningless test systems with Reiser, ext3 and JFS partitions all get corrupted after couple of crashes that needed a manual reboot. Then again, I’ve seen ReiserFS come up with no problems after a manual reboot at times. Go figure.
I mean, are you hitting the power button on your (server grade!) machines every minute of the day?! Just what is happening that is putting your data at risk? This is what you need to solve, not the filesystem.
It checks the on-disk structure but has almost zero capability to recover any data whatsoever.
Wrong. There are methods for doing this.
That I haven’t actually had to use fsck (other than as part of pre-deployment testing) is testimony to the robustness of the on-disk structures used in ext3.
Wrong. After every 30 mounts, or after a reboot without a proper unmount, fsck will be automatically run. If you’re having the amount of crashes you say you are, even on ext3, then you will encounter it.
Same hardware, all server grade components (because they actually are servers, used for Computer Science at a University), with ReiserFS losing data left right and centre
Don’t believe you. It’s that simple.
The choice is pretty damned clear, no?
Yes, the choice is clear. Your employer should fire you.
Signed; a non-cool, but old experienced big-iron admin.
I’m sorry, but if you’re losing terabytes of important data when using a full RAID setup up, uninterrupted power supply and a full backup system (you said you were using server grade stuff, right?) then you need to be looking for an alternative career - because you’re no damn good. Either that or you’re one of those people telling porkies that the author of this post has been pointing out ;-).
October 15th, 2006 at 10:17
I run 20 servers with raiserFS v3 and we are very satisfied with the performance, but in our backup server with 1 TeraByte of disk we had a problem and we had to run reiserfsck it took 3 days to check the disk and we had to stop it because it would take 5 days to finish.
in another server with 250GB it took 6 hours to check the filesystem.
Now we use it for servers up to 300GB for servers with more disks we go with other FS. I hope reiserSF 4 can correct this, because the performance pays the risk in most cases.
October 15th, 2006 at 11:29
Wow, there’s a lot of goofy “sysadmins” here…
I’ve used Reiser on everything from tiny home boxes all the way up to big SANs. I’ve NEVER had problems that were caused by ReiserFS. I HAVE had problems with ext2 though more times than I care to remember.
All this garbage about filesystems providing ‘better’ abilities to read damaged sectors on disk is complete bollocks. The data is either there or it isn’t. “Lost terrabytes of customer data” - give me a break. You’re trying to convince us that you somehow created a terrabyte-sized storage system WITHOUT any sort of RAID? The previous poster is right - if you worked for me you’d be out on your butt so fast you wouldn’t know what had happened.
Reiser is fast. reiserfsck is fast too. reiserfsck WORKS and I have had it recover some pretty badly screwed up systems, things like messing with software RAID arrays and other things that aren’t particularly stable to begin with. To the poster saying that reiserfsck takes too long, have you ever tried e2fsck?!
October 15th, 2006 at 14:41
File system checks generally do take a long time, but it shouldn’t take that long. ext2 or ext3 checks really do take an eternity.
The only problem I have with Reiser filesystems is that they can take a while to mount.
Probably a sensible idea. XFS and JFS generally perform far better for larger partitions and larger files. Now that Suse are not using Reiser I’m surprised they’re not looking at these.
October 16th, 2006 at 2:12
Actually, there is a way to install Fedora/RedHat with your favourite FS. You have to pass boot options when you boot from the installation media. There are boot options such as “reiserfs”, “jfs” and “xfs” and when it reaches the partition setup screen, it lets you choose these filesystem types among the already available ones.
BTW I used reiserfs v3 on a Samba server I installed for a radio station some years ago and it’s still up and running. With a custom compiled kernel on a RedHat 6.2.
October 16th, 2006 at 20:06
Thanks, Uno. Thanks, Zoltán. Your comments and tips are very valuable.
In other news, I’ve been reading about resilience in file systems in the face of hardware failure… pretty interesting, ReiserFS has the policy that I like the most: do no harm. I would certainly trust it misison-critical data where other file systems wouldn’t cut it.
October 18th, 2006 at 19:42
Segedunum. Your mouth is moving, but your brain isn’t engaged. You wouldn’t be in a position to hire and fire, as people like you work for people like me. It’s clear from how you phrase your argument that you’re not experienced.
As clearly stated in my prior message, the repeated power-offs were during pre-deployment testing. Any faults and recovery procedures need to be discovered and designed to be standardised in the field prior to dependence on those systems.
IT data centres and services is not just about computers and gadgets. It has to fit into a business process where service level agreements and fallback strategies protect the company against incurred losses. In other words, I design systems that operate in the face of idiots like you screwing networks and SANs up.
I see that linux_blade_guy also has reading difficulties, as I never said anything about not using RAID or that filesystems can read damaged sectors.
October 18th, 2006 at 19:45
Segedunum. Your mouth is moving, but your brain isn’t engaged. You wouldn’t be in a position to hire and fire, as people like you work for people like me. It’s clear from how you phrase your argument that you’re not experienced.
As clearly stated in my prior message, the repeated power-offs were during pre-deployment testing. Any faults and recovery procedures need to be discovered and designed to be standardised in the field prior to dependence on those systems.
IT data centres and services is not just about computers and gadgets. It has to fit into a business process where service level agreements and fallback strategies protect the company against incurred losses. In other words, I design systems that operate in the face of idiots like you screwing networks and SANs up.
I see that linux_blade_guy also has reading difficulties, as I never said anything about not using RAID or that filesystems can read damaged sectors. Maybe it’s those stupid cool sunglasses getting in the way or something?