Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Data Storage

Cross-OS File System That Sucks Less? 449

An anonymous reader writes "I recently got an external hard disk with USB 2.0/Firewire/Firewire 800/eSATA to be used for backup and file exchange — my desktop runs Linux (with a Windows partition for games but no data worth saving), and the laptop is a MacBook Pro. So the question popped up: what kind of filesystem is best for this kind of situation? Is there a filesystem that works well under Linux, MacOS X, and Windows? Linux has HFS+ support but apparently doesn't support journaling and there's also an issue with the case-insensitivity of HFS+. Are we stuck with crummy VFAT forever or are there efforts underway to bring a modern filesystem (I'm thinking something like ZFS, BeFS, or XFS) to all platforms? Or are there other clever solutions like storing ISO images and loop-mounting those?"
This discussion has been archived. No new comments can be posted.

Cross-OS File System That Sucks Less?

Comments Filter:
  • FAT is it for now (Score:5, Interesting)

    by jonadab ( 583620 ) on Saturday July 28, 2007 @01:53PM (#20024399) Homepage Journal
    There are two "extensions" I would like to see for vfat, that could be implemented right on top in a reasonably backwards-compatible way (just as LFNs were on top of traditional FAT fs).

    The easier and more important one is symbolic links. (Indeed, it ought to be possible to devise a "virtual symlink" system that would work pretty much independent of the underlying filesystem, by simply using hidden pointer files containing the paths to the target files -- similar to .LNK files that the Windows GUI uses, but you'd want them to be supported by the OS at the filesystem layer, just like regular symlinks are on filesystems that have them; also you'd want the design of the pointer files themselves to be cleaner and more platform-agnostic.)

    The harder, but ultimately just as important, is journaling (similar to what ext3 does for ext2).

    The advantage of extending FAT32 in this way should be obvious: just like with ext2/3, systems that don't support the extension can at least still access the data (although doing so may invalidate the journal). So you don't *lose* any compatibility, you only *gain* the added features. In situations where you *mostly* use the disk with a particular system (e.g., my data drive that spends basically 100% of its time mounted in FreeBSD, but is FAT32 so I can get to my data from a non-BSD system in case of an unforseen emergency), you'd get a lot of benefit from the improved features. (I'd be particularly pleased to have symlinks on my data drive, for instance.) Then you only lose the new features if you need to mount the disk under a system that doesn't support them, e.g., if some piece of hardware on my FreeBSD workstation dies and I need to get my files, I could take the drive and hook it up to just about any computer anywhere and mount it as plain old FAT32 and my files would all be there.

    This still doesn't turn FAT into BeFS or ZFS or whatnot, but it would be a welcome improvement.
  • Re:Quick answer: No (Score:3, Interesting)

    by BKX ( 5066 ) on Saturday July 28, 2007 @02:35PM (#20024815) Journal
    You read that wrong. The last paragraph of the FAQ question clearly states that EXT2IFS cannot acceess an ext3 partition that's not cleanly unmounted and will operate on an ext3 partition as if it were ext2 just like old Linux kernels without ext3 support did.
  • by ancientt ( 569920 ) <ancientt@yahoo.com> on Saturday July 28, 2007 @02:47PM (#20024953) Homepage Journal

    Okay, I have to ask, have you or has anyone you know ever tried to run a Linux distro off of a NTFS system? I'm not sure why you'd want to but I'm curious as heck if it is possible.

  • The Full Story (Score:1, Interesting)

    by Anonymous Coward on Saturday July 28, 2007 @05:02PM (#20026121)
    I've delved into this very much lately. In my experience, this is how it stands.

    EXT2/3:
    Supported well in Linux, obviously.

    It has a Windows driver that only supports ext2 so far as I know. That means ext3 journaling won't work, but since ext3 is backwards-compatible with ext2 I think that it should mount an ext3 volume, but just without all of the features.

    There is a ext2 driver for MacOS X as well, but I've found it to be unstable. It causes my system to crash and hang a lot. I've personally uninstalled it. But this may be just due to Mac OSX Tiger. I am running the latest version of the MacOS, and according to the changelog write support under Tiger was only added in the last release. So if you are running Mac OS 10.3.x it might be more stable for you.

    NTFS:
    NTFS is obviously well-supported under Windows.

    Under Linux, the NTFS-3G driver works great. I'm using it on a Ubuntu 6.10 system and have had no problems. (granted, I haven't tried to mount this volume under OSX of Windows, so I don't know if there is any corruption that the NTFS-3G driver somehow hides, or understands that windows/mac drivers don't)

    Under MacOS X, I believe there is native support for NTFS that is read-only. There is however a Mac port of FUSE, called MacFUSE. It allows for the NTFS-3G driver on OSX. The ntfs-3g driver can also be installed through fink or macports (aka darwinports) according to the ntfs-3g website.

    HFS+:

    Under Linux, HFS+ support is good. The downside is that journaling is not supported, and the case-sensitive version of HFS+ is not supported... for writing. They will mount as read-only. (I had a rough time trying to figure out why my HFS+-formated iPod would only mount read-only... apparently it has journaling enabled when you Restore it through iTunes).

    Under Windows, HFS+ is supported through MacDrive... which is proprietary and you have to pay for. I have no clue on if it supported journaling, case-sensitivity, etc. I'm not currently running Windows so I haven't looked too deeply into it.

    Under MacOS X, obviously support is great.

    My Thoughts:
    Personally I have settled on HFS+ for sharing between OSX and Linux. Unfortunately many of the offerings to add filesystem support to OSX and Windows continue to be unstable. I don't have experience with the NTFS-3G driver which I have heard good things about, but part of the reason it might not fool with OSX too much is that it operates in user space with FUSE. I have never had problems with Linux crashing due to faulty filesystem support, so the 'uniting' factor continues to be support in Linux.

    The real issue is getting OSX and Windows to play nice on a filesystem. I would have to say the choice would be between HFS+ or NTFS. It's all dependent upon how stable NTFS-3G is on OSX or MacDrive is on Windows. Only other deciding factor would be if you don't want to pay for HFS+ support on Windows. But just between OSX and Linux, I like HFS+ because it will still support permissions (and they won't be mangled if you sync your users' uids and gids on all your systems).

    (posting anonymously due to work)

  • by quizzicus ( 891184 ) <johnbanderson@gm ... ENom minus berry> on Saturday July 28, 2007 @07:08PM (#20027091) Journal
    I run my whole system (except for C:/Windows, Windows won't boot from ext3) on ext3, and XP seems to run better than it did on NTFS (could it be the automatic defrag?). ext2ifs isn't perfect, though, and sometimes it breaks my backup runs until I fsck all the partitions that Windows uses. No data loss so far, so maybe it just doesn't dot its i's properly.
  • by Gordonjcp ( 186804 ) on Saturday July 28, 2007 @07:26PM (#20027225) Homepage
    And yet not only is NTFS is still one of the best FS for handing fragmentation, ever, it has a well managed and fast file table indexing system.

    Because it's more-or-less a straight lift of FILES-11. You may or may not believe this, but your NTFS is almost compatible with VMS disks. Sadly, it's a pale imitiation - although there is the facility for things like file versioning, it's non-functional and can probably never be properly implemented without significant refactoring.

    Pity, really. Windows nearly had something really good going for it there.
  • by Rick17JJ ( 744063 ) on Sunday July 29, 2007 @03:47AM (#20030179)

    I have an external USB hard drive and recently formatted the hard drive with two different partitions. The first partition is formatted as NTFS and the second is formatted as JFS. The NTFS partition is mainly for Windows, but can also be used for transferring files between Linux and Windows. The JFS partition is only for being used by Linux. When using Linux, I can now make backup copies of stuff from my main Linux partitions onto the exteral drive's JFS partition using the rsync command. Perhaps I am being too paranoid, but I did not want Windows spyware or viruses to be able mess with what is backed up on that partition, so I deliberately chose something that Windows could not read. I use Kubuntu Linux and JFS is one of the several journaling file systems that it supports. I could have just as easily used some other Linux supported journaling file system such as EXT3 or ReiserFS, but for no special reason, I chose JFS. For the partition that Windows would use, I debated between NTFS and FAT32. I also toyed with the idea of formatting that partition as EXT2 and installing of of the several available open source drivers that would allow Windows XP to read EXT2. Linux is what I use 99% of the time and because it is my main operating system, I decided to make the JFS partition much larger and gave it 220 GB.

    I have two different computers and use a KVM switch so that they can be controlled by just one keyboard, monitor and mouse. The two computers are side by side and one runs Linux and the other runs Windows XP. Most of the time I just use the Linux computer, but once in a while I turn on the Windows computer too and with the KVM switch can jump back and fort between either in about a second or two. The Windows computer is a small book sized computer that only uses 23 Watts, so I can occasionally run both at once without using much more electricity. I play around with Windows XP now and then, so that I do not totally forget to use and maintain a Windows computer.

    I have the 250 GB hard drive in a NexStar GX external hard drive enclosure and it is connected to a manual 4-to-1 USB switch box. I then press the appropriate button on the manual USB Switch box to choose which computer the external hard drive is hooked to. For the first partion, I let Windows create the NTFS partion. I then used GParted running under Linux to create the JFS partition. By the way, I already had both the Ubuntu desktop package and the Kubuntu desktop package installed, so I was able to install GParted and run it under KDE, even though it is designed for Gnome.

    Another alternative to all this would have been to run Samba on the Linux computer and just share a few folders at home over a wired or wireless Ethernet connection.

  • You are both right (Score:3, Interesting)

    by hey! ( 33014 ) on Sunday July 29, 2007 @09:49AM (#20031653) Homepage Journal
    I think I know the reason for this discrepancy in experiences.

    Laptops.

    Laptops off the bat have drives with fewer heads, and therefore are more sensitive to fragmentation. Furthermore I have seen laptops delivered with FAT file systems with 512 byte block sizes which on converting to NTFS yield cluster sizes that are smaller than optimal. I have also seen laptops delivered with 512 byte cluster NTFS.

    Fragmentation is a huge problem under these circumstances, and lord help you if your MFT gets fragmented.

    Pretty much the first thing I do with a new machine with Windows preinstalled is check to cluster size on C to make sure it is 4K; if not I'll use Partition Magic to resize the clusters and the partition, then create a separate partition with an 16K cluster size that I use for database files and virtual machine disks. Since those files are huge and cluster management by the OS redundant, I opt for a larger cluster size, although this does preclude using Windows filesystem compression.

    This works pretty well, although I find from time to time it still helps to defrag C: on laptops. On a desktop I never bother.

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Working...