Forgot your password?
typodupeerror
Data Storage

Best Shrinkable ReiserFS Replacement? 508

Posted by kdawson
from the just-in-case dept.
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.
This discussion has been archived. No new comments can be posted.

Best Shrinkable ReiserFS Replacement?

Comments Filter:
  • OJ FS (Score:5, Funny)

    by Frank T. Lofaro Jr. (142215) on Friday September 05, 2008 @12:20PM (#24889475) Homepage

    The O. J. Simpson filesystem!

    • Re:OJ FS (Score:5, Funny)

      by Anonymous Coward on Friday September 05, 2008 @02:30PM (#24891381)

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

  • by Anonymous Coward on Friday September 05, 2008 @12:20PM (#24889481)
    ... to find a new killer filesystem, you insensitive clod!
  • gentlemen (Score:2, Funny)

    by nimbius (983462)
    start your reiser jokes.

    my 2 cents...ext3.
  • by TheMidnight (1055796) on Friday September 05, 2008 @12:23PM (#24889521)

    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.

    • To expand on that (Score:5, Insightful)

      by Giant Electronic Bra (1229876) on Friday September 05, 2008 @12:37PM (#24889691)

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

      • by davidwr (791652) on Friday September 05, 2008 @12:43PM (#24889789) Homepage Journal

        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.

        • by dermoth666 (1019892) on Friday September 05, 2008 @01:29PM (#24890469)

          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.

      • Re:To expand on that (Score:5, Informative)

        by GrumpyOldMan (140072) on Friday September 05, 2008 @01:10PM (#24890155)

        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.

        • The critical factor being CPU overhead. Fuse based file systems are nice and you can solve a lot of problems with them, and they certainly can exhibit good throughput but the situation with an HTPC is that generally you have limited CPU resources and you definitely have significant CPU demands in most cases.

          The best case scenario is you have hardware MPEG decoding and all you're doing is watching a stream that is already on disk. In that case you're probably fine with most anything, and even antique machine

      • Re: (Score:3, Interesting)

        by khb (266593)

        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.

        • Yeah, but... (Score:5, Insightful)

          by Giant Electronic Bra (1229876) on Friday September 05, 2008 @02:12PM (#24891105)

          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:To expand on that (Score:4, Informative)

        by tzot (834456) <antislsh@medbar.gr> on Friday September 05, 2008 @01:30PM (#24890497) Homepage

        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.

      • Re:To expand on that (Score:4, Informative)

        by NekoXP (67564) on Friday September 05, 2008 @02:08PM (#24891027) Homepage

        ZFS isn't available on Linux

        Bollocks.

        ZFS-FUSE works fine. If you can build a kernel with an initrd which loads FUSE, ZFS-FUSE and mounts the root filesystem, you have absolutely no troubles whatsoever and absolutely acceptable performance for a MythTV box and a couple of servers. And if you managed to set up MythTV over ReiserFS then this isn't going to be a problem for you at all.

        The fact that it's in userspace is not a barrier to entry and nor is it "not available" just because it's not a kernel module.

      • Re: (Score:3, Informative)

        by BobPaul (710574) *

        you'll just have to live without the shrink functionality...

        Ext3 is shrinkable, just not when the file system is mounted. One can, however, grow the file system even while it's mounted.

        Please see man resize2fs

      • but for the type of application discussed here it is probably overkill in terms of management complexity, etc.

        In ZFS, here is how you format a disk device called /dev/ad10, mount it to /storage, and have it automatically mount itself on startup:

        zpool create storage /dev/ad10

        In linux here's how you format a disk called /dev/sdb, mount it to /storage, and have it automatically mount itself on startup:

        fdisk /dev/sdb
        n
        p
        (more fdisk commands etc)
        mke2fs -j /dev/sdb1
        mkdir /storage
        mount /dev/sdb1 /storage
        echo "/dev/sdb1 /storage ext3 defaults 0 2" > /etc/fstab

        On my FreeBSD box ZFS is probably the easiest and most int

      • Re: (Score:3, Interesting)

        by Dolda2000 (759023)

        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 identic

    • by Anonymous Coward on Friday September 05, 2008 @12:40PM (#24889753)

      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.

  • by Ethanol-fueled (1125189) * on Friday September 05, 2008 @12:25PM (#24889539) Homepage Journal
    However you handle your FS migration, special care must be taken to divide the task at hand into small manageable chunks. The migration must be quick and dirty, but with as little mess as possible. Most importantly, be honest with your customers -- they will decide your business' fate. Don't treat them like idiots just because they didn't design a FS.
  • There really aren't that many filesystems around that meet your criteria. The only one I'm aware of acutally is Ext3 and IIRC that only supports offline shrinking. Other alternatives would be VxFS, Ext4 and maybe BTRFS, but I'm not too sure about their kernel integration.

    • by lewiscr (3314) on Friday September 05, 2008 @01:48PM (#24890733) Homepage

      VxFS includes a kernel module. You can't boot off it (no grub support), and it's installed after installation, so it can't be your root FS. It can be any other mount point. I generally use it for my MySQL and PostgreSQL data partitions. I would use it for /home if I had to deal with users.

      VxFS by itself doesn't support all of those features (moving from stripe to concat, changing stripe width etc). Some of those come from VxVM (Veritas Volume Manager), which is well enough integrated with VxFS that I can resize a logical volume and filesystem with a single command.

      VxFS is the only FS that I've used that can be resized while mounted. Actually, it must be resized while mounted. I've expanded and shrunk filesystems many times while MySQL was under load. It increases the disk I/O a bit, so MySQL runs a bit slower, but otherwise there was no impact.

      Not only that, I've had a machine reboot (my fault) in the middle of a complex operation (restrip the RAID0 portions of the RAID 0+1 array in preparation to convert to a RAID 1+0). VxVM and VxFS mounted the volume fine, MySQL started serving, then VxVM picked up where it left off and completed successfully. No data lost.

      In addition, a dirty 100G+ volume takes about 15 seconds to fsck. Suck that ext3.

      On any server that can wake me up in the middle of the night, I'll gladly pay for the Veritas Foundation Suite.

  • shrinkable? (Score:5, Informative)

    by gardyloo (512791) on Friday September 05, 2008 @12:26PM (#24889565)

    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.

  • by cephalien (529516) <benjaminlungerNO@SPAMgmail.com> on Friday September 05, 2008 @12:30PM (#24889605)

    NTFS on Vista?

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

    • Re:How about - (Score:5, Informative)

      by AndrewNeo (979708) on Friday September 05, 2008 @12:38PM (#24889713) Homepage
      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)
      • NTFS (Score:3, Informative)

        by rlp (11898)

        I use WinXP (w. NTFS) for a PVR app. It works ... BUT I have a serious problem with fragmentation. Very noticeable during video playback. I added a scheduled task to defrag once a week (along w. a weekly reboot). I also need to make sure that I never fill the drive too full.

    • Re: (Score:3, Insightful)

      by blind biker (1066130)

      How is the parent offtopic? Funny perhaps (at least I thought it was funny) but definitely ON topic of shrinkable filesystems.

  • by UnknowingFool (672806) on Friday September 05, 2008 @12:31PM (#24889611)
    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.
    • by Rich0 (548339) on Friday September 05, 2008 @12:41PM (#24889763) Homepage

      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.

  • LVM + EXT3 (Score:3, Interesting)

    by xgr3gx (1068984) on Friday September 05, 2008 @12:31PM (#24889613) Homepage Journal
    I would use LVM and EXT3.
    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.)
  • Why switch? (Score:5, Insightful)

    by donscarletti (569232) on Friday September 05, 2008 @12:32PM (#24889639)

    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.

    • Re:Why switch? (Score:4, Insightful)

      by corbettw (214229) <`moc.oohay' `ta' `wttebroc'> on Friday September 05, 2008 @12:44PM (#24889797) Journal

      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: (Score:3, Insightful)

        by LWATCDR (28044)

        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: (Score:3, Insightful)

        by mlwmohawk (801821)

        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 t

      • Re:Why switch? (Score:5, Insightful)

        by Punto (100573) <puntob@ g m a i l . c om> on Friday September 05, 2008 @01:34PM (#24890553) Homepage

        This might be fine for a hobbyist

        The guy is building a computer to watch tv.

    • Re: (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 probabili

  • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Friday September 05, 2008 @12:32PM (#24889645) Homepage Journal

    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.

  • Ext3? (Score:5, Informative)

    by Conception (212279) on Friday September 05, 2008 @12:33PM (#24889647)

    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.

  • by overshoot (39700) on Friday September 05, 2008 @12:33PM (#24889653)
    ... I'm much more interested in a cache filesystem that will use local storage as a cache for network storage. Our corporate computing is horribly bottlenecked at the NAS while we have hundreds of gigabytes on every server and workstation sitting unused.
  • by KiloByte (825081) on Friday September 05, 2008 @12:36PM (#24889681)

    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.

    • by DarkDust (239124) <marc@darkdust.net> on Friday September 05, 2008 @01:02PM (#24890047) Homepage

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

      • Re: (Score:3, Informative)

        by nabsltd (1313397)

        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.

        The ext3 filesystem has settings that make it force an fsck on boot after N mounts or M days. This is likely what you were running into.

        You can use tune2fs to disable these checks completely if you want, but it's not advised. Unless your filesystem is very, very large or you have very, very slow disk drives, this check should never take "several hours". On the other hand, if it was finding errors, then perhaps you should be looking at what might have been causing those errors (usually hardware issues, al

    • Re: (Score:3, Insightful)

      by Yokaze (70883)

      > Reiser has a codebase of an insane

      wc -l says otherwise (2.6.25.9):

      xfs 92006
      jfs 29597
      reiserfs 27941
      ext3 16078

  • by sconeu (64226) on Friday September 05, 2008 @12:36PM (#24889683) Homepage Journal

    Don't fix it. Reiser3 is in the mainline kernel. Why bother messing with your working (and apparently robust) system?

  • Stay Put (Score:5, Informative)

    by m6ack (922653) on Friday September 05, 2008 @12:39PM (#24889733)

    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.

  • MythTV? (Score:3, Informative)

    by Awptimus Prime (695459) on Friday September 05, 2008 @12:41PM (#24889765)

    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.

    Okay, you need to consider a couple of things. First off, this is MythTV. Your concept of "large files" and the normal industry use of "large files" are entirely two different things. I really doubt you are going to exceed any limitations of a modern filesystem with porn, dvds, and television recordings.

    Second, you aren't going to lose data from a power outage when it comes to archived data you are reading (divx file, for example) when the power goes out. But no file system using system memory for a cache is going to play well when abruptly having the power yanked while it's writing.

    Third, just use ext3. It's one of the most used, reliable, and proven file systems to date. If it's not enough, you are better off using a UPS and software raid5 an array a few similar sized drives, with a ext3 file system.

    Let's please filter further headlines where people are asking about what exotic filesystem they should be trying out for non-raid applications. PLEASE.

    • Re:MythTV? (Score:5, Informative)

      by GrumpyOldMan (140072) on Friday September 05, 2008 @01:03PM (#24890053)

      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.

      • Re: (Score:3, Informative)

        by hacker (14635)
        ...which is why XFS makes sense here, and always has. Deleting a 1GB or 1TB file takes the same amount of time... under 1 second.
  • FAT32 (Score:5, Funny)

    by mrkitty (584915) on Friday September 05, 2008 @12:43PM (#24889783) Homepage
    If it wasn't that great then why do most thumb drives use it? :)
    • Re: (Score:3, Informative)

      by raijinsetsu (1148625)
      There's absolutely no disaster recovery on FAT32. It has no protections from bit errors, and has no native method of defining permissions.
      It's used on thumb drives because A) it has very little meta data that needs to be written to the drive in addition to the data (meaning: you can unplug faster), and B) it works on every OS.
  • Why shrinkable? (Score:3, Interesting)

    by Blakey Rat (99501) on Friday September 05, 2008 @12:44PM (#24889799)

    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.

  • by notany (528696) on Friday September 05, 2008 @12:58PM (#24889979) Journal
    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.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.
  • Just use EXT3 (Score:5, Interesting)

    by jonnyj (1011131) on Friday September 05, 2008 @12:59PM (#24889997)

    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.

  • by Hunterdvs (461524) on Friday September 05, 2008 @12:59PM (#24890001) Homepage

    Why don't we just rename ReiserFS. It seems the problem everyone has with it is that Hans killed his wife, the technology is still fine. What about KillerFS?

  • by drew (2081) on Friday September 05, 2008 @01:15PM (#24890233) Homepage

    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.

  • XFS for Myth TV (Score:3, Informative)

    by AaronW (33736) on Friday September 05, 2008 @01:16PM (#24890251) Homepage
    I have migrated most of my ReiserFS partitions to either XFS or EXT3. For something like MythTV XFS is probably the better choice since it excels at large files. My experience with Reiser is that it tended to suck for large files, especially writes. I also love the XFS tools, like being able to defragment a mounted filesystem and xfsdump.

    EXT3 has also made huge strides, especially with the directory hashing feature. I do not like how long fsck takes after so many mounts, though, or for recovery.

    Also, regardless of filesystem, set the noatime and nodiratime parameters in fstab to see another big performance boost.
  • by Eric Smith (4379) * <eric@AAAbrouhaha.com minus threevowels> on Friday September 05, 2008 @01:19PM (#24890285) Homepage Journal
    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.)

  • Some facts (Score:3, Informative)

    by ledow (319597) on Friday September 05, 2008 @01:19PM (#24890295) Homepage

    First, I don't understand the need for a shrinkable filesystem at all (I've only ever grown filesystems in my time as a systems administrator, and then it was just easier to move the whole thing to another drive rather than mess about - that's a rule that's held since the dark days of DOS and 20Mb harddrives, although there was a program called FIPS that could do amazing things with partitions for the time). I've never seen partitions or drives that ever needed to get smaller and the only thing that indicates is that you can't afford a larger hard drive and you've hit capacity and you don't want to delete those Windows games...

    Second, if you're getting lost+found files on anything journalled, it's because you've not got "full" journalling switched on, you've not got the latest kernel, or you've hit an unusual bug. The first is most likely because you're probably running on a "middle-ground" option, like ext3 also has by default, which says "favour speed over safety". The reason for this will become clear the instant you run a "full" journalling system. It's incredibly slow to write, because everything gets written twice effectively. The "slow deletion using ext3" on MythTV things are a thing of the past - a thread does it in the background now and you never know it's happening.

    Third, I don't see why the filesystem is that critical for, of all things, a MythTV box. It's hardly vital stuff we're talking about here. If you are THAT worried, you'd have a UPS on the thing and backups, or net-backup to a proper storage PC. You're obviously not. Thus, use whatever's available and if and when you decide on a replacment filesystem because something a) isn't supported, b) isn't suitable or c) disappears from the Linux kernel, then you can... shock, horror, copy the data to a new partition with a new filesystem on it then.

    Fourth, if you are really that geeky that you can't have Reiser now because it's no longer fashionable (which is what it sounds like more than anything else, and you've come up with the "shrinkable" thing to try to bolster that position), then why not have a RAID (battery backed if you don't want to lose data, remember!). Or why not put DATA seperate to OS in different partitions, have a read-only OS partition (it's MythTV, you could boot it from a CD) and then the worst that will happen is you will lose the current-written file on the Data partition(which might be that program you wanted to record, but better than trashing the system).

  • by sportster (711011) on Friday September 05, 2008 @01:53PM (#24890797)
    Did you read the documentation? From http://www.mythtv.org/docs/mythtv-HOWTO-3.html#ss3.1 [mythtv.org]
    Filesystems
    MythTV creates large files, many in excess of 4GB. You must use a 64 or 128 bit filesystem. These will allow you to create large files. Filesystems known to have problems with large files are FAT (all versions), and ReiserFS (versions 3 and 4). Because MythTV creates very large files, a filesystem that does well at deleting large files is important. Numerous benchmarks show that XFS and JFS do very well at this task. You are strongly encouraged to consider one of these for your MythTV filesystem. JFS is the absolute best at deletion, so you may want to try it if XFS gives you problems. MythTV .21 incorporates a "slow delete" feature, which progressively shrinks the file rather than attempting to delete it all at once, so if you're more comfortable with a filesystem such as ext3 (whose delete performance for large files isn't that good) you may use it rather than one of the known-good high-performance file systems. There are other ramifications to using XFS and JFS - neither offer the opportunity to shrink a filesystem; they may only be expanded. NOTE: You must not use ReiserFS v3 for your recordings. You will get corrupted recordings if you do.
  • by voxel (70407) on Friday September 05, 2008 @08:54PM (#24896529)

    Try this, it should be good for what you need:

    http://en.wikipedia.org/wiki/Fat16 [wikipedia.org]

    If it doesn't support all your needs, then nothing will.

    Oh also, 640k of ram is enough for anybody.

Save the whales. Collect the whole set.

Working...