Slashdot Mirror
Best Shrinkable ReiserFS Replacement?
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.
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.
The O. J. Simpson filesystem!
Just because it CAN be done, doesn't mean it should!
... to find a new killer filesystem, you insensitive clod!
My fastest way of checking what operations can be supported on filesystems at the present is by checking what gparted can do. Of the filesystems it works with right now, only four (jfs, reiser4, ufs, xfs) can't be shrunk using gparted.
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.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
ls wife /dev/hills/body
ls -A wife
ls -A body
ls -A body
sudo ls -A body
Password:
Ok ok,
\u262D = \u5350
Ugh, ReiserFS and "good recovery when the file system is not closed properly"? It doesn't even have good recovery after a proper shutdown.
When other filesystems die, the damage is localised. When Reiser fucks up, all or nearly all of the tree is lost. Usually, you'll lose all files bigger than 4KB, although other damage modes are possible.
Reiser has a codebase of an insane size. A relatively small piece of code can be mostly bug-free, Reiser is simply too large, complex and ill-tested. I admit, I haven't given it a try recently but you can guess why I hate the very idea of approaching it without a ten-foot pole.
I've seen XFS screw a number of random files, ext3 mangled only files that were being written to, and my personal favourite is JFS. Even though I use JFS most of the time, the only screwup I witnessed was on a RAID without a write-intent bitmap.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Don't fix it. Reiser3 is in the mainline kernel. Why bother messing with your working (and apparently robust) system?
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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... ;).
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Despite the parent trying to be funny, NTFS does support shrinking. I've used it to shrink a full disk partition down a bit to install a Linux one on the side.
(Now queue 'no room left for Windows on the drive' jokes)
ReiserFS is still being used and maintained in-kernel. It's Stable, and it just works for you and for hundreds of thousands of others; so, what's the rush?
I'd wait for the next batch of next gen FS (BTRFS, Tux3) to show their stuff -- and perhaps take a look at getting involved. Daniel Phillips has recently sent out a call for help... Sounds like you have an itch -- go scratch it.
The migration must be quick and dirty, but with as little mess as possible
You sounds just like my wife!
Wait, I don't have a wife. Nevermind.
Even worse, I really didn't consider the context before I started talking about wives. Oops.
which is totally what she said
JFS2 from IBM is the most solid filesystem I've ever seen, but I don't know if such a filesystem works with MythTV.
JFS2 works perfectly with MythTV.
I use JFS exclusively for my MythTV store, because it's the hands-down winner for deletion of large files (something that happens frequently with a MythTV box.)
Note that JFS doesn't support shrinking, so it's not an option for the submitter.
What? Anal rape jokes are in 'bad taste' now? When did that change? Nobody tells me anything...
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Filesystem was so big issue in my work that we bite the bulled and tried first Open Solaris and then switched into Nexenta http://www.nexenta.org/ Nexenta is OpenSolaris kernel GNU/Debian/Ubutntu userland. What this gets to you is ZFS and RAID-Z and RAID-Z2. When you get used to the fact that your filesystems has end to end quarantee of data integrity by hashing (even cryptographic hashing if you want, you feel uncomfortable with any other filesystem. In home I still run Linux on my laptop, but I made my own NAS that ruons with Nexenta.
Dyslexics have more fnu.
I don't know about GP, but anything involving anal tends to leave a bad taste in my mouth.
If something rock-solid is needed, one could do worse than continue to use ReiserFS3. (This is what I use.) It's feature-complete, and very stable. I have not had one mishap with it since I implemented it years ago.
But if you want something more bleeding-edge, one could try Reiser4 (development of which I think has stagnated) or btrfs, which seems to implement the main design considerations of Reiser4, but has jagged edges waiting to be cleaned up.
If something stable and under current maintenance is required, a conservative suggestion is of course Ext3.
The general problem with journaling filesystems recovery is not the data not being written (although in some very specific applications it can be required) as most serious apps like databases just fsync what they need on-disk. Problems arise when you have unprotected write cache.
This can happen on SCSI/SAS RAID cards when you force the write cache without a battery, but the most general cause is cheap hardware, especially IDE/SATA disks. For performance reasons they usually have the write cache enabled by default, and in many disks (possibly not many SATA's but this was common on IDE) you can't even disable the write cache (hdparm -W0).
With this kind of configuration, no matter what you do in term of journaling, you will *always* loose data when power fails during I/O operations.
On a side note, if you need data journaling you should probably use an external journal on a separate disk/array. This way the journal device will be doing synchronous writes which is much faster on standard disks.
I think you're doing it wrong...
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)
No, no, no.
Login: reiser
Password:
$ touch wife /dev/hills/body
touch: access denied
$ sudo touch wife
password:
touch: access denied
$ echo "wtf?"
wtf?
$ ps -aux | grep wife
wife 14589
$ sudo kill -9 14589
mv body
Some time later:
Login: cops
Password:
$ locate body /dev/hills/body
body not found
$ sudo usermod -g felon reiser
$ sudo updatedb
$ locate body
Good. Cheap. Fast. Pick Two.