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.
LVM + EXT3 (Score:3, Interesting)
You can use LVM to change the size of the partition, and then use resize2fs to shrink it to fit the LVM
Google around, you'll find some good docs
Found here:https://www.redhat.com/archives/nahant-list/2007-March/msg00004.html
fsck
resize2fs (resize to smaller then needed)
lvm (resize to the size needed)
resize2fs (grow to fill LVM vol.)
Is Linux a hard requirement? (Score:5, Interesting)
If you can use something other than Linux, then ZFS is the winner. Take a look at the FreeBSD ZFS Quick Start [freebsd.org], particularly the examples. That's possibly the coolest filesystem demo I've ever seen.
As long as you're asking (Score:4, Interesting)
Why shrinkable? (Score:3, Interesting)
Why the shrinkable requirement? Are you expecting your saved videos to take *less* space over time? I can assure you that I've never felt the need to downgrade the drives in my media server, in fact it's nearing time to upgrade it again as I finish ripping my DVDs.
But what the heck do I know, I just use the filesystem that my OS installs by default, like 99.999% of the world.
Solution for servers, and data storage (Score:5, Interesting)
Just use EXT3 (Score:5, Interesting)
EXT3 works perfectly on my Myth box and is probably the best filesystem for use with an up to date installation. The reason it was previously not recommened with Myth is because it takes a long time to delete large files on EXT3, so if you delete a file whilst making a recording, you can get a drop-out. However, Myth backend now has an option for slow background deletion of large files; if you enable it, you won't have any problems. Given the amount of RAM on a typical modern media server, though, it's unlikely that a drop-out would occur - the system would just cache the recording ntil the hard drive became available.
I, too, have lost data with abrupt power loss on XFS. JFS doesn't auto-repair on startup with Ubuntu, so that's not a good option unless you want to manually run FSCK every time you have power outage. Any other filesystem isn't mainstream so is best avoided.
Re:ReiserFS is the data-killer (Score:5, Interesting)
Well, especially with filesystems we are in the your mileage may vary boat. We kicked ext3 out of our server room in favour of ReiserFS because we had constant problems with ext3 on several servers. Not data loss (we had with neither), but rebooting our servers (especially the development server) almost always required a fsck at boot and it always had to repair the FS. This meant several hours of down-time just because of a reboot (e.g. because we moved the server to a new UPS) which became unacceptable. No such problems with ReiserFS.
I think by now everyone has his horror stories to back either ext3's or ReiserFS's side so it's a kind of vi vs. emacs war by now, IMHO. I'm happily using ReiserFS and vi for almost a decade now ;-)
It's really a shame ZFS is not available on Linux (only via FUSE)... I am really impressed by its capabilities (have an OpenSolaris server).
Stop looking for Zebras... (Score:3, Interesting)
There's an old saying in the medical community about looking for Zebras when you should be looking for Horses. In their case it generally refers to the fact that common conditions are common and exotic conditions are rare. So when a patient walks into your office with a nasty cough, you should probably assume it's a cold or maybe the flu, rather than looking through all kinds of obscure diseases that might cause a cough exactly like the one the patient is describing.
In the context of this conversation, though, I'm going to adapt it to mean there's no reason that you shouldn't just use ext3 and be done with it. Seriously. There is a reason it's the default filesystem on virtually every modern Linux distribution, and I'm pretty sure that reason is not because the distribution maintainers all have an unreasonable grudge against Reiser, IBM, SGI, etc. I know it's not sexy, cool, and different just for the sake of being different, but it works, it works well, and it does everything you're asking for.
Re:To expand on that (Score:3, Interesting)
it is probably overkill in terms of management complexity,
Really? It's management simplicity is what I've found most appealing.
In any case unless you're running openSolaris it isn't an option
While it's license isn't GPL compatible (hence the Linux issue) it is with BSD. ZFS has been showing up in BSD variants.
Why the need for shrinkable? (Score:5, Interesting)
If you do have a good reason for needing a shrinkable filesystem, does it have to be online shrinkable? I know a lot of people shrink existing FAT or NTFS filesystems to install another operating system for dual-boot, but that's normally done offline, not while the filesystem in question is mounted. In such cases, although it's convenient to shrink in place, it's not necessary, especially since you really need to back up the contents of the filesystem first anyhow. (If the data isn't worth backing up in case of a problem with shrinking the FS, it's not worth keeping in the first place.)
Re:Yes, ZFS FTW; (Score:2, Interesting)
I admire your optimism. But if you watch threads like this one [opensolaris.org] and others that go back three years, I think you'll be disappointed. Sun's original story was "no one should ever need to shrink a pool". In the face of a *huge* number of responses to the effect that "yes, but in the real world you do", their response for a couple of years was "well then you just don't understand ZFS". Then when that didn't work they switched to "we've been working on it for years, we just want to get it right so be patient for another few years and in the mean time just keep buying more disks".
The folks at Sun are quite smart, but they're not infallible. My guess is that some early design decisions about ZFS made shrinking extremely hard, and they're having a hard time living that down given how much they crowed about ZFS being "the last word in filesystems". Eighteen months ago I was super-excited about ZFS since it just had one more feature to go before it fit my needs. Now I don't expect to ever see that feature, at least not before some better alternative comes along with equivalent features and a more Linux-friendly license (btrfs+lvm?).
ReiserFS wasn't backward compatible (Score:2, Interesting)
In the past, the reiserFS team didn't themselves consider that ReiserFS was a production tool. They made a poorly documented incompatible internal format change.
That meant that the new drivers could not handle the old filesystems.
Their solution? If you opened an old filesystem with the new driver, the old system was automatically and invisibly migrated to the new format, w/o asking or telling the user. Now, what could go wrong with this?
1. They did this even to filesystems opened read-only. This is a total violation of the contract between the SW and the user.
2. Now, that filesystem could no longer be read by the old drivers.
3. If the filesystem was physically read-only, like a CD-ROM, it could not be opened at all. Say bye-bye to your old backups.
When I saw this, I decided that I wanted nothing more to do with ReiserFS. ext3 is fine.
More broadly, why did SuSE ever make ReiserFS the standard? They need need to decide whether they're creating a production environment or a hackers' playground. The rule should be, if it's not necessary to change, then it's necessary not to change.
Re:ReiserFS is the data-killer (Score:1, Interesting)
That's funny... So far I had much more data corruption with Ext2/Ext3 (mostly Ext3) than ReiserFS, despite the fact what I managed 30 times as many ReiserFS'es than Ext's over a period of time about as long...
I did ran FSCK's on ReiserFS quite a few time though (shit happens) but never lost anything, unlike Ext3.
Re:I'll be hard... (Score:4, Interesting)
Re:I'll be hard... (Score:2, Interesting)
He really should be allowed to continue his work in a reasonably comfortable environment. If one day he achieves parole he will not be a burden on the tax payers if he can work and save his money. Further his work is important to the public and not just to Hans.
Another consideration is that people who push their minds too far in an effort to break new ground sometimes go off track and do things they would not otherwise have done.
Re:To expand on that (Score:3, Interesting)
Ext3 in my experience is just plain inferior to ReiserFS.
That's odd. My experience is just the opposite. I haven't done any stringent benchmarks or anything, but I have a couple of media directories on one computer that I rsync to another (so the contents should be identical). One computer is running ReiserFS and the other Ext3, though, and on the one running ReiserFS it takes around 5-10 seconds to list one of the directories when the caches are cold. The Ext3 computer does it in unnoticable time on cold caches.
Of course, the storage backing them isn't identical, but I think it should work to ReiserFS's advantage, since it is contained on normal 3.5" S-ATA disks in an LVM, while the Ext3 filesystem is on my laptop, which uses a 2.5" IDE disk.
It is worth noting that the disks aren't slow, because I used to have that filesystem using XFS instead, and at that time performance was a lot better. I did some basic benchmarking when I still had both filesystems alive simultaneously, with such elementary techniques as "time find /mnt", and found that XFS was more than an order of magnitude faster (I don't remember the exact results, though; it was a long time ago). The reason I switched was mainly to have something shrinkable before it got large enough that I couldn't switch filesystem again by adding enough capacity to be able to duplicate the filesystem.
I would actually have used Ext3 on it, had it had in-kernel support for online resizing. In my experience, Ext3 is just one of the best filesystems out there. The only major thing it lacks, in my mind, is indeed in-kernel support for online resizing.
Re:dump/restore is useless (Score:3, Interesting)
That's of course an option, along with xfs_freeze.
But somehow I think that someone who has planned so badly that they need to shrink a file system aren't going to have enough free space to do either.
Re:I'll be hard... (Score:2, Interesting)
The GPL is free as in Reiser.
Once you are in jail you have to stay there.