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.

46 of 508 comments (clear)

  1. OJ FS by Frank+T.+Lofaro+Jr. · · Score: 5, Funny

    The O. J. Simpson filesystem!

    --
    Just because it CAN be done, doesn't mean it should!
    1. Re:OJ FS by Anonymous Coward · · Score: 5, Funny

      But ReiserFs is the only one being ported to cell...

  2. I'll be hard... by Anonymous Coward · · Score: 5, Funny

    ... to find a new killer filesystem, you insensitive clod!

    1. Re:I'll be hard... by Anonymous Coward · · Score: 5, Funny

      I have a simple and elegant solution to two problems that I perceive have arisen from the conviction of Mr Reiser, said problems being:

      a) absence of a project manager for the ReiserFS project and
      b) an overabundance of 'killer filesystem' jokes.

      What I propose is this: the next person to make a 'killer filesystem' or similar joke will be horsewhipped in the town square and then assigned responsibility for ReiserFS for the rest of his (or her) life. Any developmental milestones which have been assigned but are not complete by the deadline will result in further horsewhipping.

      I have forwarded this action plan to the relevant authorities and am currently awaiting approval. Please show your support by buying a T-shirt or coffee mug.

      Thanks for your time.

    2. Re:I'll be hard... by xanadu113 · · Score: 4, Funny

      Put them on the development team?

      --
      -Myke
    3. Re:I'll be hard... by tzot · · Score: 4, Funny

      OK, I get it. There's software free as in beer, free as in speech, free as in jazz and free as in Reiser.

      --
      I speak England very best
  3. Some general thoughts by TheMidnight · · Score: 4, Informative

    I've heard good things about ZFS from Sun Microsystems, though I don't have much experience with it. Ext3 seems to have decent crash recovery though it requires fscks almost every time. JFS2 from IBM is the most solid filesystem I've ever seen, but I don't know if such a filesystem works with MythTV.

    1. Re:Some general thoughts by Anonymous Coward · · Score: 5, Informative

      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.

  4. shrinkable? by gardyloo · · Score: 5, Informative

    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.

  5. How about - by cephalien · · Score: 4, Funny

    NTFS on Vista?

    I hear your disk space shrinks like nobody's business.

    --
    If firefighters fight fire, and crimefighters fight crime, what do freedom fighters fight? - George Carlin
    1. Re:How about - by AndrewNeo · · Score: 5, Informative

      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)

  6. I can only speak for myself by UnknowingFool · · Score: 4, Informative

    For my MythTV installation, I choose ext3 for the system partitions like / and /usr and xfs for my /video partition. My system partitions are on a RAID 1 while my /video partition is a 1TB RAID 10 LVM. ext3 is more than adequate for my purposes and it does a decent job of recovery. Earlier this year my server started crashing intermittently with no messages in the error logs. I finally traced it to a bad stick of RAM and ext3 recovered in most of the cases. In one case I had to repair mysql databases, but that was the only hiccup.

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
    1. Re:I can only speak for myself by Rich0 · · Score: 4, 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.

  7. Why switch? by donscarletti · · 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.

    --
    When Argumentum ad Hominem falls short, try Argumentum ad Matrem
    1. Re:Why switch? by Punto · · Score: 4, Insightful

      This might be fine for a hobbyist

      The guy is building a computer to watch tv.

      --

      --
      Stay tuned for some shock and awe coming right up after this messages!

  8. Is Linux a hard requirement? by Just+Some+Guy · · Score: 4, Interesting

    If you can use something other than Linux, then ZFS is the winner. Take a look at the FreeBSD ZFS Quick Start, particularly the examples. That's possibly the coolest filesystem demo I've ever seen.

    --
    Dewey, what part of this looks like authorities should be involved?
  9. Ext3? by Conception · · Score: 4, Informative

    Ext3 with LVM seems to be the popular way to go about this. Unless you really want an esoteric solution, from your requirements I don't see a reason to stray from the norm.

  10. Re:gentlemen by Arthur+B. · · Score: 5, Funny

    ls wife
    ls -A wife
    ls -A body
    ls -A body
    sudo ls -A body
    Password:
    Ok ok, /dev/hills/body

    --
    \u262D = \u5350
  11. ReiserFS is the data-killer by KiloByte · · Score: 5, Informative

    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.
    1. Re:ReiserFS is the data-killer by DarkDust · · Score: 4, 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).

  12. If it ain't broke.... by sconeu · · Score: 5, Insightful

    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.
  13. To expand on that by Giant+Electronic+Bra · · 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... ;).

    --
    "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
    1. Re:To expand on that by GrumpyOldMan · · Score: 4, Informative

      ZFS isn't available on Linux.

      ZFS is available on Linux, via Fuse. This gives a heavy performance penalty over a native implementation(*), but it would probably be fast enough for MythTV. However, ZFS is not shrinkable, so it doesn't meet the original poster's requirements.

      (*)For a raidZ 3-disk array of WD "green" 750GB Sata drives (WD7500AACS-00ZJB0), I see 80MB/s sequential write, and 144MB/s sequential read for a native ZFS implementation on FreeBSD/amd64 7.0. For the same setup, I saw 25MB/s write and 95MB/s read from ZFS via fuse.

    2. Re:To expand on that by tzot · · Score: 4, Informative

      XFS or JFS might be perfectly good solutions

      One should never, ever use XFS on a non-UPS-protected system. It's a great filesystem, but if you don't get the time for a sync of the in-memory structures, you're screwed.

      --
      I speak England very best
  14. Stay Put by m6ack · · Score: 5, Informative

    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.

  15. Re:FS migration a la Reiser by somersault · · Score: 5, Funny

    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
  16. FAT32 by mrkitty · · Score: 4, Funny

    If it wasn't that great then why do most thumb drives use it? :)

    --
    Believe me, if I started murdering people, there would be none of you left.
  17. ext3 with data journaling by davidwr · · Score: 4, Informative

    Performance may crawl to a standstill but ext3 with full journaling of data not just meta-data should make crash-recovery nearly bulletproof.

    Another option is to reduce the number of crashes:
    Make sure your software and hardware are stable and use a good, stable battery-backed power supply.

    The latter is good advice for any system.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:ext3 with data journaling by dermoth666 · · Score: 5, Informative

      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.

  18. ext2/3 can be shrunk offline by davidwr · · Score: 4, Informative

    I'm not sure if gparted can do it yet, but you can shrink and grow ext2/3 partitions at the command line using a combination of tools.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  19. Re:Try Reiser's new filesystem by spun · · Score: 5, Funny

    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
  20. Solution for servers, and data storage by notany · · Score: 5, Interesting

    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.
  21. Just use EXT3 by jonnyj · · Score: 4, 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.

  22. Re:MythTV? by GrumpyOldMan · · Score: 4, Informative

    He's concerned about "large files" because ext3 takes eons (10 to 20 seconds) to delete large (8GB/hr) files generated by recording HDTV. This used to be important on MythTV, because deletions were synchronous. So using ext2 in combination with HDTV on MythTV meant a 10 to 20 second "freeze" when manually deleting something, or missing 10-20 seconds of a new recording while an auto-expire deleted an old show.

    In newer versions of MythTV, deletions are done by a separate thread, so there should be no concerns about using ext2/ext3.

  23. Re:Try Reiser's new filesystem by Anonymous Coward · · Score: 5, Funny

    I don't know about GP, but anything involving anal tends to leave a bad taste in my mouth.

  24. Why the need for shrinkable? by Eric+Smith · · Score: 4, Interesting
    I'm sure this is an extremely dumb question, but why do you need a shrinkable filesystem? I've often wanted to grow filesystems, but in 24 years of using Unix and Unix-like systems as a software developer and system administrator, I've never once wanted to shrink a filesystem.

    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.)

  25. On-topic:... by BrokenHalo · · Score: 5, Informative

    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.

    1. Re:On-topic:... by mweather · · Score: 5, Funny

      That's not wise. Nina tried that and we all know how that turned out.

    2. Re:On-topic:... by mweather · · Score: 4, Funny

      I thought that project was dead.

    3. Re:On-topic:... by arth1 · · Score: 4, Informative

      reiserfs isn't feature complete, unless you mean "features that Hans Reiser wanted, but screw the rest". You can't use it for SELinux (without some ugly and known buggy patches), because it lacks compatible extended metadata facilities. NTFS compatible streams won't work either. There's no defragmentation possibility. And perhaps most of all, it has no dump/restore facility.

      I keep wondering why the OP wants the ability to shrink a file system. Could it be because he's thinking in ReiserFS terms, where there is no dump/restore, and thus is used to using shrink for that job? For file systems with dump/restore, one normally does a dump, recreates the FS in the desired size, then a restore. That has the advantage of the resulting file system being tuned to the new size, and unlike a regular backup/restore, will preserve any metadata, allocated extents, ACLs, sparse files, and everything else.

      Personally, I see a lack of dump/restore facilities as a much more serious handicap than lack of shrinking. Especially if you think forward, and consider that you're much more likely to replace drives with faster and bigger drives than you are to shrink them.

      I suggest XFS, and let xfsdump/xfsrestore do the job of shrink/grow.

  26. Re:Try Reiser's new filesystem by NeoSkandranon · · Score: 5, Funny

    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)
  27. Re:gentlemen by DittoBox · · Score: 5, Funny

    No, no, no.

    Login: reiser
    Password:

    $ touch wife
    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 /dev/hills/body

    Some time later:
    Login: cops
    Password:

    $ locate body
    body not found
    $ sudo usermod -g felon reiser
    $ sudo updatedb
    $ locate body /dev/hills/body

    --
    Good. Cheap. Fast. Pick Two.
  28. Yeah, but... by Giant+Electronic+Bra · · Score: 4, 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?

    --
    "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
  29. Re:Difficult question by amRadioHed · · Score: 4, Informative

    VxFS is the only FS that I've used that can be resized while mounted

    What about ext3?

    --
    We hope your rules and wisdom choke you / Now we are one in everlasting peace
  30. Re:gentlemen by Bogtha · · Score: 4, Funny

    ls -A wife

    You won't find the mother of his children with that. ls -A skips listing parents (..). The police should have used ls -a instead.

    --
    Bogtha Bogtha Bogtha
  31. Re:ZFS and Reiser development by Antique+Geekmeister · · Score: 4, 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.