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
Just get a USB card punch and reader. I think 029 punch code is pretty much standard.
Fight Spammers!
http://www.fs-driver.org/
I just use a external drive formatted in EXT3, and for windows files i just install the Ext3 driver.
Not really, right? Even if there was, Microsoft doesn't seem to be interested in keeping it that way. With the "advent" of Vista and whatever relational-style FS they might try to forcably upgrade us to in the future, what are the odds of the prototypical modern journaling, etc FS being shared across the two? My guess is you're stuck with ext on linux and NTFS or whatever else on Windows. Of course, you could run NTFS on Linux if you've got two big brass ones.
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/
There are ext2 drivers available for windows. ext2 is just ext3 without journaling. It should be a viable option.
Give me Classic Slashdot or give me death!
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.
Personally I have a golden rule I always keep in mind when dealing with cross-OS file system usage: Never trust write support on foreign filesystem drivers. FAT12/16/32 is the only exception, since it's so old and primitive that anyone should have fully mastered the support of it by now. But apart from that, I'll never believe a filesystem driver to reliably write on ext2/3 outside of Linux, or HFS+ outside of OS X, or NTFS outside of Windows.
Modern filesystems are complicated beasts. One tiny error can have catastrophic results. Native filesystem drivers are the results of many years of real-life testing by millions of users. Can you really believe a third-party filesystem driver to be solid enough to write on a foreign filesystem?
Read-only support is OK because it's a magnitude easier to implement, though.
The only viable solution to cross-OS filesystem usage (without crippling yourself to FAT32) is networking.
NTFS is exactly what I use for my portable hard drive that I share between Windows, Linux and Mac computers. The main reason for choosing NTFS was that I need to store big virtual machine disks where files are sometimes many gigabytes in size. In Mac OS X and Linux, I use NTFS-3G to access the drive. It works, but it's very slow when transferring many and/or large files, so I would love to have a better alternative.
Because it doesn't work. The ext2 driver for OS X is _VERY_ unstable. The last time I tried it, about five months ago, the driver caused a kernel panic. After rebooting, OS X wouldn't read the drive anymore. It was unable to seek the disk. I thought it had caused a head crash until I hooked it up to a Mac without the driver installed; that one was able to see the disk and format it. Needless to say, I removed the ext2 driver.
FAT is really the only viable option at the moment. The problem there is that you will be limited to files 2GB in size. Have a DVD image you want to access from all three platforms? Forget it. You'll either have to burn it to a DVD or use FTP, because SAMBA is limited by the same 2GB limit.
Someone else posted a response about using UDF. I'll have to look into that, but I'm not sure OS X or Windows will format a hard drive to UDF. Well, at least not with OS X's "Disk Utility" application.
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.
He's right. ReiserFS is a KILLER file system, show some respect.
NTFS is also unusably slow after 6 months of heavy usage, and requires regular reformatting
Wow this is news to anyone that knows anything about the NTFS structure.
I love how people can make garbage claims like this, yet there are companies that are running NTFS volumes that are 15years old without any incident. You know companies like EDS, GM, and other agencies like Lockheed and NASA.
But I'm sure youf 'assessment' of NTFS is much smarter than the 'rocket scientists' at these organizations.
Let's take your starting line "NTFS is also unusably slow after 6 months of heavy usage."
Would you care to explain how this could possibliy, logistically or physically even be possble? Fragmentation is the only thing that could slow a FS over time unless the FS used a really stupid indexing system for the File Table. 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.
So please do englighten us all with your knowledge so I can call my contacts at NASA and tell them how stupid they are for trusting NTFS and explain to them that their systems are getting slower.
The lack of this competitive technological drive is probably why Windows has been the same POS for the last 20 years.
Or maybe it is because the NT team designed the OS so that it was highly extensible and would meet OS requirements for 15-20 at the minimum, considering it still has core kernel features that are not even used or exposed in Vista yet even.
The problem is, people like you, see Windows as Win3.1/Win9x and Windows of today running on the NT Core is a different OS, a different design, shares no code, and yet still has the same UI concepts so people aren't bright enough to realize that the underlying NT architecture is actually one of the few things MS has ever done right.
Go read up on NTFS, and Windows NT before you come back, you are only embarrasing yourself, and that is hard to do on Slashdot when talking about Windows and NT.
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.
4GB per file. If your backup job creates large tarballs, your hosed. At work, I was trying to backup a 20GB file to a USB external drive, and it told me the drive was out of space, even though it still had 700GB left. I had to format it NTFS for it to work.
"Be grateful for what you have. You may never know when you may lose it."