Best Shrinkable ReiserFS Replacement? 508
paulkoan writes "I have been using ReiserFS for my file system across a few servers for some time now (follow the link below for details of my experience). I can't foresee the future of ReiserFS, but if I'm going to have to migrate as support diminishes, I'd like to begin that process now. My criteria are: in-kernel support, shrinkable, and has good recovery when the file system is not closed properly. That shrinkable requirement precludes a lot of options. What's a good replacement for ReiserFS?"
I initially chose ReiserFS because I was building a MythTV system and it was the recommended FS across the board, from small to large files. I've had good experiences with ReiserFS and it has had a pummeling. That MythTV box for example has a very volatile environment and loses power on a regular basis. I haven't lost any data through any of these outages.
Compare this to my brief foray into XFS on the same box, where 25% of the filesystem ended up in lost+found with numbers for filenames. When this happened a second time on a different system I decided XFS wasn't for me — and I really don't get the point of a journalled filesystem that will keep data relatively safe, but then remove any means to identify it when things go wrong.
But everyone has good and bad experiences with filesystems, ReiserFS included. XFS has a good rep, my experience aside.
Why switch? (Score:5, Insightful)
ReiserFS works. It is merged with the mainline kernel trunk so it will be able to secure enough man power to at least avoid bit-rot and incompatibility to future kernel versions. You don't have to worry about suddenly losing your files now Hans isn't involved in the project, some kernel modules have gone for years without an update and still work. I doubt that this will even become one of them since so many people are using this file system and lets face it, it is a good file system nomatter who wrote it (lets not forget he was a known arsehole before he killed his wife and it didn't matter then).
The worst thing that could happen is ReiserFS slowly falling into disuse and becoming deprecated in three or four years, you will have plenty of time to worry about this later, just take a deep breath and put down your file system tools, this will all be OK.
If it ain't broke.... (Score:5, Insightful)
Don't fix it. Reiser3 is in the mainline kernel. Why bother messing with your working (and apparently robust) system?
To expand on that (Score:5, Insightful)
ZFS isn't available on Linux. It is a great enterprise class file system, but for the type of application discussed here it is probably overkill in terms of management complexity, etc. Not that it would be bad or wrong to use, and you could benefit from some of the features of course, but it really shines in demanding environments. In any case unless you're running openSolaris it isn't an option.
Ext3 in my experience is just plain inferior to ReiserFS. Recovery and formatting are both slow as death. Like the OP I have yet to suffer any data loss on a ReiserFS since way back in the early days when it first came out. Ext3 seems pretty reliable as well, but the slow recovery times are annoying and once in a while it seems like a whole filesystem just plain becomes irretrievably corrupted. OTOH it does demand less CPU overhead. Rarely a BIG issue, but can be with HTPC type systems.
Overall though I don't think you have a lot of choice. XFS or JFS might be perfectly good solutions, not really had a need to mess with either of them myself so I can't comment. Obviously ReiserFS looks like it has about reached the end and that pretty much leaves Ext3 as the only man left standing in the ring at this point. Cheer up, it works well enough, you'll just have to live without the shrink functionality... ;).
Fork it (Score:1, Insightful)
Re:I can only speak for myself (Score:5, Insightful)
I would stick with ext3 - it is really the only option that meets your needs (which is why I'm using it as well). Note that I'd avoid using LVM - there is some kind of bug in some versions of LVM that causes massive data loss in some very rare circumstances. I recently lost a few hundred GB of data on a RAID due to this issue. (Google for "access beyond end of device lvm".) Ran fsck to clean up some errors after a crash while in RAID recovery mode and suddenly I had massive data loss on an entirely different lvm logical volume - it was obvious that the fsck somehow crossed the logical volume boundaries which should not be possible.
In the end I ended up restoring critical data from backups (which did not include mythtv recordings), and watched what remained of my recordings (complete with 10 second patches of video jumping between shows). I had to completely wipe out everything on the raid and start over. I no longer run lvm - I used to swear by it but it will be a while before I go back to it. My few non-lvm partitions (root, boot) had no issues at all even though they were subject to the same treatment.
Re:How about - (Score:3, Insightful)
How is the parent offtopic? Funny perhaps (at least I thought it was funny) but definitely ON topic of shrinkable filesystems.
Re:Why switch? (Score:4, Insightful)
The worst thing that could happen is ReiserFS slowly falling into disuse and becoming deprecated in three or four years, you will have plenty of time to worry about this later, just take a deep breath and put down your file system tools, this will all be OK.
There are two problems with this:
1: That's not the worst case scenario. The worst case scenario is someone discovers a critical flaw in the filesystem that suddenly puts your data at risk. Yes, I know, this isn't likely with filesystems, but it is at least theoretically possible. Which makes it the "worst case".
2: You're proposing a reactive method of systems administration. This might be fine for a hobbyist who doesn't care about his system(s), but for a production environment this is playing with fire. You know that support for ReiserFS will disappear (unless you know for a fact that another person/group has stepped up to provide support); why wait until the last possible second, when you'll only have more work to do, to migrate your systems to a new filesystem? Don't put off to tomorrow that which can be done today.
Re:Why switch? (Score:3, Insightful)
I do agree with your points but.
This guy was using ReiserFS on his MythTV box. He may or may not be using it on other Linux boxes but that was not clear.
Sounds to me like this is a hobbyist.
Re:Why switch? (Score:3, Insightful)
2: You're proposing a reactive method of systems administration. This might be fine for a hobbyist who doesn't care about his system(s), but for a production environment this is playing with fire. You know that support for ReiserFS will disappear (unless you know for a fact that another person/group has stepped up to provide support); why wait until the last possible second, when you'll only have more work to do, to migrate your systems to a new filesystem? Don't put off to tomorrow that which can be done today.
The point I think you miss is the useful lifetime of a disk and system. Lets say he uses ReiserFS on his disks on a brand-new computer.
Addressing your first problem: critical flaw, the probability I'd bet is fairly equal across the board. So your choice of file system neither increases nor decrease (significantly) your chance of a critical flaw. If it did, you would exclude that file system in general.
Second, a "file system" is not necessarily an integral component of the technology. Its just a generic storage mechanism, you can copy data from one file system to another and as long as the copying process did not fail, your data is still usable.
If ReiserFS becomes a problem in a couple years, its time for a system upgrade anyway, so just copy the files to your new computer (or hard disk) with a different file system.
Re:Try SGI's XFS! (Score:3, Insightful)
Re:Why switch? (Score:5, Insightful)
This might be fine for a hobbyist
The guy is building a computer to watch tv.
Keep using ReiserFS (Score:2, Insightful)
Is it broke? (Score:2, Insightful)
Re:I'll be hard... (Score:4, Insightful)
Am I missing something... Isn't one of the advantages of Open Source is the ability to maintain and improve a product no matter what happens to any particular person or company?
Perhaps the Open Source Community should have project safety rating for an open source project. Like a risk level. So say without the person the project is doomed to die. To fully supported so if any one comes or go the product will continue.
Yeah, but... (Score:5, Insightful)
Most people are using Linux for HTPC applications, BSD is a whole other kettle of fish...
I'm not saying ZFS is HARD to admin, just that a basic ext3 fs is nothing at all to admin. If you know ZFS, it is no big deal. For your average garden variety user they will never take advantage of the ZFS features anyway, so they'd be better of just going with ext3. There is a lot better chance their recovery tools support it, etc.
So, I'll agree with you, if the user happens to be sophisticated and using BSD, then go for ZFS, why not?
Re:ReiserFS is the data-killer (Score:3, Insightful)
> Reiser has a codebase of an insane
wc -l says otherwise (2.6.25.9):
Re:ZFS and Reiser development (Score:4, Insightful)
ReiserFS was a great filesystem. Certainly isn't a WORSE one now than it was before in and of itself. It is just a matter of ongoing support. Whatever the reason people are dropping support and inevitably an unmaintained file system is going to become at best a marginal legacy tool. Given that it isn't even a default supported Linux fs chances are it will be broken as of kernel X, and then you will be pretty much forced to migrate, so why bother with it?
As to WHY, that I have to assume is political, there was never anything technically wrong with it. In fact there was pretty much everything technically RIGHT about it... Reading between the lines my hunch would be
Re:Why switch? (Score:3, Insightful)
Sadly, something being in the mainline kernel is no guarantee of avoiding bit-rot. I've been maintaining an elaborately modified version of the Cyclades PC-300 driver for years for precisely that reason. The SMP startup code on sparc64 has a race condition involving a shared buffer for passing params into PROM calls [linux.no]; I know this has been in the current kernel for at least the past year, but I believe it can only occur even in principle on machines with at least three processors. In practice the probability of a conflict rises with the number of processors; I have only been able to demonstrate it using at least five, and the 12-CPU E4500 I originally encountered it on seems to have only a single-digit-percentage chance of booting without a patch to acquire prom_entry_lock at the appropriate point.
Now, it seems hard to imagine ReiserFS will decline to that level of obscurity any time soon, but it certainly is possible for code in the mainline kernel to stay broken for a long time.
Re:Why the need for shrinkable? (Score:4, Insightful)
I assume the "shrink" requirement is to preclude discussion of the most viable alternatives.
Re:On-topic:... (Score:4, Insightful)
Wouldn't leaving ReiserFS because it will supposedly become unsupported at some point in the future become self-fulfilling?
After all, who is going to fix it if nobody uses it? And like everything else, it will need to be fixed at some point.
If you find it to be a good filesystem, I say keep using it. If it is a good filesystem, someone will maintain it. If not, then it dies because it deserves to and not because of FUD.
dump/restore is useless (Score:3, Insightful)
...in many production environments except for emergencies. There's no way I can take a 3TB production filesystem offline to do a dump/restore (or even a restore) just to shrink a filesystem.
There are times we have to shrink one filesystem (volume, whatever) so we can grow another with the available space, without halting dozens of engineers for hours or a day. Lots of people have this same problem.
With something like a NetApp, I can grow and shrink a filesystem at will. Quick, simple, painless. I realize we are talking free software and commodoty or similar hardware vs several hundred thousand dollars worth of proprietary HW & SW, but the point is that it's doable, and there are reasons to do it.
We have NetApps for or tier 1 space, and they work great. We use Linux on Supermicros and Dells for tier 2, and desperately need easier disk management there.
Re:ZFS and Reiser development (Score:5, Insightful)
No, it was awful in production use. Any disk failure on a RAID set, as can be expected to occur in any large environment, would lead to a confused ReiserFS whose own recovery tools would destroy it and which could no longer be backed up reliably. This has happened with no other Linux compatible filesyste I've ever seen: the others simply report a failed access, they do not lock when trying to read the ruined files.
ReiserFS was only suitable for high-speed, random access, restorable via other means filesystems such as NNTP servers and web proxies. For root partitions, boot partitions, and home directories, it was unstable and dangerous to use.
Re:On-topic:... (Score:4, Insightful)
If you find it to be a good filesystem, I say keep using it. If it is a good filesystem, someone will maintain it. If not, then it dies because it deserves to and not because of FUD.
.
Hope is not a plan.
It is reasonable to wary of any project so uniquely identified with a single individual.
But a filing system? How many developers have the freedom and the confidence to take on something so elemental?
Re:I'll be hard... (Score:4, Insightful)
Prison isn't about getting to do the things you love with free room and board.
Nor is it about harming society by preventing criminals from making meaningful contributions, just to spite them.