Slashdot Mirror
Cross-OS File System That Sucks Less?
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?"
NTFS-3G
http://www.fs-driver.org/
I just use a external drive formatted in EXT3, and for windows files i just install the Ext3 driver.
ext2 is supported everywhere and it's far better than fat32 or ntfs. for windows, http://www.fs-driver.org/ and for osx http://sourceforge.net/projects/ext2fsx/
Since MacOSX is BSD based, I would be willing to bet that similar projects and support can be found (but, I Am Not A Mac Fanboy).
On Windows, you are pretty much stuck using either NTFS or FAT. FAT volumes can not be created in windows larger than 32GB. Although, you could create the partition using 3rd party tools to get beyond that limitation. I have had some success mounting ext3 partitions using Ext2 Installable File System For Windows or Ext2 File System Driver for Windows.
Personally, from my experience, VFAT or NTFS are about your only options.
Having been in the exact same situation I've tried all sorts of different solutions and I'd say the best current solution is NTFS, which is out of the box natively supported on both OSX and Windows (natch) and also available R/O in the default linux kernel as well as having strong R/W support now via ntfs-3g. Of course fat32 still works just fine for this application, but it's getting a little long in the tooth as far as advanced features and modern storage needs go (c'mon what is up with those weak filesize limits)!?!? And I've had some limited success with using ext2/3 on windows and linux but found that the windows kernel driver for ext2 was not very stable in my config and the userspace tools to read/write ext3 in windows was far too kludgy for my tastes; I haven't had a chance to try ext2/3 on OSX.
-*The above statement is printed entirely on recycled electrons*-
See above.
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).
.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 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
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.
Cut that out, or I will ship you to Norilsk in a box.
Trying to use a filesystem across multiple platforms is painful. That's a clue that you're tackling the wrong problem. You don't need to share filesystems, you need to share files. Different problem with different solutions.
I set up an old PC with Linux to solve many needs. NFS and Samba provide a common pool of storage for every OS that I use. Since setting that up, I haven't ever though about shared partitions. They aren't needed.
Linux and Samba worked for me, but that's not the only solution. A NAS box might work better for you. The point is that you need shared storage, not a shared drive. Every OS supports network storage. Every OS supports backups across the network.
It may turn out that Hans Reiser is guilty. However, he is innocent until found guilty. And if he is guilty, that doesn't taint everything he ever did. That is like saying Germany should have recounted all the construction, development and wealth of the Hitler era. If you drive on any part of the autobahn constructed during his reign, then clearly you must be a nazi, right?
So, please drop the trolling and stop calling it MurdererFS. It is an insult to the many employees of NameSys who developed the code, and continue to do so today. Not to mention, it would certainly be an unfair accusation if Reiser is acquitted.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.