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
Since you have to find the lowest common denominator supported by all your platforms, your weak link is obviously (and as usual) Microsoft Windows.
So the most "modern" fs you'll be able to use is unfortunately NTFS.
fuse implement on both mac os x and linux
"Steve Jobs invented the world" -- Bill W. GATES
I don't know. Right now I'm a Windows user so all I know is a file system that blows - nothing about systems that suck.
I prefer Flambe as apposed flamebait.
Just get a USB card punch and reader. I think 029 punch code is pretty much standard.
Fight Spammers!
FAT32 works natively on all three, but of course it's showing its age. I use Windows mostly, and compared to NTFS, FAT32 is more susceptible to data loss than NTFS and also doesn't have security controls like NTFS. Plus that whole 4gb-per-file limit thing.
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/
I have an ext2 partition in windows using http://www.fs-driver.org/
However ä,å and ö characters in filenames get screwed up.
You know, you can partition your hard drive and put a different filesystem on each partition. Your comment about "storing ISO images and loop-mounting those" seems to indicate that you don't know about partitions (they do the same thing but avoid one level of indirection).
everything reads NTFS and if you have Parallels you can install a windows partition and write to it as well.
If you want full read/write on everything, the only I know of that has drivers for all three systems besides fat32 is ext2 . The mac one is hard to get at and is a bit primitive, but it is in the kernel.
No matter what the OS, you are going to have to install a driver/patch on at least one of them to get support for some filesystem unless you use something like FAT.
/shrug
http://www.fs-driver.org/ ext2 for windows
http://sourceforge.net/projects/ext2fsx/ for osx
Have any of you read the post you are replying to? He's asking for a solution for multiple platforms, not just windows and linux. If you read his question, he uses Linux, Mac OS X and uses a Windows partition for games. Solutions that only work on windows and linux or linux and bsd are USELESS. Stop answering with your favorite non-portable file system and answer the question, or STFU please.
i came across this on lifehacher.com but i have not have a chance to try it out. I don't think this is going to fix your linux problem..but it might be useful for all the other mac/win people out there
Mikey
I've always been the kinda guy to fall for the girl dressed like an eskimo.
I have a Linux and a Windows Hard Drive with another drive for data ive found that using the Windows Ext2/3 driver works fabulously but im not sure about Mac OSX, IMO it should work because its freeBSD - Hope this helps
the driver only implements ext2
Not an option with OS X. NTFS is read-only for Mac users.
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*-
ntfs-3g will run under osx, and there exist ext2/3 drivers for osx. Darwin is just another unix-like - windows is the real problem in the question.
For quite some time now (10.3 Panther I think) there has been a case-sensitive variant of HFS+. The Linux kernel has supported mounting it for some time now since I contributed a patch after realizing I couldn't access my filesystem. Unfortunately, it does not support HFS+ journaling so you have to make sure OS X gets shut down properly. Also, the last time I looked, the open source HFS+ utilities like fsck did not handle case-sensitive HFS+. I looked into fixing it but it was such a god-awful mess of code I decided I didn't trust it anyway.
On Windows you should be able to use MacDrive but you may want to check with them to make sure that case-sensitive HFS+ is supported. I only say this because for instance Alsoft's DiskWarrior product didn't support case-sensitive HFS+ until very recently. Why, I don't know since case-sensitive HFS+ simply omits the case-folding step before determining b-tree position. It's all documented in TN1150.
No journaling.
There are many ext2 solutions.
On my Debian NAS I use ext2. For windows it is shared via samba, and shared via netatalk to my macs. Simple solution.
...which is perfectly fine, because Ext3 is backwards compatible and Windows wouldn't make use of the journaling feature, anyway.
nfts-3g was the only good answer. I should have mentioned that, but the problem is a whole, not just a windows issue. Assuming that something works because OS X is posix is wrong as we are talking about data here, often un-recoverable and damned important. Stability and maturity is too important to leave up to chance.
> Stop answering with your favorite non-portable file system and answer the question, or STFU please.
The answer is ext3. After what MS tried with FAT, all storage manufacturers should be using ext2/ext3.
HTH!
To Forever And Terrible, because it will never go away as the cross-platform standard.
I bet 1000 years from now, your 10-billion-trillion-Exabyte, house-sized, semi-conscious, holographic storage device will have a 2 gig fat partition up front.
I would think any filesystem supported by MacFUSE would be the best place to start. Their is a NTFS-3G module for MacFUSE, and it works under linux, too.
Jerm
Oh, you're not a real doctor, are you?
I use Ubuntu with Samba and maybe NFS. My gaming computer use Vista, for storage I have a Ubuntu with EXT3 shared folder which uses samba. I can write/delete/execute software easily. All I do is mount a new network disc in Vista. I belive this also work for NFS which is filesharing(SMB://) for unix.
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.
The original post said that HFS+ was case insensitive, and if that's the reason to reject it, then I think it's a bad reason, unless there is no Linux or Windows support for case sensitivity. Mac OS X Disc Utility offers case sensitivity, but it looks like you have to set it when you do the partitioning.
Personally, I just set up a "server" that shares drives by SAMBA. Then there's not as many problems sharing the actual files between platforms.
I have encountered this predicament before and my solution was to get a mini-atx case and put some hard drives in it and then load FreeNAS on it. With FreeNAS there are plenty of options to work with the different file sharing protocols supported by each of the operating systems over the network. Just an idea, may not be practical for everyone but it is just another solution to be added in to the nine-million already out there.
Ah, but at least I have the balls not to post my opinion as a dirty AC. Actually, I work with OS X on the desktop and Linux on the server side and I have a XP box at home. I'm interested in a solution that fits all three, not some bigoted and fascist selection that pointedly excludes one or the other.
What exactly makes me a "Microsoftie"? If you read my post you replied to (for the first time) you'll notice that I was specifically bitching about the OP assuming something would work on OS X, when in fact, it can't. OS X currently only officially supports userspace drivers.
While it's not free or open source, you can format it HFS+ and use it under Mac/Linux natively, and get excellent HFS+ support under Windows by purchasing MacDrive ($50). I've used it for a while now, and has worked flawlessly.
Hi, I have exactly the same problem, One MacbookPro, One PC, and another Linux. The fact is, there isnt a portable filesystem, if you are planning on ext2/3, the mac os x driver is unstable like the hell, and will make you loose your data and crash your system, as it happens to mine. Fat and fat32 will work but with small disks only, and NTFS your linux/macos will damage it within time. I Have a 400 GB Sata external disk and currently using HFS, because its the only one that doesnt corrupt the data from time to time, and you have drivers for windows/linux. I know it isnt the best choice but if you plan to keep your data, its my advice.
Are you trying to be funny? If you want to just be an asshole and throw out a filesystem that is guaranteed to never be ported to the majority of all platforms, why don't we pick ZFS, a *CLEAR* and obvious winner over Ext3. ZFS is more technically capable, more powerful and I'll even venture to say more righteous than Ext3 will ever be.
Get your funnies right next time, kthxbye
Well, if he was really smart he's use XFS as that works on BSD and Linux.
Ohh... sorry, I didn't read the question. What the HELL was I thinking. OMG, Pink ponies! Look at the purty colors!
I said no... but I missed and it came out yes.
...Windows wouldn't make use of the journaling feature, anyway.
Huh? What's that supposed to mean? Why wouldn't it?
It's not just for 12cm frisbees.
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.
...which is perfectly fine, because Ext3 is backwards compatible Um, no. The lack of journaling is exactly why it's NOT fine. Sure, you can access your files, but you also can do a lot of damage when Windows crashes before unmounting cleanly. and Windows wouldn't make use of the journaling feature, anyway. ??? Ever heard of NTFS? Or do you still run FAT32 on your system? WindowsNT products have been using journaling for many, many years now. The Windows Extensionable Filesystem API provides full support for it to third party developers, as well. I have no idea why you would make that statement...Linux (and other free operating systems) can adapt very quickly to changes such as a new file system. The problem comes, as always, from companies that don't support out of the box anything else than their products.
A FS that isn't supported by Windows out of the box, without any user intervention (read: installing 3rd party ext2 or whatever drivers isn't an option) and opens even the smallest alert to the user telling it's not a native way of doing things will have no chance of estabilishing itself as a common filesystem for data exchange between systems.
Note that Microsoft doesn't want users to be free to exchange data in both directions, as reading and writing. A quick look at the number of file formats supported by Open Office and MS Office should explain it all.
Being up to those who lead the market to let those changes to occur, I'm not holding my breath.
Ext3 is available on Linux, Windows, OSX and FreeBSD. NTFS, the only other contender relies on unstable reverse engineered drivers.
What kind of fuckwad trusts data to a file system that isn't even documented?
After a lot of thought I went with a Kurobox running Debian and Samba. It has a gigabit ethernet port which, of course, can plug in over cat6 with no crossover, which is faster than USB. This is easily accessible by my Windows, Linux, and Mac installations and it's running ext3 - but who cares, it's over Samba, or SSH, or NFS.
It also happens only a little bigger than most drive enclosures, and you get a cheap, quiet NAS. This or any similar Linux-capable system is well worth your time.
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.
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.
B) Eliminate all the stupid users. This is frowned upon by society.
it's in the Linux kernel : v9fs
it's in Plan 9 From Bell labs (obviously)
it's in Unix clone userlands : plan9ports
it's in Inferno
it's in wmii
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The reason why it's a proprietary one that is "the best cross platform one", is because the proprietary OS's refuse to support other filesystems. If windows would support Reiserfs, it'd be a much better option for cross platform than AWFUL ntfs/fat32. But unfortunately M$, for obvious reasons, refuses to do that. Meaning that open source software has to attempt to reverse engineer a crappy file system and use it, instead of having the best filesystem win out for system users of ALL platforms.
Excellent point. Even for a home user, the data on the drive is far more valuable than the drive itself! Whoever mod'ed your post as flamebait obviously has problems with reading comprehension.Linux and Mac both have native UFS (a.k.a Fast File System) support, windows can also support UFS: http://ffsdrv.sourceforge.net/
Right now, Ext2 seems to be the best option. I use it myself on my large (backup) hard drives. There are a few big problems, though.
Ext2 support for Mac/OS X and Windows is... limited to say the least. It works, but if you're going to use Windows/Mac to copy files to your hard drive the majority of the time, you might prefer to stick with FAT32.
Ext2 is also not terribly robust. When mounted async, it has the old well known problem of data corruption should anything go wrong while writing data (power loss, crash, etc.). I've lost a couple of ext2 partitions to that. So if you care about your data, and can't use Ext3, I strongly suggest mounting your Ext2 partitions read-only, which really hobbles performance, but might not be too noticeable over (relatively slow) USB2.
Personally, I've got high hopes for UFS/FFS. Just about every operating system supports it in one form or another. Unfortunately, it seems nobody has bothered to get their implementations compatible with other implementations. So, while there is UFS/FFS support for Windows/OSX/Linux/*BSD/Solaris/AIX/etc. it's all in just a slightly different on-disk format, so it's not easy to get one to read another. It's a shame, because it's without question the most robust, flexible, high performance, and long-lived file system around.
I can only hope that with the transition to UFS2, maybe they'll avoid diverging as they upgrade. Of course, it's not a sure thing that the proprietary systems (eg. Solaris) will accept the upgrade path to UFS2 to begin with. (they seem more interested in going the Veritas route)
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I believe permissions are wonky with ntfs-3g, so it would be akin to running on a FAT system.
Easily solved... and you didn't mention anything about security, so let me help. I wrote about it previously.
I've been moving more and more of my data off to TrueCrypt on Linux/Windows or GELI on the FreeBSD side to lock things down. So far, it works great.
There are ext2 drivers for Windows, but they're definitely not ready for production use. There's just not much interest in them compared to NTFS on Linux. If we want to promote ext2/3 as a Free cross platform filesystem, let's throw some support behind a good Windows ext2 driver.
The ntfs-3g website says you can boot from it, and run Linux of it, so apparently you can. Will there be any issues? Quite possibly.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
And that issue is? Not having a Linux with HFS+ volume handy, I presume that the case insensitivity is handled in the VFS. The only times that case sensitivity has ever been an issue for me are 1) some joker decided it would be funny to name a couple of Linux kernel source files with the same name in different cases, and 2) when I try to rename a file using 'mv' to just change case with mv aliased to 'mv -i', mv thinks it's the same file and asks me to confirm.
#1 is just plain bad form to name files like that, and #2 is harmless.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I've been using symlinks in OS X 10.4 on an external drive that Finder says is formatted as FAT32. Using "ln -s" appears to create symlinks just as if it were a normal *NIX type file system - they show up as symlinks using "ls -l" and everything (Emacs, iTunes, etc.) treats them as regular symlinks. However, the same does not work when I hook the drive up to a machine running OS X 10.3. Does anybody know what's going on here? I was pretty excited that I could use symlinks like this, but I really don't know how portable it is since I don't know what is going on underneath the hood. I'm posting anonymously out of embarrassment for not already knowing the answer. It seems like whatever OS X 10.4 is doing might be good to imitate on Linux.
Linux supports almost all filesystems that are currently available, so that shouldn't be a problem. Mac OS X is a bit more picky but as far as I know, I've used it with EXT2, EXT3, HFS, HFS+, .... ReiserFS needs a driver though, I think XFS is standard, but again, not sure. Just format your file system under Mac OS X with the "Unix" filesystem and you should be all right.
Oh, you said Windows, never mind. Use a networked file system like SMB or FTP to send things from Windows to another machine or you could use some drivers available for whatever you chose (but don't kill me if it screws up as Windows usually does)
Custom electronics and digital signage for your business: www.evcircuits.com
I had the same problems a few people above mentioned. But since memory requirements are rising and rising I now bought a ATX casing, added 5 hard discs to a Raid 5 (approx. 2.5TB).
More information:
Surely, not the cheapest approach, but I think something like this will last longer (more space, does not "die" when the original machine becomes obsolete) than a normal shared disk and I can also use it as a print server, bittorrent client and so on.
Cheers!chris
one of these running Samba or NFS?
'nuff said.
Sig free's the way to be.
Before I abandoned windows pretty much forever, when I booted windows I would have my linux box run as a windows service and access my linux system disk using Samba.
It wasn't fast but ti was compatible.
Sam
blog.sam.liddicott.com
It supported natively at linux/mac os, and install the ext3 driver for windows.
it's much better solution compared to fat32 which will fit out of the box for all.
NTFS Sucks + you'll have to recompile kernel to have writing capability to NTFS disks.
Enjoy + Goodluck!
Read and Comment at my BLOG
!!!
If you look at a FS that can be read anywhere, the only solution will be an open source one. This might however mean that it is not readily available everywhere out of the box.
OTOH it will mean that drivers will be readily available if needed.
If you want something that is read out of the box by each and every OS, then make up a simple spradsheet, horizontal the different OSses, vertical the different file systems en then start crossing which has what. Last look what is available on most by default.
Loopmounting an iso is still a file (with filesystem) written on (another) filesystem.
Don't fight for your country, if your country does not fight for you.
Many? The other options are FAT, and ext2. From that choice NTFS is probably the best choice, even though I wish it wasn't.
The main problem with case sensitve HFS+ is that it breaks a lot of applications that don't expect it, like practically everything Adobe makes. Not an good solution even if you never had to share hard drives with another OS!
It doesn't mean much now, it's built for the future.
NTFS is not a solution because Microsoft can change it incompatibly at any time; all they have to do is put something in a Vista update that modifies the file system in a backwards-incompatible way. Once they do, Windows becomes unsupported by NTFS-3G. In addition, Microsoft likely has a lot of NTFS-related patents that they can use to shut down any open source implementation whenever they want.
No, the only solution is to create drivers for one of the FOSS file systems. Ext2 and ext3 are the obvious candidates. In fact, an even more obvious candidate would be the BSD file system, except that there seem to be so many incompatible versions of it.
At the moment, my desktop dual boots linux and XP, for gaming. Using the ext2 drivers for Windows, I've never had a problem reading or writing to my Ext3 partition. Now, I've got a 750GB Ext3 partition on a SATA drive that I'm hooking up to my laptop with a USB adapter - if anything would make access to it unstable, this would be it - and it's working like a charm. Haven't had any experience with mounting on Macs, though, as it appears most of the other suggestions here state as well, so, YMMV.
sounds like Universal Disk Format(UDF), the format used on rewritable optical discs, may interest you.
t
see http://en.wikipedia.org/wiki/Universal_Disk_Forma
of course, it depends on your needs, different filesystem designs tend to have different strengths. UDF tries hard to be able to represent the foibles of many systems, which create a sort of portability.
Use FAT32. Yes, it sucks as a file system. But it's fine for your stated goals (backup and transfer), and it has universal compatibility. Don't discard an optimal solution just because it makes you feel uncool.
The fact that it runs in userspace means it can corrupt your data from userspace instead corrupting other programs from kernal space.
a program of driver that runs in userspace does not make it good program...... 8p
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)
Don't some publications in the English language still use the spellings coöperate and naïve? Isn't it important to preserve spellings like those in filenames that represent the titles of articles?
In theory, at least, a further problem is that, of the set of facilities provided by the different filesystems, there are features of each that are not supported by others.
e.g. Unix-derived (like Linux) filesystems are fully case-sensitive;
NTFS (as presented by Windows) is case preserving but insensitive.
NTFS provides essentially unlimited file attributes and data streams
Unix-derived fs behave as "stream of bytes"
(and old mainframe fs typically had many other abilities such as generation numbers and atomic commit)
There isn't a perfect solution - if people start using NTFS outside Windows MS will probably retrospectively change the spec in a way that doesn't make windows worse, but crashes non-ms implementations. If ext2 gets used then some program that uses file attributes constructively will get up and bite you - even ext3 may not handle everything that Vista may use. Separate filestore from OS by using network attached files?
Andy
Hi. Here is my clean ID. Enjoy, big bro.
If you read the goddamn thread all the available solutions are pointed out. There isn't much more besides that (they mirror my findings). Geez.
NTFS will work on Linux and MacOSX via FUSE. Its userspace, but quite fast still. If NTFS+FUSE doesn't suit you, you can use Ext2 on both XP and MacOSX. Other OSes support Ext2 too (and read support).
Else, go build a fileserver with gigabit ethernet with USB HDD attached and you're all set as well. You can make your Linux server a fileserver, even stick a WLAN NIC into it. Its marvelous, I'd say. And since you use Ext2/Ext3 or NTFS, you can detach the USB HDD and take it with you. You could even stick LUKS on it w/some encrypted data, and mount that data under TrueCrypt/FreeOTFE on Windows (and if TrueCrypt is ever ported to MacOSX, there too). What is the problem with this? I don't see one. MacOSX and Windows all support CIFS so if you use Samba you're all set.
The method has been called phase-tree. The reiser4 stuff is similar.
Write new data to free blocks. Write out everything that can't be shared with the existing filesystem: data blocks, the d irectory blocks, FAT-related stuff, root directory blocks, and so on. Now, with one single-sector (atomic) write, switch over to using your new root directory and FAT.
Linux can implement this right now, 100% compatible. (the on-disk features have been used for online defragmentation) There is no need to wait for Microsoft.
Wubi is an .exe installer for Ubuntu. It doesn't repartition the drive, it runs off of NTFS.
Not a sentence!
Microsoft supports this, especially with Vista. MacOS supports it. Linux supports it, though some work is surely needed.
It allows for huge filesystems. It handles awkward media, including write-once and raw flash.
This is where we're going, like it or not. The management in Redmond has decided.
Actually ZFS is very attractive even on single-disk systems. Some ZFS developers are using it on their laptop because:
Heck, there are lots of reasons for using ZFS on single-disk systems !
Why can't you have 1 partition with ext3, 1 with HFS+ and one with NTFS file systems?
The article starts off talking about an external firewire/USB drive.
On that basis the *worst* possible choices for filesystems would be Reiserfs and XFS.
Both of these filesystems (particularly XFS) make assumptions about the reliability of power supply and of connectivity of devices. They perform *extremely* badly if a drive is disconnected unexpectedly, something which (arguably) happens very often with external drives.
XFS was originally for mainframes and today is for high-reliability servers so it makes the assumption that its running on 'enterprise-level' hardware with a UPS and RAID array.
Reiserfs, on the other hand, has been accused of simple *sloppyness*. And my own experience would back that up, I'm afraid. I know that I'll get flamed by the Reiser fan-boys out there but Reiserfs has done my data in (on unexpected power failures) more times than I care to think.
And when I say *extremely* badly, in both cases (XFS, Reiserfs) I really mean it. Data can be lost in very nasty ways such as files consisting entirely of nulls or files 'swapping' data (your avi file has some text file in it and your 'text' file is an executable binary). Often without even an error message to tell you that something has gone terribly wrong.
In the free world the media isn't government run; the government is media run.
I asked a question similar to this in my journal entry on Slashdot, on Wednesday, March 23, 2005, (the question I made was rejected for Ask Slashdot). I asked the question - which has never been answered - and apparently (at that time) - no one could offer any suggestion for a "universal hard drive format" other than FAT32. With the development of the NTFS r/w driver for linux this may have changed. But I know of no ReiserFS or EXT2/EXT3 driver for Windows.
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
What I don't understand is why umsdos was killed off? It actually provides a reasonably good solution: the universal compatibility of FAT, with an ugly-hack to add permissions, modes and links. Also, although FAT is ugly, it does have 2 advantages:
1)Non journalling - so we don't quickly destroy flash devices
2)Simple - it's actually quite hard to destroy a FAT fileystem by eg pulling out a USB stick without unmounting it.
Justs shows how much of a fucking nerd you are with this Question.
I used this method in a very similar situation worked great
80gb disk
1gb Fat
the rest EXT 3
you can now get the drivers for ext 3 for both windows and mac and put them in a everywhere compatable partition and then you are compatable with everyones computer without having to chase drivers for each new computer
Sounds like a job for FAT32 to me. If you need to maintain filesystem permission and things... just tar.gz from *nix and zip from windos. Works for Macs too except for the loss of the use of certain parts of the characterset for filenames and filesystem niceties.
Codifex Maximus ~ In search of... a shorter sig.
I don't know about the fragmentation really. Personal experience here - just checked my partitions and found many files that are stored in thousands of "fractions". The OS installation is not a year old either, and I think I did defrag everything at least once already. Add to that, even if I defragment the drive, usually the tool cannot repair my NTFS drives completely. Moving the problem files back and forth between the two partitions does help though.
Ext3, Reiserfs, other Linux FSes though, all I hear is that the filesystem avoids fragmentation by itself and doesn't need to be defragged. How is that not much better than NTFS? Come to think of it, maybe a big part of the slowdown I see accumulating on Windows is because of this NTFS goodness..
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."
Partition and disk device handling will also cause unhappiness in this situation. OS X seems to expect external disks to either have no partitions or OS X partitions. Windows on the other hand seems to expect that any hard disk will have at least 1 partition. The rub here is that OS X doesn't like Windows partitions and Windows only understands it's own partition table format. Linux of course will easily mount filesystems from either type of partition table or a disk that has been directly formatted with no partition table. This has been my experience with IEEE1394 drives. I don't know if the behavior is different with USB external drives.
The upshot of all this is that it is easy to share an external hard disk between Windows and Linux and between OS X and Linux but it is very difficult to share one between all three operating systems. You are already in for this partition grief before having to deal with the sad reality that only FAT32 is supported equally well on all three platforms. Note: USB flash drives aren't affected by this. OS X and Windows hard coded assumptions about how drives will be setup only come into play when the device in question is an actual hard disk.
How much data do you need to share? For me and my work (freelance computer contractor) I just got a dedicated GNU/Linux server in a datacentre and placed anything non-critical there, after properly securing it of course. Thanks to 3G broadband and connections with all telcos operating here, I have Internet access whenever I am and at any time (except when it's raining! unfortunately 3G is too weather-dependent). I can also share parts of the data with my clients very easily as well (just an address and password, and the client can see a current report of where the project is going, access the bug lists, and even a Gantt chart), something which I have been told is very useful for them. The server I got is in the $200 range, but there are some cheap ones as well. There are some refurbished for $30 and some slow ones for $50, which depending on the value of your data I suppose could be used as personal Internet-based storage servers. Of course you could just leave a home PC open 24h connected to your DSL/cable and configure it as a server as well. Of course this works only if you don't have to share obscene amounts of data, which is why I asked how much data you have. For most kinds of data, you don't really need to carry them all with you, and what you need is just access to a subset of them.
The short answer is that, out of the box, Windows supports no decent FSs. However, there are several projects which provide read/wrie EXT3 drivers for Windows.
# cat
Damn, my RAM is full of llamas.
Am I the only one here who sees a duplicated effort of developing 2 drivers for EXT2 in windows? Would it not be better to combine the two developers together, like Voltron and have them develop a super driver for windows?
If you just run a damn nfs/samba server on your linux box you can access your files from pretty much any platform. I have my xbox fetching files off my Gentoo Linux box just fine and they're completely different OSes.
Tom
Someday, I'll have a real sig.
I would like see a network file system that doesn't suck.
NFSv3 supports no encryption, and access to data on the server is determined by the UID/GID supplied by the client. Thus, NFSv3 is usable only in secure networks with consistent UID/GID usage (or using NIS). NFSv3 also uses many semi-randomly selected ports and half a dozen daemons, which make it hard to firewall NFSv3.
NFSv4 promises to fix tons of things compared to NFSv3, but actual implementations seems to be coming slowly.
SMB/CIFS supports access control e.g. with a password. There are also extensions to support POSIX permissions, so some people use Samba even if there are no Windows boxes in the network.
FUSE + sshfs is neat from security point of view, and it's easy to start using it. But performance is horrible: a copying a single file in background makes accessing other files at the same time very slow.
To summarize, I'd like to see a network file system that could be used securely over untrusted networks, have good performance in both fast LAN and on more laggy Internet, and has multi-user support so you don't need to mount the directories from the server separately for every user.
- UDF is not a journalling FS. Given its original purpose, there is no reason why this should ever have been considered necessary. However, once you try to use it as a general purpose harddrive FS, it becomes critical. You might just as well stick to FAT32 if data loss after a crash is considered acceptable.
- Write support is limited to a few operating systems. On Linux and Vista, the R/W support seems almost there. On other systems, it seems to be a work in progress.
I have read this topic carefully as I would dearly like a better option but, frankly, the first post seems to me to be correct: use NTFS-3g or trade in the USB drive for a LAN drive. If you are using a 3.5" HDD, the LAN drive is the same size and weight. Neither of these options has great performance.XFS has at least been partly ported to most operating systems in SGI's CXFS. I have serious doubts that a complete port will ever see the light of day since a fair amount of work would be required to complete the ports, and I can't imagine a business plan to do this that would suit SGI.
There is folly and foolishness on the one side, and daring and calculation on the other. - Admiral Pellew, Hornblower
Yeah, actually USE a freeware file system ? Daft? You must be.
Reasons:
1- Reiser4 has fast journaling, which means that you don't spend your life waiting for fsck every time your laptop battery dies, or the UPS for your mission critical server gets its batteries disconnected accidentally.
2- Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. Reiser4 does this without significant performance losses.
3- Reiser4 uses dancing trees, which obsoletes the balanced tree algorithms used in databases. This makes Reiser4 more space efficient than other filesystems, because it squishes small files together rather than wasting space due to block alignment like M$ does. It also means that Reiser4 scales better than any other filesystem.
Do you want a million files in a directory, and want to create them fast? No problem.
4- Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
5- Reiser4 has a commitment to opening up the FS design to contributions. It is now adding plug-ins so that you can create your own types of directories and files.
6- Reiser4 is architected for military grade security. It is easy to audit the code, and assertions guard the entrance to every function.
For further details, and further technical knowledge, go to http://www.namesys.com/
You can easily share a disk over Wi-Fi(n) from your MacBook.
- format the disk HFS+J
- plug it into your MacBook
- choose Apple Menu > System Preferences and then choose the Sharing preference
- check the box next to "Personal File Sharing" and also the one next to "Windows Sharing" and choose System Preferences > Quit
- choose AirPort Menu > Create Network, name your network and optionally choose encryption and click OK
- login to your new network from up to 10 nearby machines, whether they are Mac, Windows or Unix with Samba you will get all the files out on any system
If you don't want to carry the MacBook, you can replace it in the above with an AirPort Extreme Base Station and all you'll have to do to set up is plug your disk into the USB on the base station and it will share the disk automatically over the network it creates. If you don't have a USB disk enclosure yet you can get ones that stack with the AirPort Extreme to make a remarkably small package that you just plug into AC wherever you are and your network will be up in about 30 seconds and serve 30 users, again whether they are Mac, Windows, or Unix with Samba.
HFS+J gives you journaling, Unicode, long file name and large file support, rich indexing for instant searches, rich metadata, only one disallowed character in file names, Unix permissions, Mac metadata, fast multimedia streaming (way faster than any Windows file system I have seen this demonstrated) and is modern enough (1998) to get you through to ZFS. Also all your HFS+J administration tools are there on your MacBook already and are all GUI and easy to use. Or if you prefer you can use the command-line tools that are also on your MacBook (e.g. fsck).
Also if you don't know about Disk Utility then check it out, it can copy an entire disk including file system into a single file on any file system. It's really handy for people who are interacting with multiple file systems.
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.
I should add, that I actually only started using the external hard drive a few days ago. I have not yet chance to test the setup yet much. I had used it under Linux some, but had only tried it under Windows about once a day or so ago. When I tried going back and forth between operating systems just now, I experienced a slight problem with the JFS partition. Most likely, I will quickly get it solved and working properly. But anyway, this is not a setup that I have not tested much yet and did experience one problem just now. I just thought I should warn you.
The other stuff such as the KVM switch I have been using longer and that part seems to be working perfectly.
That was discussed couple of years ago and there were no solution found. I mean FAT32 is no solution - more of a problem. Albeit being read by most if not all OSs.
Many people in past had recommended for OS specific stuff to use ZIP archives (since they are also universally available). Additionally to preserve verbatim information from *nix/MacOS volumes you can create disk image (laying on FAT32 volume). All decent OSs allow you to mount such disk images. Formats are different so it is not portable solution to preserve not portable OS-specific information about files.
Just to reiterate FAT32 is more or less only such solution.
P.S. I have looked also into ext2 support. In MacOS 10.3.x there were no official drivers (nor such drivers materialized in 10.4). Second party solution (I found only one) crashed my MacOS during installation and didn't worked in the end. For Windows there are multiple working ext2 solutions. Though not nice, yet allowing you to extract your files from ext2 volume. Not fitting for usual everyday work - but passable.
All hope abandon ye who enter here.
I actually have two external hard drives and the one that I had connected at that moment actually had FAT32 on the first partition. Somehow the JFS partition got slightly messed up, I may possibly have switched it off under Windows when it was not yet safe to do so (possibly). Since there wasn't anything important on either partition, I recreated the partitions just now and decided to use four partitions this time. The first is now a small NTFS partion, the second is a small EXT2 partion, the third is a huge JFS partition, and the fourth is a FAT32 partition.
As a test, just now, I switched back and forth several times between Windows and Linux and created or edited files on various partitions each time. I did not have any problems this time.
I also went ahead and used rsync again to start back of some of my files again onto the huge JFS partition. I plan to keep one of the external hard drives stored safely elsewhere just in case the building ever burns down or my computer ever gets stolen. The data is not real important since this is just a home computer, but I still believe in backing up stuff anyway.
It doesn't run off of NTFS. It creates an image file in Windows, and then loop-mounts it in Linux for the root filesystem. Since the kernel has write support for NTFS as long as you don't change the size of the file you're writing to, it works. It doesn't really boot from NTFS, it boots from a loop-mounted ext3 or whatever Ubuntu uses (that's how many LiveCDs boot). It doesn't even use ntfs-3g.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
MOD parent "-1, Yodaspeak"
Fortunately, Sun realized that mistake with ZFS - the byte order is determined by the machine that formatted the drive (zpool), but the ZFS driver will swap bytes if needed.
Even without extending UFS this can be implemented in UFS drivers... there are a plethora of elements in the superblock that can be used to determine the byte order and figure out other compatibility problems. Going forward, the superblock can be extended to explicitly identify the variants.
Extending one implementation to support read-write access of the others is the first step. Given how many implementations are open-source, there's nothing technically in the way.
I know it would be hideously complex and expensive, but maybe someone should invent a chip that transparently converts between an internal file system and ext3/HFS+/NTFS. The OS mounts the disk and the chip determines which FS is wanted (this step probably doesn't actually work) and presents the internal FS as the target FS. The advantage would be that the device is sharable between the three biggest OSes; the disadvantage would be that the internal FS would need to not only incorporate all functionality the three public FSes support but also implement stuff like fsck etc. with public-FS-specific functionality as well.
The alternative would be to get a free FS out the door and convince Microsoft and Apple to include it. Which makes the hardware translator the best feasible option.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Your comment striked me and I actually googled for a USB (2.0?) punched card reader. Fortunately for me such bastard hardware doesn't seem to exist... That was a close one !
Non-Linux Penguins ?
The first part of your reply is of course correct (regarding the backwards compatibility).
Windows WOULD, of course, make use of the journalling IF THE FILESYSTEM SUPPORTED IT.
You're probably correct in that UFS could be patched to swap bytes when needed. OTOH, Sun seems to be committed to using ZFS as their file system of choice and they also seem committed to having ZFS ported to other OS's (e.g. MacOS and FreeBSD). In addition, ZFS seems to be more rigorously defined which suggests that different implementations will more likely be interoperable than currently is the case for UFS.
You want to switch Windows users to Linux. Guess what: they ALREADY have data on NTFS. So the windows ext2 driver is low priority.
Also, there was a comment here about the linux distribuitors being hesitant to producing windows code for users that already use linux.
Ext2 is natively supported by Linux, and third party drivers exist for windows and OSX.
There is also UFS, which is natively supported by OSX and linux has support for it too, tho i'm not sure how good it is (insane how it would be so bad, considering how open the ufs specs and implementations from several systems are).
HFS+ also has a case sensetive version since OSX 10.4, tho i'm not sure if linux supports it, linux's HFS+ support does need some improvement.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
...a definite answer!
HFS+ does have "case sensitive" option while formatting (erase) and I did opted in for it while making my raid 0 (software) HFS+.
There is ZERO effect on compatibility. Even on software which was coded before 10.4.x, e.g. 10.2.8.
There was one problem with single shareware utility but it turned out to be a glitch in programming and they fixed it after my bug report. The real issue was lack of support from commercial level disk utilities such as Diskwarrior, Techtool but they both have excellent support to it now.
What I mean is you can backup your drive using Disk Utility image and ASR options, erase it case insensitive and restore back, you magically have case sensitive HFS+.
There are a variety of cross-OS file systems out there.
This is also about a file system that sucks less.
ZFS certainly has many advantages, but then so do NTFS, HFS+, Ext*FS, ReiserFS, AdvFS, and so on. Of all the alternatives, UFS has proven itself less likely to gnaw its own guts out for one reason or another than just about anything else I've used over the almost 30 years that I've been in this racket. That's worth a little patching.
If you use colinux the speed of the linux install is near native, the only downside left is it get murdered when Windows dies.
The thing is that NTFS expands the MFT when you add files and folders to an NTFS volume, and does not reclaim the space when you delete files. This means that if you have or add a lot of small files, enough to fill up your disk and then delete them, you will end up with less usable space than you started with.
Note that you either need to re-format or use a third party defrag tool to get that space back.
An external drive that can not be used on other people machines without installing something is essentially useless.
So, sadly, it's useless.
Also, a little-known problem with Mac OS X; if your drive is not formatted as HFS+, then you cannot share it using AppleShare (but still with Samba, but that requires messing with smb.conf)
I think the best solution if you really really must have the best file system on the drive, create a small FAT partition with MacFuse and WinFUSE? installers for ext2 support, and format the drive ext2/3.
The point isn't to help Windows to Linux switchers. It's to make ext2 a viable cross-platform filesystem for removable storage devices. Big difference.
You cannot create an HFS+ partition when the drive is partitioned for PC.
Ok, I have never claimed NTFS is perfect, but FAR from the horrible FS people on SlashDot think it is.
However, the MFT is not a good example of why NTFS is bad. You realize that on a 500GB volume, the 'SYSTEM' spaced used by the MFT is around 400mb at the maximum.
The MFT isn't quite so bad, especially when you consider what all the MFT holds, how it is self repairing.
So you want to bring contention with the MFT on NTFS, I ask you to show me ANY FS that doesn't 'use' space for keeping the file structure. It is impossible, so they all do.
Some FS methods of tracking files and used space are less efficient and some are more efficient.
And the MFT you are complaining about is what helps make NTFS very efficient even for incredibly large volumes with a massive number of files on the volume. Especially when you compare it to FS like FAT, EXT2, etc.
Phew! What a rant. One for the books, eh? All I can say to that is: Is that you Mr. Gates?
I have seen scientists in different fields, of international renoun, that could not grasp the difference between a RS232 serial port and an ethernet one, or why the chaps using Linux could display programs running in any machine in the network in their own workstation while he could not without installing software on his Windows laptop (he did not want me to put viruses on it, so he wanted not extra software ...).
And of course there was no point in explaining more esoteric stuff.
The NASA guys are brilliant, but I would not put it pass them having many funny and amusing computing mishaps here and there (I am surprised they would keep any serious data in a Windows NTFS machine, if you need to apply a patch and you have a computation taking several days accessing data there, well, lets say your patch would have to wait, in other machines, depending on the nature of the patch, most likely you can apply it on the fly).
IANAL but write like a drunk one.